Senior Application Security Engineer @ Instructure Hungary Ltd

You'd be joining a team that owns the security of the application code, dependencies, APIs, and development lifecycle behind Canvas, Mastery, and Parchment products used by tens of millions of students, instructors, and institutions. What we're actually measuring is risk reduction. Not findings filed, not scan coverage, not tickets closed. This shapes the job: a large part of it is forming a defensible view of how much risk something actually carries, driving that risk down, and handing whatever remains to our risk management program so the business can decide about it explicitly. We'd rather you correctly classify ten things and reduce the three that matter than route a thousand alerts Our security engineering team is organized into two domain-specialized branches, Application Security and Cloud Infrastructure Security, so that engineers develop genuine depth rather than shallow coverage of everything. You'd own the application domain and get very good at it. We've written down what this role owns and what it doesn't, because we think ambiguity about ownership is one of the main ways security teams become frustrating places to work. You'll work closely with product engineering teams.

Core engineering responsibilities

Risk classification and residual risk handoff: Determine what risk a finding or design actually represents in context: exposure, data sensitivity, exploitability, blast radius, business impact. Tool-assigned severity is an input, not an answer — a high CVSS score on an unreachable component may be low risk, and a medium score on a public endpoint handling student data may not be

Severity is our call and so is the framework we level against: Drive that risk down, and where it can't be reduced to an acceptable level, build the case for what remains: what the risk is, what was attempted, what's left, and what resolution would take

We don't accept risk ourselves, and we don't quietly carry it: see below for who does

Vulnerability management: triage, severity adjudication, and driving remediation to completion for findings from our scanning tooling. This means partnering with the owning engineering team, not filing a ticket and walking away

Compensating controls: when a vulnerability can't be directly remediated, design and implement a control that reduces the risk to an accepted level, and document the reasoning and expiry condition

False-positive adjudication: investigate findings, determine genuine exploitability in context, and suppress non-issues with recorded reasoning. We treat suppression as an engineering judgment that needs a written justification, not a way to clear a queue

CI/CD security automation: build and maintain the pipeline gates and checks that catch problems before they ship. We'd rather automate a class of issue than review for it forever

Security tooling: installation, configuration, integration, and data pipelines for the application security toolchain

Application security specialization

Threat modeling: work with product and engineering teams to find design-level problems before they're built

Secure code review: manual review for the logic and authorization flaws that scanners reliably miss

SAST/SCA pipeline: own our static analysis and dependency scanning (Snyk, CodeQL, Wiz Code) coverage, signal quality, and developer experience

Secure defaults and paved-road libraries: build the shared libraries and patterns that make the secure path the easy path

Developer enablement: training, documentation, office hours, and design consultation

Product partnership: see below

Bug bounty program: work with our offensive security engineer to aid in researcher communication and triage flow

Technical specification review: review application specs against our security review rubric, escalating high-risk and novel designs to our Principal engineer or manager

Must have:

• Professional experience in Application Security / Product Security / Security Engineering.
• Strong understanding of core AppSec concepts, including web application and API security, authentication, authorization, and common application vulnerabilities.
• Hands-on experience with one or more of: threat modeling, secure code review, vulnerability management, SAST/SCA, CI/CD security, or security automation.
• Ability to assess and prioritize security risk in context, rather than relying solely on automated severity scores.
• Experience working directly with software developers and engineering teams to remediate security issues.
• Working knowledge of AWS and cloud application security.
• Strong analytical and problem-solving skills with the ability to investigate vulnerabilities and determine whether they are genuinely exploitable.
• Ability to communicate technical security risks clearly to both technical and non-technical stakeholders.
• Comfortable working independently, taking ownership, and making pragmatic security decisions.

Nice to have:

• Experience with Snyk, CodeQL, or Wiz Code.
• Experience building CI/CD security gates or automation.
• Experience with secure-by-default libraries, frameworks, or developer security tooling.
• Experience with bug bounty programs or vulnerability disclosure.
• Experience working with large-scale SaaS applications.
• Experience communicating security risk to Product Managers or business stakeholders.
• Experience supporting major security incidents as an AppSec SME.

