Secure code review interview questions

Questions and answers

5 questions with model answers

Rewrite each answer in your own words before the loop — interviewers can tell a memorized paragraph from one you can defend under a follow-up.

1. Question 1

   How do you approach reviewing a codebase you have never seen?

   I map the attack surface before reading logic: entry points such as routes, handlers, message consumers, and scheduled jobs, plus where authentication and authorization are enforced. Then I work sink-first — query builders, template rendering, deserialization, file and process operations, outbound HTTP — and trace backwards to see whether untrusted input can reach them, because that is far faster than reading files in order. I check the cross-cutting layers next: dependency versions, secrets in configuration or history, error handling and what gets logged, and how sessions and tokens are managed. Throughout I note what the code assumes — that a caller already checked permissions, that an internal service is trusted — because broken assumptions are where the interesting bugs live.

2. Question 2

   What do you look for when reviewing a single pull request?

   First, whether the change moves a trust boundary: new endpoint, new parameter, new external call, or a change to who can invoke something. Then authorization specifically, since new endpoints routinely inherit authentication but forget the ownership check. I look at how input is validated and where it ends up, whether errors leak internal detail, whether anything sensitive is now being logged, and whether a new dependency was pulled in. Because a diff hides context, I make a point of reading the surrounding function rather than only the changed lines — plenty of vulnerabilities are introduced by a change that is fine in isolation and wrong given what the caller does.

3. Question 3

   Your SAST tool reports four hundred findings. What now?

   I do not hand that list to developers. I triage by rule class first, because a handful of noisy rules usually generate most of the volume, and I validate a sample of each class to judge precision before deciding whether to keep, tune, or disable the rule. Findings with genuine data flow from an untrusted source to a dangerous sink get priority over pattern matches on a function name. Then I fix at the source: many findings share one root cause, such as a helper that builds SQL by concatenation, so one change closes dozens. Going forward I would gate builds only on high-confidence rules, keep the rest as informational, and treat the false-positive rate as a metric I own — because a scanner that developers learn to ignore is worse than no scanner.

4. Question 4

   How do you write a finding the developer will actually fix?

   Lead with the evidence — file, line, and the path untrusted input takes to the dangerous operation — so it is verifiable rather than asserted. State the impact in terms of this application, not a generic description of the bug class: what an attacker gets, with what access, and against which data. Give a concrete fix, ideally as the code shape you want rather than a link to a standard, and note the tradeoff if the fix affects behavior or performance. Set severity honestly and be explicit about what you did not verify. Tone matters more than people admit: reviewing the code rather than the author is what keeps engineers reporting things to you instead of routing around you.

5. Question 5

   What bug classes will a scanner never find for you?

   Anything that depends on intent. Broken authorization is the biggest one — a tool cannot know that this endpoint should only be callable by the resource owner — and it is consistently the highest-impact web bug class. Business logic flaws are the same story: negative quantities, repeated redemption of a one-time discount, or a workflow step that can be skipped all look like correct code. Race conditions and time-of-check to time-of-use issues need concurrency reasoning tools rarely do well, and insecure design cannot be found in an implementation at all. That is the argument for human review and threat modeling alongside tooling, and it is usually the point the interviewer is fishing for.