Application Security interview questions
Application Security questions a Cybersecurity can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A teammate commits an API key “just for staging.” What do you do?
The strongest answer: Treat it as a leak: rotate the key, pull it from a vault or CI secrets, and assume the commit was copied — staging is not “fake enough”
Why it works: Exactly. A committed secret is public to anyone with the repo history. Rotate, do not decorate.
- Rotate the leaked key.
- Store secrets outside git.
- Staging is still a system.
- Do not encode and call it safe.
What is a threat model, in one sentence you would say in a room?
The strongest answer: Who might try what, on what, and what we already do — a short story, not a 40-page novel and not “we use HTTPS”
Why it works: Exactly. Actors, actions, assets, mitigations. Tools and quotes are inputs.
- Actor, action, asset, mitigation.
- Keep it short enough to use.
- HTTPS is one mitigation, not a model.
- A checkbox is not a story.
How do you use STRIDE without turning it into a homework novel?
The strongest answer: As a prompt on one feature: spoof, tamper, repudiate, info-leak, deny, elevate — write the two that are real, skip the empty boxes
Why it works: Exactly. A prompt, not a spreadsheet religion. Empty cells are honesty.
- Use STRIDE as a prompt.
- Write the real two.
- Empty is ok.
- Do not replace it with a CVE dump.
A GitHub Action prints the environment “for debug.” What do you fear?
The strongest answer: Secrets in the log — masked or not, I stop the print, rotate what might have appeared, and keep debug behind an allow-list
Why it works: Exactly. CI logs are a public-ish diary. Masking fails in pieces and concatenations.
- Do not dump env.
- Rotate if it might have printed.
- Masking is incomplete.
- Debug is allow-listed.
How do you keep tokens and card numbers out of logs as the app grows?
The strongest answer: A shared redaction library and a test that fails if a fixture token appears — I do not ask every squad to remember a regex
Why it works: Exactly. A library plus a test. Memory and docs fade. Encrypted PII is still PII for everyone with the key.
- Shared redaction library.
- A test on fixtures.
- Do not rely on memory.
- Encrypted dumps still need redaction.
Where does AppSec belong in a PR, without becoming a bottleneck?
The strongest answer: A lightweight checklist on risky changes (auth, money, PII) and a paved path for the rest — not a human on every typo
Why it works: Exactly. Risk-based gates. Humans on the money path; scanners and templates on the rest.
- Risk-based PR checks.
- Humans on auth / money / PII.
- Do not review typos.
- Do not scan only after prod.
Dependabot says a transitive library is critical. What do you check before you panic-merge?
The strongest answer: Whether the vulnerable function is reachable in our tree, then patch or mitigate — I do not ignore it because “we do not call it” without looking
Why it works: Exactly. Reachability is the grown-up question. Ignore-without-looking and forever-pins are how you get surprise RCE.
- Ask if it is reachable.
- Then patch or mitigate.
- Transitives count.
- Do not forever-pin to hide the alert.
A new “login with a magic link” ships Friday. What do you threat-model in 20 minutes?
The strongest answer: Who can request a link, where it is sent, how long it lives, and what a stolen inbox gets — write those four, then ship or slip
Why it works: Exactly. Four questions beat a novel. Magic links are credentials.
- Request, channel, lifetime, stolen inbox.
- Twenty minutes, written.
- Magic links are credentials.
- Do not novel the whole firm.
How do you keep new secrets out of git after one leak?
The strongest answer: Pre-receive or CI scanning plus a vault habit — I do not rely on “please remember” after a lunch-and-learn
Why it works: Exactly. A gate plus a place to put the secret. Training helps; it does not block a commit.
- Scan on the way in.
- Give people a vault.
- .gitignore is not enough.
- Do not rewrite history as a ritual.
How do you keep threat models from rotting after the launch review?
The strongest answer: Store them next to the service, update on auth or data-shape change, and let a PR lint ask “did you touch the model?” — not a SharePoint museum
Why it works: Exactly. A living note beside the code. Museums and slides are where models go to die.
- Keep the model with the service.
- Update on auth / data change.
- Lint the question.
- No SharePoint museums.
When does AppSec join a design, and when do they stay out?
The strongest answer: Join when identity, money, or a new interpreter of untrusted input changes — stay out of the button colour so you still have time for the join
Why it works: Exactly. Scarce humans on scarce risk. Everywhere is nowhere. After-the-fact is an autopsy.
- Join identity, money, interpreters.
- Skip the colour reviews.
- Do not sit in every standup.
- Do not wait for the pentest.
What does a secrets platform owe a squad on Tuesday?
The strongest answer: Mint, rotate, and inject without a ticket — plus a break-glass that is logged — a vault nobody can use is a shared Slack password
Why it works: Exactly. Self-serve plus audit. Lectures and week-long forms send people back to Slack.
- Self-serve mint and rotate.
- Logged break-glass.
- No week-long forms.
- No runbook passwords.
What is a secure-SDLC gate you can defend to a delivery director?
The strongest answer: A short, risk-based stop: secrets scan, dependency policy, and a threat note on auth changes — not a 40-item quiz on every PR
Why it works: Exactly. Fast, mandatory, risk-shaped. Optional-when-late is not a gate. Badges are marketing.
- Secrets + deps + threat on auth.
- Keep it short so it stays on.
- No optional-when-late.
- Badges are not gates.
How do you talk about supply-chain risk without a TED talk?
The strongest answer: Pin, verify, and minimise what runs in CI and prod — lockfiles, signed images when you can, and no curl-pipe-sudo in a setup script
Why it works: Exactly. Pins and fewer moving parts. Bans and folklore slides do not ship software.
- Pin what you run.
- Verify when you can.
- No curl | sudo.
- Do not ban OSS; constrain it.
You have forty minutes for a security review of a pull request. What do you look at, and what do you deliberately skip?
The strongest answer: The trust boundaries — where input arrives, where the authorisation decision is made, where queries and commands are built, and where secrets and output encoding live. I skip style and anything the linters and tests already enforce
Why it works: Exactly — reviewing by boundary is how a limited budget still finds the classes that matter.
- Review boundaries, not lines.
- Where does input arrive?
- Where is authorisation decided?
- Skip what tooling already checks.
SAST is noisy and DAST is late. How do you use both without a theatre stack?
The strongest answer: SAST on the PR for a small, owned rule set; DAST on a running preview for the money path — I do not enable every rule to “look mature”
Why it works: Exactly. Small owned SAST, scoped DAST. All-rules and prod-with-real-users are how you lose the room.
- Owned SAST rules on the PR.
- DAST on preview money paths.
- Do not enable everything.
- Do not DAST prod with real users.
What does a security champion owe their squad?
The strongest answer: The paved path and the two questions on a risky PR — not a second job as unpaid CISO and not a snitch rota
Why it works: Exactly. Leverage and coaching. Police and empty titles kill the program.
- Coach the paved path.
- Ask two questions on risky PRs.
- Not a snitch.
- Not an unpaid CISO.
How does AppSec scale past a heroic reviewer?
The strongest answer: Libraries, lints, and default-safe frameworks — the reviewer becomes a teacher of the road, not a gate on every PR
Why it works: Exactly. Leverage is the job. Hero review does not survive 40 squads.
- Ship default-safe paths.
- Lint the dangerous ones.
- Teach, do not bottleneck.
- Vendors are extra, not the memory.
A CFO asks why AppSec costs money if “the cloud is secure.” What do you say?
The strongest answer: The cloud secures the building; we secure the app, the identity, and the data — I will show the paved road, not a fear slide
Why it works: Exactly. Shared responsibility, in one sentence, plus a road. Invented stats and “because compliance” lose the grown-up room.
- Cloud ≠ our app is done.
- Show the paved road.
- No invented breach percentages.
- Do not cut gates to please a quarter.
Who owns “what we run” across 200 repos?
The strongest answer: A platform inventory with owners, plus a policy that CI cannot fetch unsigned latest — “everyone” owns it is how nobody does
Why it works: Exactly. Inventory, owners, and a CI policy. Wikis and unread SBOMs are furniture.
- Inventory with owners.
- CI cannot fetch unsigned latest.
- SBOMs must be used.
- No wiki-as-estate.
What does an AppSec platform team ship?
The strongest answer: Authn/authz libraries, secret injection, safe defaults, and a review path for exceptions — not a ticket queue that reviews every handler
Why it works: Exactly. The road. A human queue on every handler is the bottleneck you were hired to end.
- Ship libraries and defaults.
- Ship secret injection.
- Exceptions have a path.
- Do not become every handler’s reviewer.
Give the one sentence you want every squad to say about security platform.
The strongest answer: “I can get SSO, secrets, and a scoped token before lunch” — if they cannot, you built a review board, not a road
Why it works: Exactly. Self-serve before lunch is the bar. Queues and hope are how shadows start.
- Self-serve SSO, secrets, tokens.
- Before lunch, not a ticket.
- Do not be a review board.
- Do not make skip the escape.