Application Security Engineer Interview Questions: Model Answers from Threat Modelling to Code Review

AppSec interviews are lost by candidates who can name every OWASP category but cannot explain how they would find, prioritise and fix a real flaw with a development team that has a release next week. This guide gives the questions hiring panels ask application security engineers, with model answers at junior and senior level, the code review and threat modelling exercises panels set, the standards facts candidates are expected to know without notes, and a scoring rubric for interviewers. Answers are standards-led and vendor-neutral: they describe how a good engineer reasons, not which scanner menu to open. It is written for developers, testers and security analysts applying for AppSec, product security and DevSecOps roles, and for managers who want a consistent interview. What the role involves and how to get into it is covered in the Application Security Engineer Career Guide; CVs, interview formats and offers in the Cyber Security Interview Preparation Guide.

Key takeaways

• Root cause beats category names. Panels want to hear why a flaw exists in this code and what fix stops the whole class, not "that is A05 Injection".
• Know the current references. The OWASP Top 10:2025, OWASP ASVS 5.0, the 2025 CWE Top 25, NIST SSDF (SP 800-218) and OWASP SAMM 2.0 come up in almost every technical round, and quoting the 2021 list marks a candidate as out of date.
• Threat modelling is tested live. Expect a whiteboard system and the four questions: what are we working on, what can go wrong, what are we going to do about it, did we do a good enough job.
• Code review is a practical, not a quiz. Most panels hand over a pull request and watch how the candidate traces input to sink, ranks findings and writes them up for a developer.
• Developer empathy is scored. Senior answers cut noise, offer paved roads and accept risk with owners and expiry dates, rather than blocking releases with raw scanner output.

What panels test at each level

Fundamentals and standards questions

1. Walk me through the OWASP Top 10:2025. What changed?

Model answer: "A01 Broken Access Control stays first. Then A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures and A10 Mishandling of Exceptional Conditions. Supply chain failures and exceptional conditions are the two categories that stand out as new framing, and misconfiguration moved up. It is an awareness document, not a testing standard: for requirements I would use ASVS." See the OWASP Top 10 Guide.

2. How is OWASP ASVS different from the Top 10, and how would you use it?

Model answer: "ASVS 5.0 is a verification standard with numbered requirements at three levels, grouped into chapters such as V6 Authentication, V7 Session Management, V8 Authorization, V9 Self-contained Tokens and V10 OAuth and OIDC. I would pick a level per application by risk, turn the relevant requirements into acceptance criteria and test cases, and use the requirement IDs in findings so developers and auditors share a reference." See Application Security Requirements from ASVS and NIST SSDF vs OWASP ASVS.

3. What is NIST SSDF, and how does it relate to a development lifecycle?

Model answer: "SP 800-218, SSDF version 1.1, is a set of high-level secure development practices you fold into whatever lifecycle you already run, in four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). It says what outcomes to reach, not which tools to buy, which is why customers and regulators use it for supplier attestation. SP 800-218A adds a generative AI profile." See the NIST SSDF Guide.

4. Explain the difference between SAST, DAST, SCA and IAST.

Model answer: "SAST reads source or bytecode without running it, so it finds tainted data flows early but produces false positives and misses runtime configuration. DAST attacks the running application from outside, so it finds real exploitable behaviour but has no code location and poor coverage of authenticated or business logic paths. SCA inventories third-party components against known vulnerabilities and licences. IAST instruments the running application to watch data flow during tests. None of them finds missing authorisation reliably, which is why manual review and design work still matter." See the SAST, SCA and code scanning tool rollout playbook.

5. How do you score a vulnerability? Is CVSS enough?

Model answer: "CVSS v4.0 has Base, Threat, Environmental and Supplemental metric groups, and the specification asks you to label scores as CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE so readers know what was included. A base score alone describes the flaw in the abstract. For prioritisation I add whether it is reachable in our deployment, whether exploitation is known, what data or privilege sits behind it and whether a compensating control exists. A medium on an internet-facing payment API can outrank a critical in an internal tool nobody can reach."

6. Which weaknesses top the 2025 CWE Top 25?

Model answer: "Cross-site scripting (CWE-79) and SQL injection (CWE-89) are first and second, then cross-site request forgery (CWE-352) and missing authorization (CWE-862). Memory safety weaknesses such as out-of-bounds write, use after free and out-of-bounds read are also in the top ten, which matters if we ship C or C++. I use the list to tune SAST rules and training, not as a complete threat model."

Threat modelling questions

7. How do you run a threat model with a team that has never done one?

Model answer: "I keep it to an hour and the four questions from the Threat Modeling Manifesto. We draw a data flow diagram of the change, not the whole estate: actors, processes, data stores, flows and trust boundaries. Then we walk each boundary with STRIDE prompts, agree a handful of threats that matter, write each as a ticket with an owner, and check later whether the mitigations shipped. The manifesto's values are useful here: finding and fixing design issues over checkbox compliance, and actually doing it over talking about it." See the AI Agent Threat Modelling Guide for the agent variant.

