SBOM Vulnerability Scanner

Votre lockfile ne quitte jamais cette page

L'analyse se fait entièrement dans votre navigateur : le fichier que vous déposez — ou le texte que vous collez — est lu localement et n'est téléversé nulle part. Seuls les noms et versions de paquets extraits sont envoyés, à la base de données publique de vulnérabilités OSV.dev (aucun compte, aucune clé), pour qu'elle puisse les comparer aux vulnérabilités connues. Les identifiants CVE issus des correspondances sont ensuite envoyés au vérificateur de ce site pour une recherche CISA KEV. Rien d'autre ne quitte la page : ni le contenu des fichiers, ni les chemins, ni les noms de projets.

Limites du scan

Au maximum 500 paquets sont scannés par exécution — les autres sont listés comme non scannés. Au maximum 200 détails de vulnérabilités sont récupérés. Les résultats proviennent de la base de données OSV pour les versions exactes de votre fichier ; une version de paquet que la base de données n'a jamais vue ne donne aucune correspondance, ce qui n'est pas la même chose qu'un certificat de bonne santé.

Les limites, en toute honnêteté

« Aucune vulnérabilité trouvée » signifie : aucune dans la base de données OSV pour ces versions exactes. Cela ne signifie pas que le code est sûr : les vulnérabilités que personne n'a encore signalées, les paquets malveillants, les noms typosquats et les versions compromises sont tous invisibles pour une vérification par correspondance de version.

Une correspondance est exacte à la version près. Si votre fichier épingle une plage au lieu d'une version exacte, elle est ignorée et listée comme telle — le scanner ne devinera pas quelle version vous avez réellement installée. Il en va de même pour les paquets dont l'écosystème ne peut pas être mappé par le scanner : ils sont listés comme ignorés, jamais supprimés silencieusement.

Les indicateurs KEV proviennent d'une seule recherche auprès du vérificateur de ce site (données CISA KEV, actualisées quotidiennement). Si cette recherche échoue ou est limitée en débit, le scan se termine quand même — la colonne KEV indique simplement « inconnu » au lieu de bloquer vos résultats.

Pourquoi la version épinglée est la surface d'attaque

Un lockfile existe parce que « latest » n'est pas une version. Il enregistre l'arborescence exacte installée par votre build, pour que chaque machine et chaque déploiement obtienne le même code. Ce déterminisme est aussi ce qui rend le lockfile scannable : une base de données de vulnérabilités est indexée par paquet et version exacts, donc une version épinglée peut être jugée en une seule recherche, alors qu'une plage flottante ne le peut pas. Le scan n'est donc bon que dans la mesure où le fichier l'est — commitez le lockfile, gardez-le à jour, et le scanner pourra vous dire la vérité sur ce que vous livrez.

La vérification elle-même est délibérément étroite. OSV.dev agrège les avis de vulnérabilité des GitHub Advisories, de la NVD et des écosystèmes de langages, et les compare à vos versions. Ce qu'il ne peut pas faire, c'est juger le code : un paquet sans CVE connue peut tout de même être malveillant, abandonné ou ressembler à un paquet que vous vouliez installer. La correspondance de version est un premier filtre rapide et bon marché — celui qui attrape le lodash que vous avez oublié de mettre à jour — pas un audit de sécurité.

Pourquoi un indicateur KEV prime sur un score CVSS élevé

Un score CVSS mesure la gravité d'une vulnérabilité si elle était exploitée. Le catalogue des vulnérabilités connues exploitées (Known Exploited Vulnerabilities) de la CISA mesure autre chose : si elle est réellement exploitée, dans la nature, en ce moment même. Une CVE de gravité moyenne figurant sur la liste KEV mérite un correctif cette semaine ; une CVE critique que personne n'a transformée en arme peut souvent attendre la prochaine mise à jour planifiée. C'est pourquoi ce scanner signale les lignes KEV séparément et pourquoi les résultats sont triés d'abord par la pire gravité — mais l'indicateur KEV est celui sur lequel il faut agir en premier.

Les versions corrigées comportent leur propre risque. Le correctif d'une vulnérabilité est généralement une version mineure ou de patch, mais « corrigé en 4.17.21 » peut aussi signifier un changement de comportement qui casse votre build, et certaines vulnérabilités n'ont aucune version corrigée — le scanner le dit clairement au lieu d'en inventer une. Corrigez d'abord les éléments KEV, puis les critiques avec un correctif publié, puis planifiez le reste ; épinglez les nouvelles versions, commitez le lockfile et relancez le scan. La même boucle appartient à la CI, où elle s'exécute à chaque pull request au lieu d'une fois par trimestre.

Licences dans cette SBOM

Les licences indiquées ici proviennent uniquement des champs de licence portés par la SBOM elle-même. Les lockfiles (package-lock.json, requirements.txt, go.mod) ne contiennent aucune donnée de licence, donc rien n'est affiché pour elles — cette page ne recherche pas les licences paquet par paquet, car aucune base de données publique ne les fournit de manière fiable.

Termes relatifs aux lockfiles et aux SBOM, définis précisément

Lockfile. Un fichier qui enregistre la version exacte de chaque paquet installé par un build — package-lock.json pour npm, requirements.txt avec des épingles == pour Python, go.mod/go.sum pour Go — afin que les installations soient reproductibles.

SBOM. Software Bill of Materials : un inventaire lisible par machine de chaque composant d'un logiciel, généralement au format CycloneDX ou SPDX. C'est le lockfile généralisé à toute la chaîne d'approvisionnement.

OSV.dev. La base de données publique de vulnérabilités de Google, qui agrège les avis de GitHub, de la NVD et des écosystèmes de langages, interrogeable par nom de paquet, écosystème et version exacts.

GHSA. Un identifiant GitHub Security Advisory (GHSA-xxxx-xxxx-xxxx). La plupart des vulnérabilités npm, PyPI et Go dans OSV en portent un, généralement accompagné d'un identifiant CVE.

CVE. Common Vulnerabilities and Exposures : le système de numérotation partagé (CVE-YYYY-NNNNN) qui permet à chaque base de données, chaque scanner et chaque fournisseur de parler de la même vulnérabilité.

CVSS. Common Vulnerability Scoring System : un score de 0 à 10 indiquant la gravité d'une vulnérabilité si elle était exploitée. 9,0+ est CRITICAL, 7,0+ HIGH, 4,0+ MEDIUM, en dessous de 4,0 LOW.

KEV. Le catalogue des vulnérabilités connues exploitées (Known Exploited Vulnerabilities) de la CISA : des vulnérabilités dont l'exploitation dans la nature est confirmée, chacune avec une date limite de correction. Un indicateur KEV signifie « corrigez maintenant », quel que soit le score CVSS.

Fixed version. La première version d'un paquet dans laquelle une vulnérabilité n'est plus présente, tirée des événements de plage affectée de l'avis. Pour certaines vulnérabilités, aucune n'a encore été publiée.

Purl. Package URL (pkg:npm/[email protected]) : une manière standard de nommer un paquet avec son écosystème et sa version. Les SBOM contiennent des purls, ce qui permet au scanner de savoir à quel écosystème appartient un composant.

Questions fréquentes