The first time you correlate a real product's SBOM, the number is alarming — hundreds, sometimes thousands, of matched CVEs. The second realisation is more useful: almost none of them matter. The whole game is separating the few that do from the many that don't, and doing it in a way you can defend.
Where the noise comes from
A matched CVE is not a vulnerability in your product — it's a vulnerability in a component your product includes. Those are different claims, and the gap between them is where the noise lives:
- The vulnerable component is present but the vulnerable code path is never reached.
- The vulnerable feature isn't compiled in, or a config flag disables it.
- The path is reachable but an attacker can't control it into the vulnerable state.
- The match is simply wrong — a fuzzy name or version-range error.
Each of these is a legitimate reason a CVE doesn't apply — and each maps to a VEX not_affected justification, covered in how to justify a not_affected VEX.
Suppressing it safely
"Suppress" sounds like hiding. Done properly it's the opposite — it's making an explicit, recorded decision that a CVE doesn't apply, with the evidence attached. The mechanism is the two-stage determination: cheap reachability clears the bulk (unreachable → not_affected), and exploitation proof resolves the reachable-but-questionable cases. Nothing is dropped silently; a CVE the engine can't resolve is marked undetermined with a reason and kept in front of a human. The list gets shorter, not quieter.
Noise reduction the CRA accepts
Suppress by assertion and a regulator can unpick it. Suppress with evidence and the suppression is the defence.
This is the distinction that matters. The CRA doesn't forbid you from deciding a CVE is not_affected — it rewards it, because a vulnerability proven not to reach your product carries no reporting obligation. What it won't forgive is an unsupported suppression that turns out to be wrong on an actively-exploited flaw. Evidence-backed noise reduction cuts the list and leaves you defensible; assertion-based noise reduction cuts the list and leaves you exposed. Same shorter list, very different risk.
The metric to watch
If you're measuring your programme, two numbers tell the story: determination coverage (what share of matched CVEs got resolved to a status, rather than left undetermined) and reporting-load reduction (what share ended not_affected with evidence). Together they say how much noise you cleared and how confidently. They're the honest scoreboard for whether evidence-backed VEX — the pillar — is actually earning its place, and whether your reporting load is under control.
Frequently asked
How much of a matched CVE list is usually noise?
On a real product, the large majority. Most CVEs matched to components are not reachable or not exploitable in the specific build — wrong configuration, dead code path, a function never called. Industry experience with VEX and reachability puts suppressible, non-actionable findings at a substantial share of the total.
Isn’t suppressing CVEs risky under the CRA?
Suppressing them by assertion is risky; suppressing them with evidence is exactly what the CRA rewards. A CVE proven not to reach your product carries no reporting obligation, and the proof is your defence if an authority asks. The risk is in unsupported suppression, not in evidence-backed suppression.
Does cutting noise mean I might miss a real vulnerability?
Done right, no — nothing is dropped silently. Every matched CVE gets a determination: suppressed with evidence, escalated, or explicitly marked undetermined with a reason. Noise reduction narrows what needs human attention; it doesn’t hide anything.