A false positive in vulnerability scanning is an alert about a problem that does not actually affect you, for example a flaw in code your product never runs. Scanners raise them because matching a component name to a flaw is easier than proving the flawed code is used.
Why scanners over report
A scanner reads your inventory and compares each component and version with a database of known flaws. If a match is found, it raises an alert. That check is fast and cautious. What it usually cannot see, without extra analysis, is whether your code calls the vulnerable function, whether the setting that makes it dangerous is on, or whether the component is even loaded in production.
What the noise costs
Every alert needs a person to look at it. Hundreds of alerts that go nowhere teach teams to ignore the list, and a real problem hides in the pile. For a manager the cost shows up as slow patching, tired engineers and arguments about priorities.
Three ways to cut it
| Method | What it asks | Result |
|---|---|---|
| Reachability analysis | Does our code reach the flawed part? | Removes unused findings from the top of the list |
| Exploitation evidence | Is it being used in attacks? | Raises the urgent few |
| Vendor statements | Does the supplier say the product is not affected? | Documents a reasoned "no" |
CISA describes VEX as an attestation about whether products are affected by known vulnerabilities, which is the formal way for a supplier to record that kind of answer. FIRST adds that severity scores alone do not measure risk.
Do not swing too far
Cutting noise is good. Dismissing alerts without a reason is not. Ask for a short written note on every finding closed as not applicable: what was checked, by whom, and when. That note is what an auditor or a customer will want later, and it lets the team revisit the decision when the code changes.
A metric worth asking for
Ask what share of serious findings end up being reachable in your products. A low number suggests the noise is high and the team could gain from better triage. A high number suggests the list is already well filtered, or that the code leans heavily on the flawed parts.
Where Safeguard fits
Safeguard produces SBOMs and scans dependencies, and its reachability analysis shows which findings your code actually uses. You can run a free scan on a repository to see an inventory for yourself.
Try it yourself
Toggle between all findings and reachable findings and note how the count changes and what stays at the top.
Click through it at your own pace, or open it full screen.
Quick check
Is a false positive the same as a false alarm?
In practice yes. It is an alert that does not need action in your context.
Can reachability analysis be wrong?
Any analysis has limits, such as code loaded dynamically. Keep a way to review and reopen decisions.
Sources
Last reviewed: 19 October 2026.
