A true positive in cyber security is an alert or scan finding that correctly identifies a real vulnerability, malicious action, or policy violation — the thing the tool says is happening is actually happening. A false positive is the opposite: the tool fires, but there's nothing there. It sounds like a simple distinction, but it's the single biggest lever on whether a security team spends its day fixing real problems or filing tickets nobody will ever act on. Get the ratio wrong and it doesn't matter how good your underlying detection logic is — analysts stop trusting the queue, or worse, stop reading it.
What actually counts as a true positive versus a false positive?
A true positive is confirmed: the CVE is in a library your code actually calls, the login attempt really did come from a compromised credential, the exposed S3 bucket really is public and really does contain customer data. A false positive is a match on paper that doesn't hold up under scrutiny — a vulnerable function flagged in a dependency your application never imports, a WAF rule tripped by a legitimate query string, a login flagged as anomalous because someone traveled and logged in from a new city. Two related terms round out the matrix: a false negative is a real problem the tool missed entirely (the most dangerous outcome), and a true negative is the tool correctly staying quiet. Vulnerability scanners in particular struggle with the true-positive/false-positive line because most operate on version matching alone — if a CVE exists in lodash 4.17.15 and you have that version installed, the scanner reports it, whether or not your code path ever reaches the vulnerable function.
Why does the false-positive rate matter more than raw finding counts?
Because analysts have finite attention, and every false positive spent on triage is attention not spent on the true positive sitting three rows down the same queue. This is the mechanism behind alert fatigue: research on SOC operations has repeatedly found that teams facing high false-positive rates start batch-closing or ignoring alerts, and the practice generalizes badly — real incidents get closed alongside the noise. A vulnerability scanner that reports every version-matched CVE without checking reachability can produce findings where fewer than one in five are things an attacker could actually exploit in your running application. That's not a minor inconvenience; it's a queue where the signal-to-noise ratio guarantees some real issues get missed, because nobody has time to read all of it carefully.
How do you reduce false positives without creating false negatives?
You add context before you cut volume, not the other way around. The naive fix — turning down scanner sensitivity or suppressing whole rule categories — trades false positives for false negatives, which is a worse trade. The better fix is layering context onto each finding: reachability analysis (does your code actually call the vulnerable function), exploitability data (is there a known public exploit, is the CVE in CISA's Known Exploited Vulnerabilities catalog), and runtime evidence (did this pattern actually execute, not just appear in a scan). Static analysis tools that only pattern-match source code tend to run hotter on false positives than tools that combine static findings with dynamic confirmation — this is part of the reasoning behind pairing SAST and DAST rather than relying on either alone, since a dynamic test that actually triggers the vulnerability is much harder to argue with than a static match.
What does a mature true-positive rate look like in practice?
It looks like a queue where nearly everything that lands in front of an analyst is worth their time, and it's earned through tuning, not luck. Mature security programs track precision (the share of flagged findings that are true positives) as deliberately as they track coverage, because a program that only measures "number of vulnerabilities found" has an incentive to over-report. Teams that get this right usually combine several signals before a finding reaches a human: static match plus reachability plus a check against exploit databases plus a confidence score, so that low-confidence, single-signal findings get triaged automatically rather than routed to a person. The goal isn't zero false positives — that's not achievable with any detection method — it's a rate low enough that the team's default response to an alert is "investigate," not "probably nothing."
FAQ
Is a false positive the same as a false negative?
No. A false positive is a finding that fires but isn't real; a false negative is a real problem the tool failed to detect at all. False negatives are generally considered more dangerous because they create a false sense of security.
What's a healthy false-positive rate for a vulnerability scanner?
There's no universal number, but the goal is a rate low enough that analysts don't start ignoring the queue. Reachability-aware scanning typically cuts unactionable findings substantially compared to version-matching alone, because most CVEs in a dependency tree are never invoked by the application's actual code paths.
Does reducing false positives risk missing real vulnerabilities?
It can, if you reduce them by lowering sensitivity or suppressing categories outright. It doesn't, if you reduce them by adding confirming context — reachability, exploitability, runtime evidence — before deciding what to suppress.
How does alert fatigue connect to false positives?
High false-positive rates train analysts to treat alerts as noise, which generalizes to real alerts getting the same dismissive treatment. It's a behavioral problem caused by a technical one, and the fix has to address both.
What exactly is a true negative in cyber security?
A true negative in cyber security is the tool correctly staying silent — no vulnerable code path, no malicious login, no policy violation, and the scanner or detector reports nothing. It's the least visible outcome of the four (true positive, false positive, false negative, true negative), precisely because a correct absence of an alert never shows up in anyone's queue, but it's the outcome a well-tuned detection stack produces most of the time.
How Safeguard Helps
Safeguard layers reachability analysis on top of version-matched vulnerability data so findings are ranked by whether your code actually calls the vulnerable function, not just whether the package is present — cutting the false-positive load that drives alert fatigue. Combining SCA with SAST and DAST results lets Safeguard cross-confirm findings across static and dynamic evidence before they reach an analyst's queue, so the true positives that do land are worth acting on immediately.