Home / Knowledge hub / False positive rate
Knowledge hub
False positive rate
How often a tool reports issues that turn out not to be real.
What it means
In security testing, the false positive rate describes how often a tool reports a problem that, when someone checks, is not actually there. In everyday use it is the share of reported findings that turn out to be wrong. Statisticians define it differently, so ask which one a vendor means.
A false positive is a false alarm. The scanner saw a pattern that looks like a flaw, such as an error message or a similar-looking response, and reported it without confirming that anyone could use it. The rate is how often that happens.
Why it matters
Every false alarm costs a person time to read, check and close. At scale it becomes a tax on the team. Developers who are sent ten wrong tickets stop trusting the eleventh, which may be the real one. Noise is how real findings get ignored.
It also distorts decisions. A report padded with unconfirmed items makes the application look worse than it is, wastes budget on non-issues and can fail a deal over a problem that does not exist. The cost of the rate is paid in time, trust and fixes that never happen.
How it shows up
Static tools that read code tend to report more doubtful items, because they cannot see how the running app behaves. Running scanners can report issues based on a response that merely looks suspicious. See false positive and its opposite, false negative. Tuning one usually moves the other.
When you compare tools, ask how the rate was measured, on what applications, and who judged the results. Vendor numbers are rarely comparable. A better check: take a sample of their findings on your own app and see how many hold up. Tools that confirm a finding before reporting it, with evidence of exploitation, cut the rate at source.
Questions people ask
False positive rate, answered
What is an acceptable false positive rate?
There is no standard number. A tool that finds a lot with half of it wrong may cost more than one that finds less and is right.
Judge by the time your team spends on each real fix.
How do you calculate it?
A common version is wrong findings divided by all findings reported. Statisticians define the rate against all non-issues instead.
Ask which definition is used, and apply the same one when comparing.
Can we lower it?
Yes. Tune rules for your stack, suppress confirmed noise with a recorded reason, give the tool valid logins, and prefer tools that verify before reporting.
Do not silence a whole class of results to cut noise.
Is a low rate always better?
Not alone. A tool that reports almost nothing has a very low false positive rate and a high rate of missed flaws.
Look at both, with coverage.
Why do scanners report false positives at all?
Because they judge by patterns in responses without knowing your business rules. A page that looks like an error may be harmless.
Verification by an exploit is the way around it.
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.
False negative
A real vulnerability that a test failed to find.
Finding triage
Sorting new findings into fix now, fix later, duplicate or not real.
Evidence of exploitation
The request, response and screenshot showing a flaw was truly used.
Finding deduplication
Merging reports of the same flaw so a team sees it once.
How much of the list is real?
If we did not break it, we do not report it. Each finding comes with the request, the response and the line of code, so your team starts from proof and not from a hunch. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.