To cut SCA false positives, fix how packages are identified, record why a finding does not apply in a machine readable statement, check whether your code can reach the vulnerable function, and give every suppression an owner and an end date. Do not delete findings. Mark them with a reason so they can be revisited.
Why do false positives happen?
Two causes cover most cases.
Wrong identification. Some scanners match a library to a vulnerability record by name and version strings. OWASP Dependency-Check, for example, identifies libraries by matching them to CPEs, and its documentation says a finding can be wrong when an incorrect CPE is identified. That wrong match then brings in CVEs that do not apply to the library at all. Scanners that use package URLs from lockfiles avoid much of this.
Present but not exploitable. The library is really there and the vulnerability is real, but your code never calls the vulnerable function, the vulnerable feature is off, or a control blocks it. The tool is technically right and practically unhelpful.
What is VEX, and why does it help?
VEX stands for Vulnerability Exploitability eXchange. CISA's minimum requirements document describes it as a way to state whether a product is or is not affected by a vulnerability. A statement uses a status: not affected, affected, fixed, or under investigation. For "not affected" it should include a justification, or else an impact statement must explain why.
The point is to record the reasoning once, in a format tools can read, and share it with customers who ask. A note in a chat thread disappears. A VEX statement can travel with the software bill of materials.
How does reachability help?
Reachability analysis asks whether execution can get from your code to the vulnerable function. If it cannot, the finding drops in priority. This will not replace a human reviewing a critical case, and it can miss dynamic behavior such as reflection, so treat the output as ranking. Safeguard includes reachability analysis in its platform. Here is the exploitability view.
Open the full version at /demos/exploitability-check.
How do you suppress safely?
Suppression is where false positive work goes wrong. A blanket rule that ignores everything below a severity quietly hides real issues. Dependency-Check's suppression files show a better pattern: rules can target a specific file by hash or path, a specific CPE or CVE, and a rule can carry an "until" date after which it stops applying, so the suppression lapses and forces a second look.
Use that idea in any tool.
- Suppress the narrowest thing possible: one finding in one component.
- Write the reason and link the evidence.
- Name an owner.
- Set an end date, thirty to ninety days for most cases.
- Review expired suppressions in your weekly triage.
How will you know it is working?
Track three numbers per month: findings opened, findings closed as not applicable, and findings reopened after a suppression expired. If the reopened count is zero, your suppressions may be too broad or never reviewed. If most closed findings are not applicable, your matching needs work.
What to do
- Prefer scanners that identify packages from lockfiles and package URLs over name matching.
- Sample twenty recent findings and label each true or false, with the cause.
- Turn on reachability or exploitability data and use it to sort, not to delete.
- Record every not affected decision as a VEX style statement with a justification.
- Give each suppression an owner and an expiry date.
- Report the reopen rate monthly.
Quick check
Is an unreachable vulnerability a false positive?
Not exactly. The vulnerability is present but may not be exploitable in your use. Record it as not affected with a justification, and lower its priority.
Should I suppress all low severity findings?
No. Blanket rules hide real issues. Suppress narrow cases with a reason, an owner and an end date.
Sources
- OWASP Dependency-Check: suppressing false positives
- CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
Last reviewed: 18 October 2026.
