Your SBOM is an inventory of what you ship. Correlation is what turns that inventory into a security picture — and, if you're not careful, into a wall of noise that buries the handful of things that actually need a decision. Under the CRA, getting from the noise to the signal isn't a nice-to-have; it's the difference between a manageable reporting obligation and an unmanageable one.
From inventory to matched CVEs
Correlation matches each component in your SBOM against known vulnerabilities. A component has a name and a version; a vulnerability record says which versions of which product it affects. Where they overlap, you get a match — a CVE tied to a component in a specific product version.
The output is a matched set: for each product version, the CVEs that touch its components, each one dated, attributed to its source, and deduplicated across sources. That set is the raw material for everything downstream. It is also, on a real product, alarmingly long — which is the whole problem this article is about.
The sources that matter
There is no single authoritative feed. Each source has a different remit, and correlating against one alone leaves gaps. Four matter for a CRA programme:
| Source | What it is | Why you need it |
|---|---|---|
| NVD | NIST National Vulnerability Database. CVEs enriched with CVSS scores and CPE identifiers. | The broad baseline — though it has had enrichment delays, which is why it can't be your only source. |
| EUVD | The EU Vulnerability Database, operated by ENISA. EU-relevant vulnerability information, aligned with the CRA and NIS2. | The European context, from the authority whose framework you're complying with. |
| OSV | Open Source Vulnerabilities. Package-ecosystem-native, keyed to purls. | The best coverage of open-source dependencies — most of a modern SBOM. |
| CISA KEV | Known Exploited Vulnerabilities catalogue. Vulnerabilities with evidence of exploitation in the wild. | The authority on active exploitation — the signal the CRA clock turns on. |
Correlate against all four, then deduplicate and attribute: the same underlying flaw can appear in several feeds under different identifiers, and you want one finding that remembers which sources flagged it, not four copies.
Getting correlation right
Naive correlation is where the noise comes from. Three things separate a matched set you can trust from one you can't:
- Precise identity. Match on a real identifier — a
purlfor packages, aCPEfor products — not on a fuzzy name. "log4j" matching a Go module calledlog4j-formatteris the kind of false positive that erodes trust in the whole list. - Version-range logic. A CVE affects a range of versions, not a point. Correct correlation understands that
< 2.17.1excludes the version you actually ship — and gets semantic-versioning edge cases right rather than string-comparing. - A dated snapshot. Vulnerability data changes daily. Every matched set should be timestamped to the data it was computed against, so a determination made on Monday is reconstructable on Friday.
Do this well and the list shrinks and steadies. Do it badly and every scan produces a different pile of maybes, and the team stops believing any of it.
CVSS vs EPSS vs KEV: three questions, not one
Once you have a clean matched set, you have to rank it — and this is where most prioritisation goes wrong, because three different signals get treated as if they measured the same thing. They don't.
| Signal | Question it answers | Scale |
|---|---|---|
| CVSS | How severe would this be if exploited? | 0–10 severity |
| EPSS | How likely is it to be exploited soon? | 0–1 probability |
| KEV | Is it being exploited right now? | Yes / no (evidence-based) |
A CVSS 9.8 that nobody is exploiting and nobody is likely to is a lower operational priority than a CVSS 6.5 that's in the KEV catalogue. Severity tells you the blast radius; it says nothing about whether the bomb is going off. EPSS (from FIRST.org) adds the missing dimension of likelihood, and KEV replaces prediction with observation: it's a record that exploitation has actually happened. Read together, they turn a flat list sorted by severity into a queue sorted by real risk.
Severity is how bad it would be. EPSS is how likely. KEV is that it's happening. Only the last one starts a reporting clock.
The signal that starts the clock
The CRA's reporting obligation is triggered by an actively exploited vulnerability — one for which there is reliable evidence that a malicious actor has exploited it in a system without authorisation. That is a specific, high bar, and it's worth being precise about what does and doesn't clear it:
- A newly published CVE, on its own — no.
- A public proof-of-concept exploit — no, not by itself.
- A high EPSS score — no; that's a prediction, not evidence.
- A listing in the CISA KEV catalogue, or comparable threat intelligence — yes, a strong signal that the bar is met.
The operational move that almost nobody has built is to wire that signal to a timer. The moment a component in one of your products crosses into active exploitation, a clock should start — automatically, auditably — rather than depending on someone noticing a KEV update. What happens next is the 24 / 72 / 14 reporting obligation.
From matched set to reportable risk
Here's the trap: active exploitation in the wild is necessary for a report, but it isn't sufficient. A vulnerability can be actively exploited somewhere and still not affect your product — because the vulnerable path isn't reachable, or can't be triggered in your context. The CRA obligation attaches to an actively exploited vulnerability that affects your product.
So the path from a matched set to a report has two gates, not one:
- Is it actively exploited? — the KEV / threat-intel signal. Starts the clock.
- Does it affect our product? — reachability and exploitation proof. Decides whether there's actually something to report, and backs the answer with evidence.
The first gate is correlation and monitoring, covered here. The second is the harder one, and it's where a matched CVE becomes a defensible determination — evidence-backed VEX. Correlation tells you what to look at; it doesn't tell you what matters. That's the layer above.
Common mistakes
- Sorting by CVSS alone. It buries the exploited 6.5 under a pile of theoretical 9s.
- One source only. NVD-only correlation misses open-source ecosystem coverage and EU context; KEV-only misses everything not yet exploited.
- Name-based matching. Fuzzy identity produces false positives that poison trust in the list.
- Treating a KEV hit as a report. Active exploitation starts the clock; it doesn't prove your product is affected. Both gates have to pass.
Frequently asked
What is the difference between CVSS, EPSS and KEV?
CVSS measures severity (0–10). EPSS estimates the probability of exploitation in the near term (0–1). CISA KEV records that a vulnerability is being exploited in the wild. They answer how bad, how likely, and is-it-happening — and only the last is the CRA reporting trigger.
What is the EU Vulnerability Database (EUVD)?
The EUVD is the European Union's vulnerability database, operated by ENISA. It aggregates EU-relevant vulnerability information and supports the CRA and NIS2 frameworks. For a CRA programme it is a first-class source to correlate against, alongside the NVD, OSV and CISA KEV.
Why correlate against multiple sources instead of just the NVD?
No single source is complete or perfectly timely. The NVD has seen enrichment delays, OSV covers open-source ecosystems best, the EUVD carries EU context, and CISA KEV is the authority on active exploitation. All of them together, deduplicated and attributed, give a more complete and defensible picture.
Does a CVE in my SBOM mean I have to report it?
No. A matched CVE is a candidate. The CRA reporting obligation is triggered by an actively exploited vulnerability that affects your product. A CVE that isn't being exploited, or doesn't reach your product, doesn't start the clock.