The short answer: a false positive is when a security tool raises an alarm about something that is actually safe, and a false negative is when it stays silent about something that is actually dangerous. A false positive is a false alarm that wastes attention; a false negative is a missed threat that can get you breached. Every detection system trades one against the other.
These terms trip people up because the words "positive" and "negative" feel backwards in a security context. A "positive" result sounds good, but here it means the tool flagged a problem, and a "false" positive means that flag was wrong. Once you internalize that "positive equals the alarm fired" and "false equals the alarm was mistaken," the rest follows. Understanding this pair is essential to reading any scanner, test, or detection report without being misled by the numbers.
What Is a False Positive?
A false positive is a false alarm: the tool reports a vulnerability, threat, or match that is not really there. A vulnerability scanner flags a library as exploitable when the vulnerable function is never actually called. An intrusion detection system alerts on normal traffic that happens to resemble an attack. A spam filter quarantines a legitimate invoice.
False positives are annoying rather than catastrophic, but they carry a real cost. Every false alarm consumes an analyst's time to investigate and dismiss. Worse, a flood of them causes alert fatigue, the state where teams start ignoring or auto-closing findings because most turn out to be noise. That is dangerous, because buried in the noise there may be a genuine alert that now gets dismissed along with the rest. High false-positive rates quietly erode trust in a tool until people stop looking at it.
What Is a False Negative?
A false negative is a miss: something dangerous is present, but the tool says nothing. The scanner does not detect a real vulnerability, the antivirus lets malware through, the test suite passes while a security flaw ships to production. Where a false positive is a fire alarm going off with no fire, a false negative is a fire with no alarm at all.
False negatives are the more dangerous failure mode because they are silent. Nobody investigates an alert that never fired. A real vulnerability that a tool failed to catch can sit undetected for months, giving attackers exactly the opening they need. The hard part is that false negatives are difficult to measure: you often only discover them after an incident, or during a manual review that finds what the automation missed. A tool reporting "no issues" is not the same as there being no issues.
Side-by-Side Comparison
| Aspect | False Positive | False Negative |
|---|---|---|
| What happened | Alarm fired, but nothing was wrong | Something was wrong, but no alarm |
| Nickname | False alarm | Missed threat |
| Primary cost | Wasted time, alert fatigue | Undetected breach, silent risk |
| Visibility | Obvious, you see the alert | Hidden, you see nothing |
| Who feels it | Analysts and developers | The whole organization, later |
| Reducing it tends to | Increase false negatives | Increase false positives |
| Worst outcome | Real alerts ignored in the noise | Attack succeeds unnoticed |
When to Care About Each
Care about false positives when your team is drowning in findings and losing faith in the tooling. If developers routinely dismiss scanner output without reading it, or analysts spend most of their day closing tickets that turn out to be nothing, your false-positive rate is the bottleneck. Reducing noise here is not about being lazy; it is about preserving the attention needed to act on the findings that matter.
Care about false negatives when the cost of a miss is severe, which in security it usually is. High-stakes environments, such as anything handling payments, health data, or critical infrastructure, generally prefer to tolerate more false positives in exchange for fewer misses, because an investigated false alarm is recoverable while an undetected breach may not be. The right balance depends entirely on what a miss would cost you.
How They Fit Together
False positives and false negatives are two ends of the same dial, and you cannot drive both to zero at once. Make a detector more sensitive so it catches more real threats, and it will inevitably flag more innocent things too, raising false positives. Make it more conservative so it stops crying wolf, and it will start letting subtle real threats slip past, raising false negatives. This trade-off is fundamental to every classifier, from spam filters to vulnerability scanners.
The goal, then, is not perfection but a deliberate balance suited to your risk tolerance, plus techniques that improve both sides at once rather than just sliding the dial. Reachability analysis, for instance, cuts false positives in dependency scanning by checking whether vulnerable code is actually invoked, without missing genuinely reachable flaws. Correlating multiple signals, or using AI to triage and explain findings, can raise real detections while suppressing noise. The mature move is to measure both rates honestly, tune the balance for your context, and invest in methods that shrink the trade-off rather than pretending it does not exist.
Frequently Asked Questions
Which is worse, a false positive or a false negative?
It depends on context, but in security a false negative is usually the more feared outcome because it is silent and can lead directly to a breach. That said, a tool with so many false positives that people ignore all its output effectively produces false negatives too, because the real alerts get lost. Both failure modes ultimately let threats through.
Why can't a tool just eliminate both?
Because sensitivity is a single dial with two ends. Catching more real threats means accepting more false alarms, and cutting false alarms means missing more real threats. You can shift where the balance sits and use smarter analysis to improve both somewhat, but no detector achieves zero of each on messy real-world data.
What is alert fatigue and how does it relate?
Alert fatigue is what happens when a high false-positive rate trains people to stop paying attention. When most alerts are noise, teams start dismissing them reflexively, and eventually a genuine alert gets dismissed along with the junk. So an excess of false positives can quietly cause the very misses that false negatives describe.
How does reachability analysis help?
Reachability analysis checks whether a vulnerable piece of code can actually be executed in your application. A vulnerability in a dependency you never call in an exploitable way is a likely false positive, so filtering by reachability removes noise without hiding the vulnerabilities that your code genuinely exposes.
Tuning the signal-to-noise ratio in your own scanning? Safeguard's SCA product uses reachability analysis to cut false positives without hiding real risk, our Griffin AI triages and explains findings to reduce noise, and our DAST product confirms exploitability in running apps. Explore the ideas in our concepts library, and if scanning is new to you, the Safeguard Academy starts from the basics.