There are five common kinds of code security audit: manual code review, automated static analysis, dependency and supply chain review, configuration and secrets review, and penetration testing against a running system. Each answers a different question, so the right mix depends on what you are trying to prove and how much code you have.
1. Manual code review
People read the code with attack scenarios in mind. It finds logic flaws that tools miss: broken authorization, unsafe business rules, missing checks. It is slow and depends on reviewer skill, so aim it at the riskiest parts: authentication, access control, payments, data export and anything parsing untrusted input.
The OWASP Code Review Guide exists for this work. It is a lab project, licensed under Creative Commons Attribution ShareAlike 4.0, and its repository is the place to read its scope.
2. Automated static analysis
Tools scan source or compiled code for patterns that signal flaws, such as injection or unsafe functions. They cover every line, run on every change and are consistent. They also produce false positives, and they cannot judge whether a check is correct for your business. Use them as a gate on every pull request and triage the results.
3. Dependency and supply chain review
Most of the code in a product is somebody else's. This audit lists the third party components, matches them to known vulnerabilities and licenses, and checks where they came from. NIST SP 800-218, the Secure Software Development Framework, includes practices on reviewing and securing third party software and on finding and fixing vulnerabilities in a repeatable way. Output should be an inventory plus a ranked list of fixes.
4. Configuration and secrets review
Code ships with settings, infrastructure definitions and sometimes hard coded keys. This review checks permissions, exposed ports, debug flags and committed credentials. It is quick and finds some of the worst problems.
5. Penetration testing
Testers attack the running application, using the same tools an attacker would. It shows what is actually exploitable and how flaws chain together, and it tests deployment details a code review cannot see. It samples, so it does not prove absence of flaws.
How does a standard help you scope?
OWASP's Application Security Verification Standard, currently version 5.0.0, is a list of requirements for building and testing secure web applications. Its stated aim is to normalize the coverage and rigor of verification. Choosing a target level and testing against its requirements gives an audit a defined scope, so the result can be compared over time and across applications.
Constructed example: a payments release
A team preparing a new payments feature chooses its audits by risk. Manual review for the authorization and refund logic, because a bug there costs money. Static analysis on every pull request for the whole codebase. A dependency review to confirm no library with a known exploited flaw reaches the build. A secrets check across the repository history. Finally a penetration test of the staging environment in the last two weeks before launch. None of the five alone would have covered all the risk, and none was oversized.
The release is invented to show the reasoning.
How do you choose?
Ask what you need to know. If you suspect logic flaws, read the code. If you need breadth on every change, automate. If a customer or auditor wants evidence, pick a standard and test against it. If you are worried about how pieces combine in production, test the live system.
Safeguard covers several of these through code scanning, dependency scanning with reachability, and secrets scanning, which suit the automated layers. Manual review and penetration testing still call for people.
How to check or apply this
- List the applications and rank them by data sensitivity and exposure.
- Pick a target standard, such as an ASVS level, for each tier.
- Automate static, dependency and secrets checks on every change.
- Schedule manual review for authentication, authorization and data handling.
- Commission a penetration test before major launches and annually for exposed systems.
- Track findings to closure with owners and dates.
- Re-audit after large changes.
Quick check
Is a static analysis scan the same as a code audit?
No. It is one type of audit. It will not find most logic flaws, and it does not examine how the system behaves in production.
How often should we audit?
Automate checks on every change, review risky areas whenever they change materially, and do a penetration test at least before major releases and on a regular schedule for exposed systems.
Sources
- OWASP Code Review Guide
- OWASP Application Security Verification Standard
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
