How to Run a Secure Code Review: What to Look for That Automated Tools Miss

Automated security tools are good at finding what they are designed to find: known vulnerability patterns, dependency version mismatches, common misconfiguration signatures. They are not good at understanding what an application is supposed to do and identifying where it fails to enforce that intent. Business-logic vulnerabilities, authorisation flaws tied to an application's specific data model, and race conditions in multi-step workflows require a reviewer who understands both what the code does and what the application should prevent.

A secure code review is a deliberate, security-focused reading of application code with the aim of identifying those vulnerabilities. It is distinct from a standard code review, which focuses on correctness, maintainability, and consistency with development standards. In practice, the two can be combined: a developer with security knowledge conducting a code review with security intent. The difference is having a framework for what to look for that goes beyond what a scanner has already checked.

What Automated Tools Miss

Static analysis tools work by pattern matching against known vulnerability signatures. A tool can reliably detect that a SQL query is being constructed by string concatenation with user-supplied input, because that is a recognisable pattern with a standard fix. It cannot detect that a multi-step order submission process allows an authenticated user to modify the price of an item at checkout by replaying a request from an earlier stage, because the vulnerability depends on understanding the intended business process and how the application's state machine is supposed to work.

Authorisation flaws are a consistent category of findings that automated tools handle poorly. Whether a specific user should be permitted to access a specific resource depends on the application's data model and access control design, not on recognisable code patterns. A reviewer who understands that the application has three user roles with distinct permissions can check whether the code enforces those boundaries at every access point. A scanner does not have that understanding. Insecure direct object reference findings, privilege escalation through parameter manipulation, and horizontal privilege escalation between accounts at the same permission level are all categories where human review reliably finds what scanners miss.

How to Structure a Secure Code Review

An effective secure code review starts with understanding the application's threat model before looking at the code. What data does the application handle? Who are the user types and what are they authorised to do? Which components handle external input? Which components have access to sensitive data or privileged operations? That context shapes where to focus the review: a reviewer who starts reading from the top of a file without that context will spend time on low-risk code and may miss high-risk areas entirely.

With that context established, the review should trace data flows from entry points to sensitive operations. Entry points are anywhere the application accepts external input: HTTP endpoints, message queue consumers, file uploads, API callbacks. The question at each entry point is whether the input is validated, whether it is sanitised appropriately before use, and whether access controls are enforced before any processing occurs. Tracing a specific input from receipt to eventual use in a database query, file operation, or external API call reveals where the validation and control enforcement actually is relative to where it should be.

Authentication and Session Management

Authentication and session management are areas where the gap between automated and human review is particularly significant. A scanner can check whether a library with known authentication vulnerabilities is in use. It cannot check whether the application's multi-factor authentication implementation correctly enforces the second factor before granting access to sensitive functionality, or whether a password reset flow is susceptible to account takeover through predictable token generation or token reuse. Those checks require reading the authentication code with knowledge of common authentication bypass patterns.

Session management findings are frequently about state that is trusted when it should not be. A session token that includes user role information which the application reads from the token rather than verifying against the database on each request is a privilege escalation vector if the token is modifiable. JWT implementation patterns are a consistent source of findings: algorithm confusion attacks, missing signature verification in some code paths, and claims that are trusted without checking whether they are current are all findings that come from reading the authentication code carefully rather than from running a scanner.

Making Secure Code Review Sustainable

Secure code review does not scale if it is positioned as a specialist activity that requires a security expert on every pull request. The sustainable model is developing a security-aware engineering culture where the people doing code reviews understand common vulnerability classes for their technology stack and incorporate security questions into their standard review practice. That development comes from training that is specific to the application's language, framework, and architecture, and from having a reference point, such as findings from previous penetration tests, that makes the relevant vulnerability classes concrete rather than abstract.

We build developer security training programmes from clients' actual penetration test findings, which means the training is calibrated to the vulnerability classes that are specific to their application. Teams we work with see finding recurrence rates below 15% on retests when that training is in place. To discuss what a secure code review programme looks like for your engineering team, contact us at info@cyberlinx.com.au.