Skip to content

How do you approach a secure code review?

Short answer

Start by understanding the app's threat model and where it handles untrusted input, secrets, authentication, and authorization. Use SAST to scan broadly and DAST against the running app, but treat tool output as leads, not findings — triage out false positives. Then spend human time on the high-value, context-dependent areas tools miss: authz logic, business logic, crypto usage, and trust boundaries. Trace data flow from source to sink.

Secure code review is where appsec earns its keep, because it can catch a flaw before it ever ships. Interviewers ask about it to see whether you can use tools as a force multiplier without confusing their output for the actual work — which is human judgment about context.

Start with context

Before reading code, understand the application: what does it do, what data is sensitive, and where does untrusted input enter? Lean on (or build) a quick threat model. This tells you where to spend your limited attention — there's no time to read everything with equal care, so you target the risky surface.

Tools: leads, not verdicts

  • SAST reads source statically and is great for breadth: hard-coded secrets, injection-prone sinks, unsafe deserialization, weak crypto APIs. But it produces false positives and cannot understand intent.
  • DAST exercises the running app from outside and confirms exploitability for whole classes of bugs, but has shallow code visibility.

Use both to generate leads, then triage. Filing raw SAST output as bugs is the fastest way to lose developer trust — every false positive you forward erodes it.

Where humans win

Spend manual effort on what tools structurally cannot judge:

  • Authorization logic — can user A reach user B's data? Tools see code, not the access-control intent behind it.
  • Business logic — abusing legitimate features (skip-the-payment-step bugs).
  • Cryptography usage — the right algorithm used wrongly (ECB mode, static IVs, home-rolled schemes).
  • Trust boundaries — where data crosses from untrusted to trusted, validate that it's actually sanitized.

The core technique is tracing data flow from source to sink: follow untrusted input from entry to the dangerous operation, checking every transformation along the way for validation and encoding.

What interviewers look for

They want threat-model-driven focus, SAST/DAST treated as leads needing triage, manual attention on authz and business logic, and source-to-sink data-flow reasoning — plus the empathy to protect the team's trust by filtering false positives.

Likely follow-ups

  • Why can't SAST reliably find broken access control or business-logic flaws?
  • What does 'tracing from source to sink' mean in practice?
  • How do you keep false positives from destroying the team's trust in your reviews?

Sources

Certifications

Get 100 cybersecurity interview questions + answers

Drop your email and we'll send you the free PDF pack and the flashcard deck.

No spam. Unsubscribe anytime.