How do you cut false positives in supply chain scanning?

You cut false positives in supply chain scanning by checking whether vulnerable code is reachable, recording a status such as not affected with a reason, fixing component matching errors at the source, and suppressing with an expiry date. Treat "unreachable" as evidence to record, not as a reason to ignore.

Where does the noise come from?

Three sources dominate. A library has a known flaw, but your code never calls the affected function. A scanner matches the wrong component, because names and versions are ambiguous. Or the same issue shows up several times, once per scanner.

Only the second is a true false positive. The first is a real vulnerability that does not matter to you today, which is a different claim and needs different evidence.

What does reachability analysis add?

Safeguard's documentation describes three kinds of reachability: static, from a call graph built from source, lockfile and bytecode; dynamic, from what loads at runtime; and configuration, from framework settings that show whether code is wired in. Findings are classed as reachable, conditionally reachable, unreachable or unknown, and unknown is treated as potentially reachable.

That last rule matters. Dynamic dispatch, reflection and native code defeat static analysis, so a tool that quietly calls everything uncertain "unreachable" will hide real issues. Ask any vendor how it treats the uncertain cases.

The same page combines reachability with exploitation signals, EPSS and CISA's Known Exploited Vulnerabilities list, and with runtime and business context. Use those for ordering, not for deleting.

How do you record "this doesn't affect us"?

CISA's minimum requirements for a Vulnerability Exploitability eXchange document define the elements for a VEX statement, which says whether a product is affected by a vulnerability. The OpenVEX specification gives concrete status values, including under_investigation, and justification labels for not affected findings: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path and inline_mitigations_already_exist. A not affected statement must carry either a justification or an impact statement, and an affected statement must say what to do.

The benefit is a record. Instead of a silent suppression, you have a dated, reasoned statement that a customer or auditor can read.

How do you fix matching errors?

When a scanner names a component you do not use, or a version you do not run, the cause is usually the inventory. Check that the lockfile is current, that build output matches the source, and that package identifiers are exact. Report persistent mismatches to the tool owner, and keep the fix in policy, not in one engineer's memory.

What are the limits?

Reachability can be wrong. A path unused today can be wired in next quarter, so rerun the analysis on change. Be wary of any claim of "no false positives". Verification, for instance of a leaked credential, reduces noise for that class but does not remove the need for review.

Never suppress a finding without an owner and an expiry date, and never use reachability to dismiss malware.

Try it in the exploitability check demo.

What to do

1. Count findings by source: duplicates, mismatches and real but unreachable.
2. Merge duplicates by choosing one scanner as the system of record.
3. Fix inventory errors at the source: lockfiles, build outputs and identifiers.
4. Turn on reachability, and ask how unknown cases are handled.
5. Record every not affected decision as a VEX statement with a justification.
6. Give every suppression an owner and an expiry.
7. Rerun after major dependency or code changes.

Quick check

Sources

• Safeguard docs: Vulnerability Prioritization and Reachability, fetched 18 October 2026
• CISA: Minimum Requirements for VEX, fetched 18 October 2026
• OpenVEX specification, fetched 18 October 2026

Last reviewed: 18 October 2026.