A true positive is a real vulnerability the scanner reports. A false positive is a report of something that is not a vulnerability. A false negative is a real vulnerability the scanner misses. A true negative is correct silence. Scanners trade the second and third against each other.
The four outcomes
| Real issue exists | No real issue | |
|---|---|---|
| Scanner reports it | True positive | False positive |
| Scanner is silent | False negative | True negative |
Developers feel false positives because they must read each one. Attackers benefit from false negatives because nobody reads them at all. A tool tuned only to remove noise often creates more of the second kind.
A worked example
Suppose a code base has 20 real injection flaws and a scanner reports 50 findings. Of those, 15 are real and 35 are not.
- True positives: 15.
- False positives: 35.
- False negatives: 5, the real flaws it missed.
Precision is the share of reports that are real: 15 of 50, which is 30 percent. Recall is the share of real flaws found: 15 of 20, which is 75 percent. These numbers are invented for illustration only, to show the arithmetic. They do not describe any real tool.
Why both measures matter
Precision tells you how much time triage will waste. Recall tells you how much risk remains. OWASP lists a high number of false positives as a core weakness of source code analysis tools and also says current tools can automatically identify only a relatively small percentage of application security flaws. It names accuracy, measured by false positive and false negative rates, as a selection criterion, and points to the OWASP Benchmark for measuring it.
How to measure on your own code
- Pick a sample of findings, not all of them. For sample size reasoning see sample size to estimate a false positive rate.
- Have two people classify each as true or false, and resolve disagreements.
- For recall, plant known bugs. Test a SAST tool with seeded bugs explains how.
- Repeat after tuning to see whether you gained precision at the cost of recall.
Common mistakes
- Reporting only the false positive rate. A tool that finds nothing has none.
- Counting a duplicate of a real finding as a separate true positive.
- Counting a real but low value finding as a false positive. It is true, just unimportant. Use a separate status, see false positive, accepted risk or won't fix.
Try it yourself
Open the demo and look at which scan findings you would classify as real and which you would question.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers reachability analysis to help separate findings that matter from those that do not. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Which is worse, a false positive or a false negative?
It depends on the stakes. False positives cost time. False negatives cost security. Most teams accept some of the first to reduce the second.
Can a scanner have zero false positives?
Only by reporting very little, which raises false negatives. Be sceptical of a claim of zero.
Sources
Last reviewed: 19 October 2026.
