Cut SBOM false positives in three steps: improve component identity in the SBOM itself, separate what ships from what only builds, and record each decision as an exploitability statement so it persists. Most noise starts upstream of the vulnerability matcher, in how the list was built.
Where do false positives come from?
An SBOM is a list. A scanner turns that list into findings by matching each component against vulnerability data. A bad finding comes from a bad match or a correct match that does not matter.
Weak identity. NTIA's minimum elements report lists the data fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp. The report notes that supplier and component names are human-readable strings, and that a component can have multiple names or aliases. When an SBOM has only a name and a loose version, a matcher may confuse two products with similar names or match the wrong version range.
Scope confusion. An SBOM that mixes build tools, test frameworks and runtime libraries produces findings for code that never reaches production.
Unused code. The component is present and the flaw is real, but your software never calls the affected function.
Stale data. A vulnerability database entry was corrected, or your SBOM predates the fix you already applied.
How do you fix identity?
Generate the SBOM from lockfiles and build output, not from guesses over a file tree. Include unique identifiers where your tooling allows, and use SPDX or CycloneDX, the formats the NTIA report points to for automation support. Regenerate the SBOM on every build so its timestamp and versions match what shipped.
Then check a sample. Take ten findings and confirm by hand that the component and version are what the SBOM says. If three are wrong, fix generation before tuning anything else.
How do you fix scope?
Tag components by role: runtime, build, test. Report findings for runtime components first and treat the others on a slower track. Where a component is in the SBOM only because a build tool pulled it in, say so in the SBOM or the policy, not in a mental note.
How do you record decisions so they stick?
CISA's VEX minimum requirements define a document that states, for a product and a vulnerability, a status: not affected, affected, fixed or under investigation. For not affected, it asks for a justification from a fixed list: component not present, vulnerable code not present, vulnerable code not in the execute path, or vulnerable code cannot be controlled by an adversary. The publication is dated 21 April 2023.
Use that vocabulary internally even if you never exchange a VEX document. A recorded decision with a justification and an owner survives the next scan. A decision kept in someone's head returns as a new alert every week.
Where does reachability help, and where does it not?
Reachability analysis asks whether a call path from your code reaches the vulnerable code. Safeguard's docs describe static, runtime and configuration based checks, with verdicts of reachable, conditionally reachable, unreachable and unknown. They also state limits: reflection, eval and unsafe dynamic dispatch give an unknown verdict, and data-driven vulnerabilities can still be exploitable when static analysis finds no path. Unknown stays flagged conservatively. Treat any reachability result as a ranking aid and check the stated limits for whichever tool you use.
Safeguard also rescores SBOMs on upload and hourly as feeds change, per its continuous scanning docs, which helps with stale data: a finding can drop when upstream data is corrected.
What are the honest limits?
You cannot get to zero. Some findings will be wrong and you will not know until someone checks. The goal is a list short and accurate enough that people read it, plus a record of every decision.
What to do
- Audit ten findings by hand and count the wrong matches.
- Generate SBOMs from lockfiles and build output on every build.
- Include supplier, version and unique identifiers in each component entry.
- Tag components as runtime, build or test and report them separately.
- Record each not-affected decision with a justification from the VEX list.
- Add reachability as a ranking input, with unknowns kept visible.
- Review recorded decisions when the component version changes.
Quick check
What is the fastest way to cut SBOM noise?
Separate runtime from build and test components, then check a sample of findings by hand for wrong matches. Those two steps often remove the largest block.
Do I need to publish VEX documents?
No. You can use the statuses and justifications internally. Publishing them helps customers who receive your SBOM avoid chasing alerts you have already resolved.
Sources
- NTIA: Minimum Elements for a Software Bill of Materials
- CISA: Minimum Requirements for VEX
- Safeguard docs: Reachability Analysis
- Safeguard docs: Continuous Scanning
Last reviewed: 18 October 2026.
