Secure code review is working if reviewers cover the risky code, most of their findings are real, the time spent produces fixes, and the trend over months points the right way. OWASP lists exactly these four measures. Track them loosely, because strict targets distort behaviour.
The four measures
The OWASP Secure Code Review Cheat Sheet names these security metrics for a review programme:
| Measure | OWASP wording | What to count |
|---|---|---|
| Coverage | Manual review coverage: percentage of critical code paths reviewed by humans | Critical paths with a recorded human review |
| Finding quality | Ratio of valid security issues to total findings | Confirmed findings divided by raised findings |
| Efficiency | Time spent on manual review vs. security value delivered | Hours spent against fixes made |
| Trend | Security posture improvement over time | Same measures, quarter on quarter |
Coverage: start with a list
You cannot measure coverage of "critical code paths" until you have named them. Make a short list: login and session code, anything that checks permissions, payment or personal data handling, file and parser entry points. Mark which ones have had a human security review and when.
Do not chase a percentage across the whole repository. A hundred percent of a logging library is worth less than half of your authorization layer.
Finding quality: protect the signal
If a quarter of what reviewers raise is wrong, developers learn to ignore reviewers. Count how many security comments led to a change versus how many were closed with "not an issue." A falling ratio is an early warning that comments are vague, reviewers lack context, or a tool is feeding noise into reviews.
When a finding is rejected, record why. The reasons teach you what to fix, whether the answer is better documentation, a clearer helper function or a reviewer briefing.
Efficiency: be honest about cost
OWASP frames it as time spent against security value delivered. Reviews that take hours and produce nothing are not proof of safety. They may mean the wrong people are reviewing, the changes are too large, or checks that a tool could do are using up human attention.
A useful side measure is the age of open review requests. Google's public guidance suggests a first response within one business day. Slow response times often cause teams to skip security review altogether.
Trend: compare like with like
Review each measure every quarter. Compare against yourself, not against another company. A new team will have low coverage. What matters is the line.
Measures that mislead
- Number of findings. More findings can mean better reviewing or worse code. It tells you neither.
- Comments per reviewer. Rewards noise.
- Approval speed alone. Fast approvals may be rubber stamps.
If you need one sanity check, sample ten approved pull requests a month and ask whether a reviewer actually read the risky lines. It is subjective, and it is more honest than any dashboard.
Try it yourself
Open the demo to see how security controls map to framework evidence. Use it to think about which of the four measures you could show an auditor today.
Click through it at your own pace, or open it full screen.
Quick check
What is a good finding quality ratio?
OWASP gives no target number. Watch the direction, and read the rejected findings to learn why they were rejected.
Do these measures need special tooling?
No. A spreadsheet with critical paths, review dates and outcomes is enough to start.
Sources
Last reviewed: 19 October 2026.
