What is a false positive in security scanning?
A false positive is a security finding that is wrong: the flaw is not present, not reachable, or not exploitable in context. Their real cost is not the wrong findings themselves but the triage time they consume and the trust they burn - developers stop believing a noisy tool, and then real findings get ignored too. Evidence-carrying findings, stable fingerprints, and gating only on new findings keep the cost near zero.
A false positive is a security finding that is wrong: the scanner reports a vulnerability that is not actually present, cannot be reached, or cannot be exploited in its real context. Every detection technology produces some; what separates usable tools from shelfware is how rare they are, how quickly a human can recognize one, and whether the same wrong finding ever has to be triaged twice.
What causes them
False positives come from a few recurring places:
- Pattern matching without understanding. A rule that fires on code that merely resembles a vulnerability will flag safe code that shares the shape. This is the biggest source, and it is a design consequence: matching spellings instead of tracking data flow trades correctness for rule-writing speed.
- Unrecognized sanitizers. The code cleans its input, but through a custom helper the engine does not model, so the engine reports the flow as unsanitized.
- Unreachable context. The vulnerable-looking code exists but cannot execute: dead code, a disabled feature flag, a component that never loads. Reachability analysis exists to demote exactly these.
- Version-level matching in SCA. A dependency version matches a CVE, but the vulnerable function is never called. Real component, real CVE, no exposure - which is what VEX statements were invented to record.
The real cost is process, not the finding
One wrong finding costs twenty minutes. The compounding costs are worse: teams re-triage the same wrong finding after every rescan because the tool keys findings to line numbers that shift with each refactor; and developers who meet enough noise stop trusting the queue, at which point real findings inherit the skepticism. Noise is how scanners lose the credibility that detection quality was supposed to earn - the full process argument is worth reading if this is your daily reality.
How mature tooling keeps the cost near zero
Four properties matter more than any advertised accuracy percentage:
- Evidence with every finding. A source-to-sink trace or captured request lets a reviewer confirm or dismiss in minutes. Findings that cannot explain themselves default to noise regardless of whether they are right.
- Stable fingerprints. Findings identified by content, not location, so a triage decision survives rescans, branches, and refactors. Decide once, permanently.
- Gates on new findings only. Builds fail on what a change introduced, not on the historical backlog, so noise never blocks unrelated work.
- Measured noise. The fraction of findings judged false, tracked per rule, so bad rules get fixed instead of quietly taxing the team forever.
The design stance behind low noise
The lowest-noise engines get there by construction rather than tuning: detection that reasons over program structure, rules gated against corpora of known-clean code before they ship, and honest confidence levels on findings instead of uniform certainty. That stance - precision as a contract, evidence as a default - is core to how the SecuNexa engines are built, and it is testable in an evaluation: run the tool on code you know is clean, and count.
Frequently asked questions
What is the difference between a false positive and a true-but-unimportant finding?
A false positive is factually wrong: the vulnerability is not there or cannot be triggered. A true-but-low-priority finding is real but does not matter much in context. They need different responses: false positives are suppressed with a justification and should drive tuning of the rule that produced them; low-priority findings stay in the queue and are ranked down by prioritization.
What is a false negative, and which is worse?
A false negative is a real vulnerability the scanner missed. False negatives are more dangerous because they are invisible; false positives are more corrosive because they are visible and expensive daily. A tool tuned to zero noise by disabling detection trades one for the other, which is why the honest goal is precision with evidence, not silence.
How do suppressions avoid becoming a way to hide real problems?
By requiring a justification, recording who made the decision, keying it to a content-based fingerprint so it applies only to that exact finding, and keeping suppressed findings visible under a filter rather than deleting them. A suppression done this way is an auditable decision, not a hidden one.