D'où viennent nos données
Chaque verdict d'euvex s'appuie sur une source publique et nommée. Voici lesquelles, ce qu'elles couvrent, et ce qu'elles ne couvrent pas.
OSV · Open Source Vulnerabilities
Vulnérabilités connues
Ce que c'est.
Une base ouverte de vulnérabilités des composants open source, maintenue par Google et alimentée par les écosystèmes eux-mêmes : GitHub Security Advisories, les avis npm, PyPI, Go, Rust, Debian et d'autres. Elle est interrogée par purl (l'identifiant universel de paquet), donc le croisement est exact, pas approximatif par nom.
Comment euvex l'utilise.
Chaque composant de votre inventaire est envoyé à api.osv.dev lors du scan, puis à chaque revérification quotidienne. Les avis remontés sont conservés dans la révision : c'est ce qui permet de dire plus tard qu'une vulnérabilité est nouvelle.
Ce qu'OSV ne couvre pas
« Aucune vulnérabilité connue » ne veut donc pas dire « aucune vulnérabilité ». Le mot connue fait tout le travail, et c'est pour ça qu'il est écrit partout dans le produit.
Et surtout : les identifiants qu'OSV ne sait pas résoudre
pkg:generic/openssl@3.0.11 ne remonte aucun avis, quand pkg:deb/debian/openssl@3.0.11 en remonte soixante-dix, pour le même OpenSSL, dans la même version.Or
pkg:generic et pkg:conan sont ce que produisent par défaut Yocto, Buildroot et conan, c'est-à-dire les chaînes de compilation embarquées. Un SBOM de firmware déposé tel quel peut donc n'avoir aucun composant interrogeable.euvex ne compte pas ces composants comme sains : il les marque « non analysé », affiche le rapport de couverture N sur M, et refuse de conclure à l'absence de vulnérabilité tant qu'un seul composant du produit n'a pas pu être interrogé. Nous n'essayons pas non plus de combler le trou en rapprochant les composants par leur nom : mesuré aussi,
openssl en version 9.9.9, qui n'existe pas, remonte 267 « vulnérabilités », dix-huit distributions répondant chacune avec ses propres bornes de version. Un silence honnête vaut mieux qu'un bruit présenté comme un verdict.Si votre chaîne sait émettre des purl de distribution, c'est le réglage qui change le plus ce qu'euvex peut voir de votre produit.
NVD · National Vulnerability Database
Vulnérabilités connues · par CPE
Ce que c'est.
La base de vulnérabilités du NIST, l'institut de standardisation américain. Elle s'interroge par CPE, l'autre grand identifiant de composant, celui qui sait nommer un logiciel qui n'est le paquet d'aucun écosystème.
Pourquoi une seconde source.
Parce qu'OSV s'interroge par purl et n'indexe pas pkg:generic, ce que produisent Yocto, Buildroot et conan. Autrement dit, la chaîne de compilation d'un firmware. Sans cette source, le SBOM d'un produit embarqué n'a aucune réponse possible, et euvex ne peut que dire qu'il n'a pas pu chercher.
Comment euvex l'utilise.
Uniquement pour les composants qu'OSV ne sait pas résoudre : deux sources sur un même composant produiraient deux avis pour une même faille, sous deux identifiants. Quand votre SBOM déclare un CPE, c'est le vôtre qui est interrogé, jokers compris (Yocto écrit cpe:2.3:*:*:openssl:3.0.11), et jusqu'à quatre par composant. Sinon, euvex pose la question avec un éditeur inconnu plutôt que d'en deviner un. La passe tourne dans la surveillance programmée, pas au dépôt : NVD répond un composant à la fois. Un firmware fraîchement déposé revient donc toutes les dix minutes jusqu'à ce que chaque composant ait été demandé, pendant quarante-huit heures au plus, puis chaque jour.
Ce qu'il faut savoir
pkg:deb/debian. Les périmètres diffèrent, une distribution ajoutant ses propres correctifs. Un chiffre n'est donc pas la correction de l'autre.Certaines fiches anciennes désignent un produit sans borner les versions touchées. euvex les écarte : les retenir signalerait une vulnérabilité de 2009 sur une version publiée quinze ans après.
Une réponse vide ne vaut pas toujours « rien d'affecté ». Quand la NVD ne connaît aucun produit de ce nom à son dictionnaire, comme
linux-yocto, le composant reste « non analysé » : il faut un CPE au nom que la NVD emploie, ici linux_kernel.euvex lit deux cents avis par composant. Le noyau Linux en dépasse de loin le compte, 5 487 pour une version 6.6.21 relevée le 30.10.2026 : le dossier dit alors combien la NVD en annonce, et reprend à part tous ceux du catalogue KEV, ceux qu'euvex croise pour ouvrir un dossier de l'article 14.
Mention demandée par les conditions d'utilisation de l'API : « This product uses the NVD API but is not endorsed or certified by the NVD. »
EUVD · la base de vulnérabilités de l'ENISA
La référence européenne
Ce que c'est.
La base de vulnérabilités de l'agence de l'Union européenne pour la cybersécurité. Chaque faille y porte un identifiant propre, de la forme EUVD-2021-34768.
Ce qu'euvex en fait.
Il cite. Chaque vulnérabilité trouvée par les sources précédentes est traduite en son identifiant européen, affiché à côté de l'identifiant américain dans votre dossier. Votre rapport porte ainsi la référence de l'Union, pas seulement celle des États-Unis.
Ce qu'euvex n'en fait pas, et pourquoi
openssl rend 227 résultats, dont le premier concerne openssl_encrypt, un autre logiciel. Et préciser la version ne change rien : la version 3.0.11 et une version 9.9.9 qui n'existe pas rendent exactement les mêmes 227 résultats.S'en servir pour apparier un composant reviendrait donc à deviner. Une source citée n'est pas une source de décision, et confondre les deux serait le défaut que toute cette page existe pour éviter.
Elle publie aussi un score EPSS, la probabilité qu'une faille soit exploitée. euvex ne le lit pas. Le déclencheur de l'article 14 est « activement exploitée », un constat ; une probabilité n'en est pas un. C'est le même raisonnement qui a fait écarter la sévérité CVSS.
CISA KEV · Known Exploited Vulnerabilities
Exploitation active · art. 14
Ce que c'est.
Le catalogue de l'agence américaine de cybersécurité qui recense les vulnérabilités activement exploitées, celles dont une exploitation réelle a été constatée, pas seulement supposée possible.
Pourquoi celui-là, et pas la sévérité.
Parce que c'est le prédicat du texte. L'article 14 du CRA déclenche l'obligation de signalement sur « activement exploitée », pas sur « grave ». Une vulnérabilité au score CVSS de 9,8 jamais exploitée ne déclenche rien ; une vulnérabilité au score moyen, activement exploitée, déclenche tout. Utiliser la sévérité comme déclencheur aurait été plus simple et juridiquement faux.
Comment euvex l'utilise.
Le catalogue est récupéré depuis cisa.gov. À chaque revérification d'un scan, les vulnérabilités trouvées dans vos composants y sont cherchées, dans une copie du catalogue rafraîchie toutes les six heures ; une correspondance ouvre un dossier de signalement et lance le décompte des échéances. Une entrée que la CISA vient d'ajouter peut donc attendre jusqu'à six heures avant d'ouvrir un dossier. Les rapports lisent la même copie, et ne la présentent jamais comme consultée au-delà d'un jour.
Deux limites à connaître
euvex distingue donc toujours « aucun cas ouvert » de « le catalogue était injoignable » : le rapport de surveillance porte un indicateur dédié, parce que ces deux situations n'ont pas du tout le même sens.
Journal officiel de l'Union européenne
Le droit
Ce que c'est.
Les règlements eux-mêmes : CRA (UE) 2024/2847, Machines (UE) 2023/1230, RED avec la directive 2014/53/UE et le règlement délégué 2022/30, AI Act (UE) 2024/1689, Batteries (UE) 2023/1542.
Comment euvex les utilise.
Toutes les dates et toutes les exigences citées dans le produit sont lues dans le texte, avec l'article ou l'annexe en référence, pas reprises d'un article de synthèse. Les échéances et leur source sont publiées sur la page Repères.
Ce que ça ne fait pas de nous
Les formats : CycloneDX, SPDX et purl
Interopérabilité
CycloneDX 1.5
Standard porté par l'OWASP. euvex l'exporte de façon déterministe (même inventaire, même fichier), ce qui rend les comparaisons et l'archivage fiables. Et il l'importe : un SBOM produit par une autre chaîne entre tel quel.
SPDX 2.2, 2.3 et 3.0
Standard de la Linux Foundation, celui que Yocto écrit par défaut et que Zephyr produit avec west spdx. euvex le lit à l'import, en JSON, en tag-value et en JSON-LD, et n'en exporte pas : ce qui sort d'euvex est du CycloneDX.
Package URL (purl)
L'identifiant universel qui nomme un paquet sans ambiguïté d'écosystème. C'est lui qui permet de croiser votre inventaire avec OSV sans confondre deux paquets homonymes. KEV se croise ensuite par l'identifiant CVE des avis trouvés.
Conséquence directe : ce qui sort d'euvex se lit ailleurs, sans dépendre de notre survie. L'archive complète se télécharge en un fichier : une enveloppe JSON mince autour de BOM CycloneDX standard, où chaque révision se lit seule, dans n'importe quel outil.
Où tout cela est hébergé
Localisation
Les données.
PostgreSQL chez Supabase, région de Francfort. Les emails partent via Resend, Irlande. L'application est servie par Vercel, à Francfort ; le DNS et la tâche planifiée par Cloudflare, société américaine au réseau mondial.
Ce qui n'est jamais conservé.
Le lockfile que vous déposez. Il est lu, transformé en inventaire, puis jeté : seule la nomenclature résultante est enregistrée : des noms de paquets et des versions, pas votre code.
Le détail complet (chaque donnée, sa base légale, sa durée de conservation, chaque sous-traitant) est dans la politique de confidentialité, écrite depuis le schéma réel de la base.
Vérifiez par vous-même
Déposez un lockfile : le verdict cite chaque avis avec son identifiant, que vous pouvez ouvrir directement sur OSV. Un compte gratuit suffit.