First off, what exactly is a secure code review? It’s is essentially a code review (where application code is examined to identify potential issues, improve code quality, and ensure adherence to coding standards) with two specific outcomes in mind:
- Identify possible edge cases and vulnerabilities directly within the source code.
- Validate that security controls are coded properly as they were defined in the security design and requirements.
Crucially, secure code reviews are needed for the "unknown unknowns," business logic flaws, etc., which are difficult for pattern-based tools (e.g. SAST) to catch. SAST alone is inadequate because while the tools are great at covering known "bad" patterns and targeting specific types of vulnerabilities, SAST doesn’t validate the whole spectrum of security controls.
Seth Law of Absolute AppSec (and founder of Redpoint Security, Inc.) teaches a 2-day class on the subject, and we had him join the May 2025 edition of LeanAppSec Live to share some best practices.
You can watch the 30-minute session, including audience Q&A. To download his slides or see the full replay, register for the on-demand version.
Give adequate time
This isn't a quick scan; it's a thorough analysis. This kind of deep analysis requires sufficient time to understand the application, map its structure, brainstorm risks, and then meticulously review the code. Rushing through it means you're more likely to miss subtle flaws or misconfigurations that automated tools can't catch.
Work in small chunks
Looking at a huge codebase can feel like staring up at a mountain. Seth advises breaking it down, saying "Don't try to eat the whole elephant in a single go". The recommendation is to "Start broad, focus in on smaller snippets". Reviewing code in manageable pieces helps you maintain focus and prevents you from feeling overwhelmed, making the process more effective.
Stay on task
What's the objective? To identify potential security vulnerabilities and validate the correct implementation of security controls. It's easy to get sidetracked by things like code style or general bugs during a code review, but a secure code review has a specific security focus.
Don’t make it personal
This is so important for collaboration and a positive feedback loop. The review is about the code and its security posture, not about the developer who wrote it. Keep your feedback objective and focused on the technical aspects of the code's security implementation. This helps ensure that the findings are received as constructive feedback aimed at improving the software's security, rather than personal criticism.
Ask questions
Secure code review isn't a solo mission carried out in isolation: Don't hesitate to reach out to the developers or other team members for context and clarity. In fact, Seth suggests talking to the architects before beginning so you can find out what concerns they might have, and potentially save yourself a lot of time. Also, you'll often need clarification on how certain parts of the application work, why specific design choices were made, or how a particular security control is intended to function.
Documentation is your friend
Lean on any available documentation! Understanding the application's behavior profile and technology stack is part of the methodology. Documentation for the framework being used can tell you about built-in security features, and application-specific documentation can explain the intended functionality and how security controls were meant to be implemented. This information provides vital context and can save you time by explaining the "why" behind certain code structures or security control placements.
Build the code and run the tests
Building the code ensures you are looking at a compilable, potentially runnable version of the application. Executing the application's existing test suite can provide valuable insight into the code's intended functionality and expected behavior (even if tests might not be specifically focused on security). Understanding the normal operation of the code, as validated by tests, can help you identify where unexpected behavior might occur or where security logic might be missing or incorrect.
Technical skills needed for secure code reviews
In addition to non-technical skills of influencing and program management, a security engineer also needs application security and software development skills to be successful at secure code review.
Application security skills
Understanding of Application Security Concepts and Vulnerabilities: A fundamental skill is identifying possible edge cases and vulnerabilities in source code. This involves knowledge of a wide range of vulnerabilities, many of which align with the OWASP Top 10. Examples include:
- Injection (such as Cross-Site Scripting (XSS)
- XML External Entities (XXE)
- Redirects, and Server Side Request Forgery (SSRF)
- Identification and Authentication Failures (like User Enumeration, Session Management Issues, Authentication Bypass, and Brute-Force Attacks)
- Cryptographic Failures (such as Lack of Encryption, Improper Encryption, and Insecure Token Generation/Randomness/Validation)
- Security Misconfigurations (including insecure defaults, incomplete configurations, and Open cloud storage)
- Vulnerable and Outdated Components (any dependencies, libraries, services)
- Broken Access Control (Privilege Escalation, Missing Function Level Access Control, Insecure Direct Object Reference, and Mass Assignment)
- Security Logging & Monitoring Failures
- Debug Messages, Error Handling, and Information Leakage
Ability to Identify Business Logic Flaws: A security engineer needs to be able to identify "unknown unknowns" that are hard for pattern-based tools like SAST to catch, making human review crucial for their discovery. Identifying them requires understanding the application's intended behavior and its implementation in code.
Ability to Use Security Tools Effectively: While secure code review goes beyond automated scanning, it can be augmented by tools. Reviewers can leverage Static Analysis (SAST) and Software Composition Analysis (SCA). AI can also be used to augment manual code review by asking specific questions to speed up analysis.
Software Development Skills
Ability to Read and Understand Source Code: The core task is to review source code, and since the process should be language agnostic, security engineers need the ability to understand code in different programming languages.
Technical Proficiency to Build and Run Code/Tests: General principles for secure code review include building the code and running the tests, which will be easier for a security engineer who has done these tasks before.