You'd be joining a team that owns the security of the application code, dependencies, APIs, and development lifecycle behind Canvas, Mastery, and Parchment products used by tens of millions of students, instructors, and institutions. What we're actually measuring is risk reduction. Not findings filed, not scan coverage, not tickets closed. This shapes the job: a large part of it is forming a defensible view of how much risk something actually carries, driving that risk down, and handing whatever remains to our risk management program so the business can decide about it explicitly. We'd rather you correctly classify ten things and reduce the three that matter than route a thousand alerts Our security engineering team is organized into two domain-specialized branches, Application Security and Cloud Infrastructure Security, so that engineers develop genuine depth rather than shallow coverage of everything. You'd own the application domain and get very good at it. We've written down what this role owns and what it doesn't, because we think ambiguity about ownership is one of the main ways security teams become frustrating places to work. You'll work closely with product engineering teams.

Core engineering responsibilities

Risk classification and residual risk handoff: Determine what risk a finding or design actually represents in context: exposure, data sensitivity, exploitability, blast radius, business impact. Tool-assigned severity is an input, not an answer — a high CVSS score on an unreachable component may be low risk, and a medium score on a public endpoint handling student data may not be

Severity is our call and so is the framework we level against: Drive that risk down, and where it can't be reduced to an acceptable level, build the case for what remains: what the risk is, what was attempted, what's left, and what resolution would take

We don't accept risk ourselves, and we don't quietly carry it: see below for who does

Vulnerability management: triage, severity adjudication, and driving remediation to completion for findings from our scanning tooling. This means partnering with the owning engineering team, not filing a ticket and walking away

Compensating controls: when a vulnerability can't be directly remediated, design and implement a control that reduces the risk to an accepted level, and document the reasoning and expiry condition

False-positive adjudication: investigate findings, determine genuine exploitability in context, and suppress non-issues with recorded reasoning. We treat suppression as an engineering judgment that needs a written justification, not a way to clear a queue

CI/CD security automation: build and maintain the pipeline gates and checks that catch problems before they ship. We'd rather automate a class of issue than review for it forever

Security tooling: installation, configuration, integration, and data pipelines for the application security toolchain

Application security specialization

Threat modeling: work with product and engineering teams to find design-level problems before they're built

Secure code review: manual review for the logic and authorization flaws that scanners reliably miss

SAST/SCA pipeline: own our static analysis and dependency scanning (Snyk, CodeQL, Wiz Code) coverage, signal quality, and developer experience

Secure defaults and paved-road libraries: build the shared libraries and patterns that make the secure path the easy path

Developer enablement: training, documentation, office hours, and design consultation

Product partnership: see below

Bug bounty program: work with our offensive security engineer to aid in researcher communication and triage flow

Technical specification review: review application specs against our security review rubric, escalating high-risk and novel designs to our Principal engineer or manager

,[Vulnerability Management: Triage, investigate, and prioritize application security findings based on actual risk and drive remediation with engineering teams., Risk Assessment: Assess vulnerabilities and application designs based on exposure, exploitability, data sensitivity, blast radius, and business impact., Threat Modeling: Identify security risks and design-level issues before applications and features are built., Secure Code Review: Review application code, APIs, authentication/authorization, and business logic to identify vulnerabilities that automated tools may miss., SAST/SCA & Security Tooling: Own and improve application security tooling such as Snyk, CodeQL, and Wiz Code, including signal quality and developer experience., CI/CD Security: Build and maintain automated security checks and pipeline gates to identify issues before they reach production., Developer Enablement: Partner with developers through security guidance, training, documentation, and secure-by-default libraries and patterns., Compensating Controls: Design security controls when vulnerabilities cannot be directly remediated and document the remaining/residual risk., Product Partnership: Translate technical security issues into clear business risk for Product Managers and help inform prioritization decisions., Bug Bounty: Support vulnerability triage and researcher communication in partnership with Offensive Security., Technical Design Reviews: Review application and technical specifications against security requirements and escalate high-risk or novel designs when needed., Major Incident Support: Act as an Application Security SME for major incidents escalated by the SOC/SecOps team.] Requirements: Application Security, Product Security, Security Engineering, web application security, authentication, authorization, AWS, Cloud Application Security, Synk, CodeQL, Wiz Code, CI/CD Security Gates, Automation Tools: Jira, Confluence, GitHub, GitBook, GIT, Github, a bit of Gerrit, Agile, Scrum, Kanban. Additionally: Medicare Private Healthcare with Hospital Package, Employee Assistance Program, SZEP Card, Employee Wellness Program, Free coffee, Bike parking, Playroom, Free snacks, Free beverages, Free lunch, In-house trainings, In-house hack days, Modern office, Startup atmosphere, No dress code.