Four Feeds, But Only One Starts the Clock
"Matches against OSV, NVD, CISA KEV, and ENISA EUVD" is a sentence that sounds like it needs a merge algorithm, some kind of weighted voting across four sources that all answer the same question. It doesn't work that way, because the four feeds don't answer the same question. Here's what each one is actually for, and where the line between "live today" and "not built yet" actually sits.
OSV is the default, and it's the only one queried automatically
OSV (Open Source Vulnerabilities, Google's database) is purl-native. A purl (Package URL, the pkg:type/name@version string that names a package unambiguously) goes in, matching advisories come back, no fuzzy matching required. That precision is why it's the primary path: every scan queries OSV by default, results get cached locally with ETags so the same purl isn't re-fetched needlessly, and nothing else needs to run for most components to get a real answer.
NVD only runs if you ask it to
NVD (the US National Vulnerability Database) predates purl-style identifiers. It indexes by CPE (Common Platform Enumeration), an older naming scheme that's broader but noisier, the kind of match where "close enough" sometimes means "wrong." Querying it by default for every component would trade OSV's precision for NVD's false-positive rate, so it doesn't run unless you explicitly ask for it with a CPE fallback flag. It exists to fill gaps OSV doesn't cover, not to double-check OSV's work.
CISA KEV is the one the CRA actually cares about
This is the feed most people would guess matters least, and it's the one that matters most for compliance specifically. CISA's KEV (Known Exploited Vulnerabilities) list isn't a vulnerability database the way OSV and NVD are. It's a curated list of vulnerabilities the US government has confirmed are being actively exploited in the wild, nothing more, nothing less.
That distinction is the whole story. The CRA's 24-hour reporting clock, the one we've written about at length, doesn't trigger on "your product has a known vulnerability." Plenty of CVEs sit in a product for years without triggering anything. It triggers on "actively exploited," and KEV is the closest thing to an authoritative, checkable answer to that specific question. A vulnerability can have a CVSS score of 9.8 and sit in OSV and NVD for months without ever landing on KEV. The day it does land there is the day the clock has a real chance of starting for you.
ENISA EUVD isn't a fourth feed yet
Here's the honest part. ENISA EUVD (the EU Vulnerability Database) gets named alongside the other three in our own materials because it belongs there conceptually, an EU-run equivalent matters for a regulation this EU-specific. But there's no code path for it today. It's a reserved row in the endpoint allowlist, not something bomwerk actually queries. Calling it a fourth feed before it exists would be exactly the kind of overclaiming we try not to do, so it isn't one, not yet.
The binary can't reach anywhere except this list
One more detail worth stating plainly, because it's a real security property, not a slogan. bomwerk's network layer isn't a general HTTP client that happens to be pointed at a few feeds. Every outbound host is a fixed entry in an allowlist, enforced before a socket ever opens, not just documented in a doc a security reviewer has to trust. A flag prints that exact list, so what a customer's security team is told and what the binary can actually reach can't quietly drift apart from each other. Abridged, from the open-source CLI:
$ bomwerk --endpoints
bomwerk makes outbound HTTPS requests to these hosts, and to no others.
OSV querybatch https://api.osv.dev/v1/querybatch
OSV query https://api.osv.dev/v1/query
NVD CVE API 2.0 https://services.nvd.nist.gov/rest/json/cves/2.0 (--cpe-fallback only)
crates.io, PyPI, RubyGems version APIs (--license-fallback only)
CISA KEV isn't in that list, because the open-source CLI never fetches it. The KEV catalog is pulled by the monitor in the Pro extension, whose build adds www.cisa.gov to the same allowlist and prints it the same way. There's no entry for ENISA EUVD in either. That's not an oversight in the printout, it's the printout telling the truth.
None of this is dramatic on its own. It's four names that get said in the same breath doing four different jobs, and one honest gap in a list that could have quietly pretended otherwise.
Not sure what your current SBOM is missing? We'll assess one repository across its supported ecosystems, explain the evidence gaps, and go deeper on C/C++ where the build context allows.
Get a free scan of one repo