Générateur de SBOM : la nomenclature des logiciels CycloneDX pour le règlement sur la cyberrésilience

Annexe I, partie II, point 1), du règlement (UE) 2024/2847 : les fabricants « recensent et documentent les vulnérabilités et les composants des produits, notamment par l’établissement d’une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits ». Cela s’applique à partir du 11 décembre 2027 (article 71).

• La nomenclature fait partie de la documentation technique, avec les processus de gestion des vulnérabilités (annexe VII, point 2 b)).
• Vous la remettez à une autorité de surveillance du marché sur demande motivée (annexe VII, point 8). Vous n’êtes pas tenu de la rendre publique (considérant 77).
• Si vous choisissez de la mettre à la disposition des utilisateurs, les informations pour l’utilisateur indiquent où (annexe II, point 9).
• La Commission peut en préciser le format et les éléments par un acte d’exécution (article 13, paragraphe 24). CycloneDX et SPDX sont des formats couramment utilisés.

Un fichier JSON CycloneDX 1.6 avec votre produit comme composant principal, chaque paquet avec sa version exacte et son URL de paquet (purl), et les dépendances de niveau supérieur du produit lorsque le fichier de verrouillage les indique. Elle lit :

• npm package-lock.json (lockfileVersion 2 ou 3), Yarn yarn.lock (Yarn 1, 2 et ultérieur) et pnpm-lock.yaml (lockfileVersion 9.0) ; les paquets réservés au développement sont exclus quand le fichier les signale ;
• Python requirements.txt avec chaque paquet fixé (name==version), comme l’écrivent pip freeze ou pip-compile ;
• Rust Cargo.lock, version 3 ou 4, et Go go.mod, avec les modules indirects ;
• l’arbre des dépendances Maven écrit par mvn dependency:tree -DoutputFile, et Gradle gradle.lockfile ; les paquets de portée test sont exclus ;
• PHP Composer composer.lock, sans packages-dev, et NuGet packages.lock.json.

Un fichier qui ne suit pas son format n’est pas lu : la page indique la ligne et la raison au lieu de deviner. Un paquet venant d’une autre source que le registre public est listé sans URL de paquet, pour que le fichier ne désigne jamais un paquet que vous n’avez pas utilisé.

Vous avez déjà un SBOM produit par un autre outil ? Ouvrez-le comme fichier JSON CycloneDX, ou comme fichier JSON SPDX tel que celui qu’exporte le graphe des dépendances de GitHub (Export SBOM), pour vérifier ses composants sur OSV.dev et dans le catalogue KEV. Il est lu pour la vérification seulement : pour produire un nouveau SBOM, ouvrez les fichiers de verrouillage. Là où aucun fichier de verrouillage ne fixe la version, le fichier de GitHub donne une plage comme ^4.17.0 : ces composants sont listés comme non vérifiés ; ouvrez le fichier de verrouillage pour les vérifier.

La vérification signale chaque vulnérabilité trouvée sur OSV.dev dont le numéro CVE figure au catalogue des vulnérabilités exploitées connues (KEV) de l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA), avec la date à laquelle la CISA l’a ajoutée. La CISA inscrit une vulnérabilité dès qu’il existe des preuves fiables qu’elle a été exploitée. À partir du 11 septembre 2026, l’article 14 du règlement sur la cyberrésilience vous demande de notifier une vulnérabilité activement exploitée contenue dans votre produit (article 3, point 42) dans les 24 heures après en avoir eu connaissance. Une entrée KEV ne tranche pas la question pour votre produit, mais indique où regarder en premier ; la page des délais de notification compte les heures.

La nomenclature liste ce que listent les fichiers de verrouillage. Le code copié dans le produit, les paquets du système d’exploitation, le micrologiciel et les bibliothèques dans d’autres langages n’y figurent pas : ajoutez-les vous-même. La vérification des vulnérabilités utilise OSV.dev, qui ne liste que les vulnérabilités publiées ; elle ne remplace pas l’évaluation des vulnérabilités que demande l’annexe I, partie II.

Pour le reste du dossier CRA, le kit documentaire CRA rédige la documentation technique et la déclaration UE de conformité. La page sur le règlement sur la cyberrésilience indique la classe de votre produit.