8. Map STRIDE to the property each threat breaks.

Model answer: "Spoofing breaks authentication, tampering breaks integrity, repudiation breaks non-repudiation, information disclosure breaks confidentiality, denial of service breaks availability and elevation of privilege breaks authorisation. The value is as a prompt list at each trust boundary, so the team does not stop after thinking of injection."

9. Threat model this: a mobile app calls an API gateway, which calls three microservices and a payment provider.

Model answer: "Trust boundaries sit at the device to gateway hop, gateway to services, service to service and service to payment provider. Top threats: object-level authorisation failures on any endpoint taking an ID; tokens accepted by every service because audience is not checked; service-to-service calls trusted without workload identity; payment callbacks not verified, so an attacker forges a success; secrets for the provider stored in configuration; excessive data in responses that the mobile app filters client-side. Mitigations go to the owning team, and I would ask for authorisation tests on every ID-bearing endpoint before release." See the API Security Guide.

10. When is a threat model done, and when do you redo it?

Model answer: "Done when the agreed threats have owners and the mitigations are verified, which is the fourth question. Redo it when a trust boundary changes: new external integration, new data classification, new authentication method, a move to a new platform, or after an incident that the model did not predict."

Secure code review questions

11. How do you approach a 2,000-line pull request with a day to review it?

Model answer: "Read the ticket and the threat model first, then find what touches trust boundaries: new routes, authentication or authorisation logic, queries, file and command handling, deserialisation, cryptography and new dependencies. Run SAST and secret scanning to narrow the search. Trace each untrusted source to its sinks and check the control at each boundary. Spend most of the time on the high-risk files, and if the design itself looks wrong, escalate to a full review instead of passing it with comments." This matches the OWASP split between diff-based and baseline review.

12. A query is built with string concatenation, but the input is validated with an allow-list regex. Is it safe?

Model answer: "It might be today, but it is fragile: the regex can be loosened, the function reused elsewhere, or the input decoded after validation. The fix is a parameterised query so data can never become code, with validation kept as defence in depth. I would raise it as a finding with lower severity than an exploitable injection and explain why."

13. What do automated tools consistently miss in review?

Model answer: "Business logic flaws, missing or inconsistent authorisation, race conditions in transactions, workflow state that can be skipped, cryptographic misuse that compiles fine, and architecture weaknesses. That is where I spend human review time, and why I ask for authorisation test cases rather than more scanner rules."

14. How do you write a finding a developer will actually fix?

Model answer: "File and line, a one-sentence impact in business terms, the conditions for exploitation, the fix with a code example in their language and framework, the ASVS or CWE reference, severity with the reasoning, and how to verify the fix. I prefer pairing on the first one, and if the same flaw appears in ten places the real fix is a shared library or framework default, not ten tickets."

15. You find an API key committed six months ago. What now?

Model answer: "Treat it as exposed: removing it from the latest commit does nothing because it is in history and possibly in forks and CI logs. Revoke and rotate it first, check the provider's logs for use since the commit, then work out why it was there. The lasting fix is short-lived credentials from workload identity federation in the pipeline, a secrets manager for what remains, and push protection on the repository." See the DevSecOps Guide.

Pipeline and supply chain questions

16. How would you add security tools to CI without slowing developers down?

Model answer: "Start in report-only mode and tune before blocking. Run fast checks such as secret scanning and lightweight SAST on every pull request, slower scans nightly. Block only on high-confidence, high-impact rules and on new findings, not on the legacy backlog, which gets its own burn-down plan. Results go into the developer's pull request, not a separate portal. Measure false positive rate and time added to the pipeline, and drop rules nobody acts on."

17. What does SLSA give you, and what level is realistic?

Model answer: "SLSA 1.0's build track goes from L0, no guarantees, to L1, provenance exists, to L2, a hosted platform generates and signs provenance that consumers verify, to L3, a hardened platform that isolates builds and keeps signing secrets away from user-defined steps. Most organisations on a managed CI service can reach L2 quickly; L3 needs build isolation decisions. Provenance tells you how an artefact was built; an SBOM tells you what is in it. You want both." See Provenance Attestation vs SBOM.

18. A critical vulnerability lands in a library used by 300 services. Walk me through the first day.

Model answer: "Use SCA and SBOM data to list affected services and versions, then rank by exposure: internet-facing, reachable vulnerable function, sensitive data. Check for known exploitation. Publish one clear upgrade path or mitigation, open tickets for owners with a deadline per tier, and track the count of exposed services publicly to engineering leadership. Where an upgrade is blocked, record a time-limited exception with a compensating control."

Senior and lead questions

19. You inherit an AppSec programme with one engineer and 400 developers. What do you do in the first 90 days?

