Home / Knowledge hub / False negative
Knowledge hub
False negative
A real vulnerability that a test failed to find.
What it means
A false negative is a real vulnerability that a test failed to find. The report comes back clean and the flaw is still sitting there. NIST defines it as a tool intended to detect something failing to do so.
Its opposite, a false positive, reports something that turns out not to be real. Both are wrong answers. They do not cost the same.
Why it matters
One false positive costs an engineer an afternoon. A false negative costs you a clean report that you then acted on, told a customer about, and used as a reason to stop looking. It is the more dangerous mistake and the harder one to measure, because proving what a test missed means already knowing what was there.
It should also change how you read any clean result. Nothing found means the checks that ran did not fire, on the paths they reached, with the logins they held. Without those three facts, a clean report is a sentence rather than an assurance.
How it shows up
Few tools publish their misses. Where numbers exist, they usually come from deliberately vulnerable practice applications such as OWASP's Benchmark, which says something about the tool and very little about your codebase.
Ask a vendor three questions: which classes do you not test for, what did you miss on your own benchmark, and how many logins did you use. A tool with one session cannot find a flaw that needs two accounts to demonstrate. Our benchmark publishes on 3 November 2026, misses included. Why we have no number yet.
Questions people ask
False negative, answered
What is the difference between a false negative and a false positive?
A false positive tells you something is broken when it is not. A false negative tells you nothing at all while something is broken.
You discover the first by investigating. You discover the second when somebody else finds the bug, which is usually a worse day.
How would we even know what our scanner missed?
You compare. Run a second tool with a different approach, have somebody test by hand, or check the last incident against what the tool said beforehand.
The cheapest version is to ask the vendor which vulnerability classes it does not cover at all. That list is the shape of your blind spot.
Why do vendors publish detection rates but never their misses?
Because misses sell badly and are easy to measure selectively. A score against a public benchmark of known bugs says how the tool does on that benchmark, not on your application.
The more useful question is which classes a tool cannot reach by design. That answer does not move with the test set.
Does a clean report mean we are secure?
It means the test found nothing within a scope, with a set of logins, against a list of checks. Ask for those three and the result becomes readable.
A clean report with no scope attached is a marketing document. A clean report with a scope attached is evidence.
How do we compare two testing tools honestly?
Give both the same application, the same credentials and the same time. Then count what only one of them found, and read those findings carefully.
Counting total findings rewards noise. The overlap and the misses are the interesting part of the comparison.
Sources
Where this comes from
Related
Terms that sit next to this one
False positive
A reported issue that turns out not to be real.
DAST
Tools that attack a running application from the outside.
Penetration test
A time-boxed engagement where skilled people attack your systems by hand.
Vulnerability
A weakness that somebody could use to cause harm.
Severity
How bad a finding is, from critical down to informational.
What did your last test miss?
Our benchmark publishes on 3 November 2026, misses included. Until then we say plainly which classes we test and which we skip. Ask us what we would not find in your application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.