Audit de dépendances et SBOM à partir de votre fichier lock
Chargez package-lock.json, yarn.lock, requirements.txt, pom.xml ou vos fichiers Gradle. Voyez les avis de sécurité connus avec leurs versions correctives, les classes de licence et les paquets obsolètes — et téléchargez une nomenclature logicielle (SBOM) au format CycloneDX.
Si vous utilisez déjà Dependabot, Renovate, Snyk, OSV-Scanner ou Dependency-Track dans votre CI, cet outil vous sera rarement utile. C’est une vérification ponctuelle pour une reprise de projet, une due diligence ou une première SBOM.
YuSMP est une société de développement logiciel ; l’analyse est gratuite et automatisée. Nous proposons sur demande une revue manuelle des dépendances et des mises à jour.
1Ajoutez vos fichiers de dépendances
Vos fichiers restent dans votre navigateur. Les fichiers lock sont analysés localement. À l’étape suivante, vous verrez quelles paires paquet@version seraient envoyées à notre serveur puis à la base publique de vulnérabilités OSV.dev et à un registre de paquets ; vous pouvez exclure les paquets internes. Nous ne conservons pas cette liste et ne l’écrivons pas dans les journaux.
Fichiers
| Fichier | Format | Paquets | État |
|---|
2Contexte (facultatif)
3Ce qui sera envoyé
| Envoyer | Paquet | Version | Portée |
|---|
Vérification en cours
- Recherche des vulnérabilités connues
- Vérification des dates de version et des licences
- Classement des corrections
Les gros projets prennent jusqu’à une minute.
Résultats
À corriger en premier
Télécharger une SBOM CycloneDX
La SBOM est générée dans votre navigateur à partir des composants ci-dessus (les paquets exclus et privés en sont retirés et comptés dans le fichier). Format : CycloneDX 1.5 JSON.
Ce que couvre le fichier (éléments minimaux NTIA)
- ✓Nom, version et identifiant unique (purl) du composant
- ◐Relations de dépendance : racine → dépendances directes uniquement
- ✓Auteur des données SBOM et horodatage
- ✕Nom du fournisseur — absent, les registres ne le fournissent pas de façon fiable
- ✕Empreintes des composants — pas encore incluses
Le CRA attend des fabricants qu’ils documentent les composants de leurs produits, notamment au moyen d’une nomenclature logicielle (SBOM) dans un format courant et lisible par machine couvrant au moins les dépendances de premier niveau (annexe I, partie II, point 1).
Cet outil aide à démarrer un inventaire des composants et à voir les avis connus. Ce n’est ni un conseil juridique ni une évaluation de conformité.
Recevoir le rapport PDF
Un PDF avec les priorités de correction, l’effort en heures, les tableaux des vulnérabilités, licences et paquets obsolètes et la méthode — par e-mail. Nous voyons aussi que vous avez lancé l’analyse, pour vous proposer une revue manuelle si elle est utile.
Revue manuelle des dépendances et des mises à jour
Un ingénieur passe votre pile en revue : ce qui est réellement atteignable, quelles mises à jour sont sûres, quoi remplacer, et un plan que votre équipe peut suivre. Premier échange gratuit, NDA sur demande.
Audits de sécuritéModernisation logicielleCTO à temps partagé
Ce que cet outil ne fait pas
- Il n’analyse pas votre code source (pas de SAST) et ne vérifie pas si une fonction vulnérable est réellement appelée.
- Il n’analyse pas les images de conteneurs, les paquets du système d’exploitation ni les registres privés.
- Il ne corrige rien et n’ouvre pas de pull requests.
- Il ne conserve ni vos fichiers ni la liste des paquets.
- Ce n’est ni un certificat, ni une opinion d’audit, ni un conseil juridique, ni une évaluation de conformité.
Si vous avez déjà une SCA dans votre CI
Gardez-la. Les outils continus comme Dependabot, Renovate, OSV-Scanner ou Dependency-Track surveillent chaque commit ; cette page sert à un regard ponctuel : reprise d’un projet d’un prestataire, due diligence, première SBOM pour un client ou base de code que personne n’a vérifiée depuis longtemps.
Comment ça marche
Votre navigateur lit les fichiers et extrait chaque paquet avec sa version exacte. Les paquets sans version exacte (une plage dans package.json, une exigence non figée, une propriété Maven non résolue) apparaissent comme « version non figée » et ne sont pas recherchés : une plage ne permet pas une réponse honnête. Ajoutez un fichier lock pour un résultat complet.
Les paquets internes sont exclus automatiquement : file:, link:, workspace:, sources git et URL, et tout ce qui provient d’un registre non public. Vous pouvez en exclure d’autres à la main avant tout envoi.
Ce n’est qu’après « Vérifier les dépendances » que la seule liste paquet@version part vers notre fonction serverless. Elle interroge OSV.dev, la base ouverte de vulnérabilités qui agrège les avis de GitHub, PyPI, npm et d’autres sources, et deps.dev (Open Source Insights) pour les licences, les dates de version et les dépréciations. La gravité provient du vecteur CVSS v3 ou de la note de l’avis ; les doublons (GHSA, CVE, PYSEC) sont fusionnés.
Les priorités pondèrent la gravité par la portée (dépendance directe de production, transitive, de développement) et par l’existence d’un correctif. L’effort est un ordre de grandeur en heures, pas un devis. Figez vos dépendances et tenez une SBOM : voir notre liste de contrôle sécurité des applications web.
Données de vulnérabilités : OSV.dev et ses sources (CC-BY 4.0). Métadonnées des paquets : deps.dev (Open Source Insights, CC-BY 4.0).
CRA, SBOM et votre produit
- Le règlement sur la cyberrésilience (CRA, règlement (UE) 2024/2847) est entré en vigueur le 10 décembre 2024. La notification des vulnérabilités activement exploitées et des incidents graves s’applique depuis le 11 septembre 2026 ; la plupart des autres obligations à partir du 11 décembre 2027.
- Le CRA attend des fabricants qu’ils documentent les composants de leurs produits, notamment au moyen d’une nomenclature logicielle (SBOM) dans un format courant et lisible par machine couvrant au moins les dépendances de premier niveau (annexe I, partie II, point 1).
- Les obligations visent les fabricants de produits comportant des éléments numériques mis sur le marché de l’UE. Leur application à votre produit dépend du produit — cet outil ne le détermine pas.
Cet outil aide à démarrer un inventaire des composants et à voir les avis connus. Ce n’est ni un conseil juridique ni une évaluation de conformité.
FAQ
Mes fichiers sont-ils envoyés ?
Non. Les fichiers sont lus par votre navigateur et ne le quittent pas. Seule la liste des noms de paquets publics avec leurs versions exactes, que vous confirmez à l’étape d’aperçu, est envoyée — et vous pouvez exclure n’importe quel paquet avant.
Qu’est-ce qui est envoyé exactement aux services externes ?
Des paires comme lodash@4.17.15 avec l’écosystème (npm, PyPI, Maven), le caractère direct ou de développement du paquet et la licence indiquée dans le fichier lock. Notre fonction transmet les noms et versions à OSV.dev et deps.dev (tous deux exploités aux États-Unis). Les noms de fichiers, chemins, URL de registres privés et votre code source ne sont pas envoyés. Nous ne conservons pas la liste et ne la journalisons pas.
Qu’est-ce qu’une SBOM et qui en a besoin ?
Une nomenclature logicielle (SBOM) est une liste lisible par machine des composants d’un produit : noms, versions, identifiants, licences. Clients, investisseurs et autorités la demandent de plus en plus, et le règlement sur la cyberrésilience l’attend des fabricants de produits comportant des éléments numériques.
« Vulnérabilité trouvée » signifie-t-il que mon produit est exploitable ?
Non. Cela signifie qu’un avis publié concerne cette version du paquet. Si votre code appelle la fonction vulnérable, dans quelle configuration et avec quelles entrées, n’est pas évalué ici — c’est le rôle d’une revue manuelle.
« Rien trouvé » signifie-t-il que c’est sûr ?
Non. Cela signifie qu’aucun avis connu ne correspond aux versions exactes vérifiées. Les paquets non figés, exclus et tout ce qui sort des formats pris en charge n’ont pas été vérifiés, et de nouveaux avis paraissent chaque jour.
Est-ce une vérification de conformité au CRA ?
Non. Cet outil aide à démarrer un inventaire des composants et à voir les avis connus. Ce n’est ni un conseil juridique ni une évaluation de conformité, et l’application du CRA dépend de votre produit.
Quels formats sont pris en charge et qu’est-ce qui ne l’est pas ?
npm (package-lock.json, npm-shrinkwrap.json, yarn.lock, package.json), PyPI (requirements*.txt / .in) et Maven/Gradle (pom.xml, build.gradle, build.gradle.kts). Les fichiers Maven et Gradle ne listent que les dépendances déclarées, sans l’arbre transitif et souvent sans versions résolues. Pas encore pris en charge : pnpm, Poetry, Pipenv, Go, Rust, Ruby, PHP, .NET, images de conteneurs et registres privés.
En quoi est-ce différent de Dependabot, Snyk ou OSV-Scanner ?
Ces outils tournent en continu dans votre dépôt et votre CI et peuvent proposer des correctifs. Cette page est une vérification ponctuelle sans rien installer : utile pour une reprise de projet, une due diligence ou une première SBOM. Si vous utilisez déjà l’un d’eux, gardez-le.
Services associés
Audits de sécurité
Tests d’intrusion et revues de sécurité, y compris une revue manuelle des dépendances et des mises à jour.
Modernisation logicielle
Mettre à jour les frameworks et remplacer les paquets non maintenus sans arrêter le produit.
CTO à temps partagé
Supervision technique expérimentée pour les reprises de projet, la due diligence et les décisions sur la chaîne d’approvisionnement.