Where our data comes from
Every euvex verdict rests on a public, named source. Here are which ones, what they cover, and what they do not cover.
OSV · Open Source Vulnerabilities
Known vulnerabilities
What it is.
An open database of vulnerabilities in open source components, maintained by Google and fed by the ecosystems themselves: GitHub Security Advisories, npm, PyPI, Go, Rust, Debian advisories and others. It is queried by purl (the universal package identifier), so the match is exact, not an approximation by name.
How euvex uses it.
Each component of your inventory is sent to api.osv.dev at scan time, then at every daily recheck. The advisories returned are kept in the revision: that is what makes it possible to say later that a vulnerability is new.
What OSV does not cover
“No known vulnerability” therefore does not mean “no vulnerability”. The word known does all the work, and that is why it is written everywhere in the product.
Above all: the identifiers OSV cannot resolve
pkg:generic/openssl@3.0.11 returns no advisory, while pkg:deb/debian/openssl@3.0.11 returns seventy, for the same OpenSSL, in the same version.Yet
pkg:generic and pkg:conan are what Yocto, Buildroot and conan produce by default, in other words the embedded build chains. A firmware SBOM uploaded as it is may therefore have no component that can be queried.euvex does not count these components as clean: it marks them “not analysed”, shows the coverage ratio N of M, and refuses to conclude that there is no vulnerability as long as a single component of the product could not be queried. Nor do we try to fill the gap by matching components by name: measured too,
openssl at version 9.9.9, which does not exist, returns 267 “vulnerabilities”, eighteen distributions each answering with their own version bounds. An honest silence is worth more than noise presented as a verdict.If your chain can emit distribution purls, that is the setting that most changes what euvex can see of your product.
NVD · National Vulnerability Database
Known vulnerabilities · by CPE
What it is.
The vulnerability database of NIST, the US standards institute. It is queried by CPE, the other major component identifier, the one that can name software that is no ecosystem's package.
Why a second source.
Because OSV is queried by purl and does not index pkg:generic, which is what Yocto, Buildroot and conan produce. In other words, the build chain of a firmware. Without this source, the SBOM of an embedded product has no possible answer, and euvex can only say that it could not look.
How euvex uses it.
Only for the components OSV cannot resolve: two sources on the same component would produce two advisories for the same flaw, under two identifiers. When your SBOM declares a CPE, yours is the one queried, wildcards included (Yocto writes cpe:2.3:*:*:openssl:3.0.11), and up to four per component. Otherwise, euvex asks the question with an unknown vendor rather than guessing one. The pass runs in the scheduled monitoring, not at upload: the NVD answers one component at a time. A freshly uploaded firmware therefore comes back every ten minutes until each component has been asked, for forty-eight hours at most, then every day.
What to know
pkg:deb/debian. The scopes differ, a distribution adding its own fixes. One figure is therefore not the correction of the other.Some old records name a product without bounding the affected versions. euvex sets them aside: keeping them would flag a 2009 vulnerability on a version released fifteen years later.
An empty answer does not always mean “nothing affected”. When the NVD knows no product by that name in its dictionary, such as
linux-yocto, the component stays “not analysed”: it needs a CPE with the name the NVD uses, here linux_kernel.euvex reads two hundred advisories per component. The Linux kernel goes far beyond that count, 5,487 for a version 6.6.21 recorded on 30.10.2026: the file then says how many the NVD announces, and separately takes up all those in the KEV catalogue, the ones euvex cross-checks to open an Article 14 case.
Notice required by the API terms of use: “This product uses the NVD API but is not endorsed or certified by the NVD.”
EUVD · ENISA's vulnerability database
The European reference
What it is.
The vulnerability database of the European Union Agency for Cybersecurity. Each flaw there carries its own identifier, of the form EUVD-2021-34768.
What euvex does with it.
It cites it. Each vulnerability found by the previous sources is translated into its European identifier, shown next to the American identifier in your file. Your report thus carries the Union's reference, not only that of the United States.
What euvex does not do with it, and why
openssl returns 227 results, the first of which concerns openssl_encrypt, another piece of software. And specifying the version changes nothing: version 3.0.11 and a version 9.9.9 that does not exist return exactly the same 227 results.Using it to match a component would therefore be guessing. A source that is cited is not a source for decisions, and confusing the two would be the very flaw this whole page exists to avoid.
It also publishes an EPSS score, the probability that a flaw will be exploited. euvex does not read it. The trigger of Article 14 is “actively exploited”, an established fact; a probability is not one. The same reasoning ruled out the CVSS severity.
CISA KEV · Known Exploited Vulnerabilities
Active exploitation · Art. 14
What it is.
The catalogue of the US cybersecurity agency that lists actively exploited vulnerabilities, those whose real exploitation has been observed, not merely assumed possible.
Why that one, and not the severity.
Because it is the predicate of the text. Article 14 of the CRA triggers the reporting obligation on “actively exploited”, not on “severe”. A vulnerability with a CVSS score of 9.8 that is never exploited triggers nothing; a vulnerability with a medium score, actively exploited, triggers everything. Using severity as the trigger would have been simpler, and legally wrong.
How euvex uses it.
The catalogue is fetched from cisa.gov. At each recheck of a scan, the vulnerabilities found in your components are looked up in it, in a copy of the catalogue refreshed every six hours; a match opens a reporting case and starts the deadline countdown. An entry CISA has just added may therefore wait up to six hours before opening a case. The reports read the same copy, and never present it as consulted more than a day ago.
Two limits to know
euvex therefore always tells “no case open” apart from “the catalogue was unreachable”: the monitoring report carries a dedicated indicator, because these two situations do not mean the same thing at all.
Official Journal of the European Union
The law
What it is.
The regulations themselves: CRA (EU) 2024/2847, Machinery (EU) 2023/1230, RED with Directive 2014/53/EU and Delegated Regulation 2022/30, AI Act (EU) 2024/1689, Batteries (EU) 2023/1542.
How euvex uses them.
Every date and every requirement cited in the product is read in the text, with the article or annex as reference, not taken from a summary article. The deadlines and their source are published on the Key dates page.
What that does not make us
The formats: CycloneDX, SPDX and purl
Interoperability
CycloneDX 1.5
A standard maintained by OWASP. euvex exports it deterministically (same inventory, same file), which makes comparisons and archiving reliable. And it imports it: an SBOM produced by another chain comes in as it is.
SPDX 2.2, 2.3 and 3.0
The Linux Foundation standard, the one Yocto writes by default and Zephyr produces with west spdx. euvex reads it on import, in JSON, tag-value and JSON-LD, and does not export it: what comes out of euvex is CycloneDX.
Package URL (purl)
The universal identifier that names a package with no ecosystem ambiguity. It is what makes it possible to match your inventory against OSV without confusing two packages of the same name. KEV is then matched by the CVE identifier of the advisories found.
The direct consequence: what comes out of euvex can be read elsewhere, without depending on our survival. The complete archive downloads as one file: a thin JSON envelope around standard CycloneDX BOMs, where each revision reads on its own, in any tool.
Where all this is hosted
Location
The data.
PostgreSQL at Supabase, Frankfurt region. Emails go out through Resend, Ireland. The application is served by Vercel, in Frankfurt; the DNS and the scheduled task by Cloudflare, an American company with a worldwide network.
What is never kept.
The lockfile you upload. It is read, turned into an inventory, then discarded: only the resulting bill of materials is stored, package names and versions, not your code.
The full detail (each piece of data, its legal basis, its retention period, each subprocessor) is in the privacy policy (in French), written from the actual database schema.
Check for yourself
Upload a lockfile: the verdict cites each advisory with its identifier, which you can open directly on OSV. A free account is enough.