false positive vulnerability alerts: how to confirm

TL;DR

Most scanner false positives come from sloppy version matching, not real bugs. Before you dismiss an alert, prove it is wrong three ways: the version match is stale, the vulnerable code never runs in your build, or your config already neutralizes it. Document the proof, then dismiss.

false positive vulnerability alerts: how to confirm

Use this when

• A scanner flags a CVE that does not smell right for your stack
• You want to dismiss an alert and need evidence it is safe to do so
• An alert survives a patch and you suspect the scanner is wrong, not the fix
• Your team keeps getting the same alert and you want to kill it permanently

Not for

• Alerts you plan to patch (thats the real-vuln path)
• Tuning scanner rules or writing custom scan policies
• Alerts from SAST findings on your own code (different verification)

Steps

1. Check the version range against your actual resolved version.

The advisory lists affected versions. Compare against your lockfile, not your manifest, because manifests lie and lockfiles dont. If your resolved version is outside the range, the scanner matched stale data.

Expected: a definitive in-range or out-of-range answer.

2. Check whether the vulnerable code actually ships and runs.

Find where the flagged package is used. Dev-only, test-only, or pulled in but never imported all count as not reachable. Grep for imports and check the production bundle.

Expected: a yes or no on reachability, with the evidence noted.

3. Check whether your configuration dodges the flaw.

Some CVEs only trigger under specific configs (a feature enabled, a flag set, a protocol in use). If your config never hits the trigger, the flaw is inert in your deployment.

Expected: config compared against the advisorys trigger conditions.

4. Cross-check with a second source.

Run the package through another database (the OSV record, the NVD entry, or a second scanner). If two independent sources disagree with the first, the first is probably wrong.

Expected: agreement or a documented disagreement with reasons.

5. Dismiss with the proof attached.

Write the three checks into the dismissal note: version evidence, reachability evidence, config evidence. Future you will thank present you when the alert resurfaces.

Expected: alert dismissed with a note anyone can re-verify.

Variant phrasings

Scanner flagged a CVE but I think its a false positive

Work the three checks in order: version range, reachability, config. Most false positives die at step one.

How to tell if a Dependabot alert is wrong

Same process. Dependabot is the noisiest offender on version matching because it reads the manifest graph, not the lockfile.

Alert keeps coming back after I dismissed it

Your dismissal lacked evidence or the scanner re-matched on a lockfile change. Re-run the checks, attach the proof, and check whether your lockfile regenerated with a different version.

Why it happens

Scanners match advisory version ranges against dependency metadata, and that matching is approximate: manifests vs lockfiles, backported fixes that keep old version numbers (Linux distros and some vendors do this constantly), and advisory ranges that lag the actual fix. The scanner errs on the side of flagging, so the false positive is a feature of its design, not a bug you can eliminate.

Edge cases

• Vendor backports: Red Hat, Debian, and others patch CVEs without bumping the version number. Your scanner flags the old version while the distro package is actually fixed. Check the distros security tracker, not the version string.
• Vendored or forked code: if you vendor a library, scanners match the vendored version against public advisories and often get it wrong. Check the actual vendored code.
• Reachability is ambiguous: when you cant prove unreachable, dont dismiss. Treat it as low priority and patch on the normal cycle instead.
• Scanner disagreement with no tiebreaker: escalate to the advisory itself and the actual code diff of the fix. The code is the final authority.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8ljSweKmUaZCcKQR-IIe1w