Model answer: "Baseline with OWASP SAMM 2.0 across its five business functions, Governance, Design, Implementation, Verification and Operations, so the plan is evidence-based. Inventory applications by risk. Put secret scanning and dependency scanning everywhere because they are cheap and high value. Threat model only the top tier of applications. Start a security champions group, publish secure defaults for the main frameworks, and agree three metrics with engineering leaders." See the AppSec Maturity Model.

20. How do you measure whether the programme works?

Model answer: "Mean time to remediate by severity against agreed targets, escape rate (vulnerabilities found in production that should have been caught earlier), threat model coverage for high-risk applications, false positive rate of blocking rules, secrets exposure and time to revoke, and SAMM score movement year on year. Vulnerability counts alone reward not looking." See the AppSec Programme Metrics Guide.

21. A product director wants to ship with a known high-severity finding. What do you do?

Model answer: "Make the risk clear in their terms, offer the smallest mitigation that reduces it, and if they still want to ship, record a risk acceptance signed by the accountable owner with an expiry date and a fix ticket. Security advises; the business owner accepts risk. I escalate only if it breaches a policy line such as exposing regulated data."

22. How should AI coding assistants change our AppSec approach?

Model answer: "Treat generated code as untrusted contributions: same review, testing and dependency checks. Watch for invented package names and outdated patterns, protect the assistant's tokens and configuration files, and make sure prompts do not carry secrets. Secure defaults in templates help the assistant as much as humans." See the AI-Assisted Code Review and AI SAST Guide.

Practical exercises panels use

Behavioural questions

• Tell me about a time a developer disagreed with your finding. Show how you checked your own reasoning, reproduced the issue safely and reached agreement or accepted you were wrong.
• Describe a fix that removed a whole class of bugs. A framework default, shared library or template beats a story about one ticket.
• When did you lower a severity or drop a rule? Panels want evidence you cut noise, not only that you add findings.
• How did you get a team to adopt threat modelling? Specifics: how short you kept it, who attended, what changed in their design.
• Tell me about a mistake in a review. Name what you missed, how it was found and what you changed in your process.

How to prepare

1. Re-read the current references: the Top 10:2025 list, the ASVS 5.0 chapter structure, SSDF practice groups, SAMM business functions, CVSS v4.0 nomenclature and the top of the 2025 CWE Top 25.
2. Practise code review in the employer's main language: review intentionally vulnerable training applications and open source pull requests, and write up findings as you would at work.
3. Threat model three systems aloud: a web application, an API with third-party integrations and a CI/CD pipeline, each in under 30 minutes.
4. Prepare two programme stories: one where you reduced risk measurably and one where you reduced developer friction.
5. Know the identity side: OAuth and OIDC flows, token validation, session handling and pipeline credentials, since these appear in most scenario questions.
6. Prepare questions for them: ratio of AppSec engineers to developers, who owns remediation, whether pipelines can block, and how risk acceptance works.

For hiring managers: a scoring rubric

Score each dimension independently before discussion, use the same exercises for every candidate at a level, and never set an exercise that asks candidates to attack a live system.

Framework mapping

Common failure patterns

• Answering with the 2021 Top 10: it signals the candidate has not kept up, and the 2025 changes are an easy follow-up question.
• Fixes that are really mitigations: "add a WAF rule" or "validate input" offered where a parameterised query or a server-side authorisation check is the actual fix.
• No prioritisation: treating every finding as release-blocking, which is the behaviour hiring managers most want to avoid.
• Ignoring identity: missing token audience checks, service-to-service trust and pipeline secrets in a threat model exercise.
• Offensive showmanship: describing exploitation in detail but having nothing to say about the fix, the test that prevents regression or the developer conversation.
• Interviewers testing trivia: panels that ask for port numbers and acronyms instead of setting a review or threat model exercise hire for memory, not judgement.

Practitioner checklist

• Learn the Top 10:2025 categories and be ready to explain what changed from 2021.
• Know the ASVS 5.0 chapter structure and how to turn requirements into tests.
• Name the four SSDF practice groups and the five SAMM business functions.
• Practise three threat models aloud using the four questions and STRIDE.
• Review at least two vulnerable code samples in the employer's language and write findings.
• Prepare a secrets exposure answer that starts with revoke and rotate.
• Explain CVSS v4.0 nomenclature and how you add exploitability and exposure context.
• Bring two measurable programme stories and a question about how risk acceptance works.

Standards and references

• OWASP: Top 10:2025
• OWASP: Application Security Verification Standard 5.0
• NIST: SP 800-218 Secure Software Development Framework 1.1
• OWASP: Software Assurance Maturity Model 2.0
• MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses
• Threat Modeling Manifesto
• OWASP: Secure Code Review Cheat Sheet
• FIRST: CVSS v4.0 Specification

Related NHI Mgmt Group resources: Application Security Guide · Application Security Engineer Career Guide · ISC2 CSSLP Certification Guide · Penetration Tester Interview Questions