False Positives vs False Negatives in Security Scanning

False positives in cyber security are alerts that flag something as a threat when it is not, and false negatives are real threats the tooling failed to flag at all; the first drowns your team in noise, the second is how breaches slip through undetected. Every scanner, SAST tool, SCA tool, IDS, and SIEM rule sits somewhere on the trade-off between them, and pretending you can drive both to zero is the fastest way to end up with tooling nobody trusts. The useful skill is deciding, per control, which error you can least afford and tuning toward it on purpose.

The Four Outcomes, Named

Any detector's result falls into one of four boxes:

• True positive: flagged, and it was real. The tool did its job.
• True negative: not flagged, and there was nothing to flag. Also correct, just invisible.
• False positive: flagged, but it was benign. Wasted investigation.
• False negative: not flagged, but it was real. A miss you may never learn about.

The asymmetry that matters: you see your false positives immediately (someone chases them and finds nothing), but you usually do not see your false negatives until they turn into an incident. That visibility gap warps intuition. Teams over-index on the noise they can feel and under-weight the misses they cannot, which is exactly backwards from a risk standpoint.

What Each Error Actually Costs

A false positive costs analyst time and, more corrosively, credibility. A vulnerability scanner that reports 400 "criticals" where 380 are unreachable, already-mitigated, or test-only will train developers to close the tab. That alert fatigue is itself a security failure: it is how the twenty real findings get ignored alongside the noise. The cost of false positives is rarely one wasted hour; it is the slow decay of the whole program's signal.

A false negative costs you the incident. A missed SQL injection, a vulnerable dependency the SCA tool never resolved, a malicious login the SIEM rule did not match. In cyber security, false negatives are the expensive errors because they are silent: no ticket, no alert, no metric moves, right up until exfiltration or a public CVE forces the discovery. The absence of alerts is not evidence of safety; it can equally be evidence of a blind detector.

So the honest framing of false positive vs false negative in cyber security is a cost comparison, not a quality score. Which mistake hurts more for this specific control?

The Trade-Off Is a Dial, Not a Bug

Nearly every detector has a sensitivity threshold. Turn it up and you catch more real threats (fewer false negatives) at the price of more noise (more false positives). Turn it down and the alert queue gets quiet, but real threats start slipping past. You are not choosing whether to have errors; you are choosing which kind.

The right setting depends on the stakes behind the control:

• Perimeter and pre-merge gates for critical assets: bias toward catching everything. A few extra false positives on a deploy gate for a payment service are cheaper than one shipped RCE. Accept the noise, staff the triage.
• High-volume, low-stakes telemetry: bias toward precision. An IDS on internal chatter that fires 10,000 times a day trains everyone to ignore it, so a noisy rule is worse than a slightly less sensitive one.
• Compliance and audit evidence: you often cannot tolerate false negatives at all, because "we didn't detect it" is not a defensible answer. Precision is a secondary concern.

Set the dial per control, and write down why. A threshold with no documented rationale drifts.

Tuning Without Lying to Yourself

Reducing false positives is easy if you are willing to raise false negatives, so any noise-reduction effort has to prove it did not just make the tool blind. Practical tactics:

1. Suppress with reachability, not blanket rules. For dependency findings, a vulnerability in a package you import but never call a vulnerable function from is a legitimate lower priority. Suppressing by reachability cuts noise without hiding exploitable issues. Suppressing by "we'll ignore this CVE ID everywhere" is how a real instance later gets silenced.
2. Track suppressions as debt. Every muted finding should have an owner, a reason, and an expiry. Permanent silent suppressions become permanent false negatives you built by hand.
3. Correlate signals. One weak indicator is a coin flip; three correlated ones are a real event. Correlation raises precision without lowering sensitivity, which is the rare win on both axes.
4. Feed triage outcomes back. Every "false positive, closed" and every confirmed hit is labeled training data for your rules and your prioritization. A program that never revisits its thresholds is running yesterday's trade-off.
5. Measure what you can. You can count false positives directly (triaged-and-benign over total alerts). False negatives are harder, but pen tests, red-team exercises, purple-teaming, and post-incident reviews are how you estimate the misses. Any program that reports only false-positive rates is measuring the easy half.

The SCA and Vulnerability-Scanning Angle

Dependency and vulnerability scanning is where this trade-off bites daily. Two failure modes:

• Over-reporting: flagging every CVE in the transitive graph regardless of whether the vulnerable code path is reachable, whether a fix is available, or whether the finding is in a devDependency that never ships. This is the false-positive-heavy tool that gets ignored.
• Under-reporting: incomplete transitive resolution, a stale advisory feed, or missing an ecosystem entirely, so genuinely vulnerable components never surface. These false negatives are the dangerous ones, and they are invisible precisely because the tool looks clean.

Good tooling attacks both: broad, accurate transitive resolution to shrink false negatives, and reachability plus fix-availability context to shrink false positives without suppressing real risk. An SCA tool such as Safeguard leans on reachability analysis for exactly this reason, so the queue reflects exploitable issues rather than the raw CVE count. When you are comparing scanners, the questions that matter are precisely these two: what does it miss, and how much of what it reports is noise. Run both against your own repositories rather than trusting benchmark numbers, because the trade-off is workload-specific. If you want to build the intuition further, our security fundamentals content covers detection tuning in more depth.

FAQ

What is a false positive in cyber security?

A false positive is an alert that flags benign activity or a non-exploitable finding as a threat. It wastes investigation time and, at volume, causes alert fatigue that leads teams to ignore alerts, including the real ones buried in the noise.

What is a false negative in cyber security?

A false negative is a real threat or vulnerability that the tooling failed to detect. It is the more dangerous error because it is silent: there is no alert to investigate, so the gap is often discovered only when it becomes an incident or a disclosed CVE.

Which is worse, false positives or false negatives?

It depends on the control's stakes. For gates protecting critical assets, false negatives are worse because a miss can mean a breach, so you accept more noise. For high-volume low-stakes telemetry, excessive false positives are worse because they destroy the signal and trust in the tool.

Can you eliminate both false positives and false negatives?

No. Most detectors have a sensitivity threshold where reducing one increases the other. The goal is to tune the trade-off deliberately per control, use correlation and reachability to improve both where possible, and measure both rather than optimizing only the visible false-positive rate.