Guide · SBOM

Produire un SBOM pour votre stack

Une nomenclature logicielle (SBOM) liste les composants de ce que vous livrez, avec leurs versions. Le Cyber Resilience Act attend des fabricants qu'ils en tiennent une (annexe I, partie II, point 1). Des outils open source gratuits en produisent une pour chaque stack courante en quelques minutes. Cette page donne la commande pour chacune, et ce qu'il faut vérifier avant de vous fier au résultat.

Les outils ci-dessous appartiennent à leurs propres projets ; SkyQon ne les fabrique pas et n'en assure pas le support. Commandes vérifiées dans la documentation de chaque projet le 13 novembre 2026.

Avant de commencer

Choisissez un format. CycloneDX et SPDX sont les deux standards ouverts. Les deux conviennent. SkyQon lit CycloneDX JSON et SPDX 2.x JSON ; il ne lit pas encore le XML ni SPDX 3.0.
Décrivez ce que vous livrez, pas votre portable. Lancez l'outil sur la build de release, le fichier de verrouillage ou l'image que vous livrez. Un SBOM fait sur un poste de développement liste des outils de test et oublie ce que la build ajoute.
Un SBOM par version. Faites-en un nouveau à chaque release et gardez les anciens. Un signalement de vulnérabilité cite une version ; c'est le SBOM de cette version qui vous dit si vous êtes concerné.
Intégrez-le à la build. Chaque commande ci-dessous s'exécute sans question, elle trouve donc sa place dans une étape de CI à côté de la build qui produit la release.

Toute stack et conteneurs

Deux outils généralistes lisent la plupart des gestionnaires de paquets et des images de conteneur. Commencez ici si votre produit mélange plusieurs langages ou est livré sous forme d'image.

Syft

Analyse un dossier ou une image de conteneur et écrit les deux formats en une fois.

syft ./my-product -o cyclonedx-json=./sbom.cdx.json
syft registry.example.com/acme/app:2.1.0 -o spdx-json=./sbom.spdx.json

Trivy

Analyse une image ou un dossier de projet. Avec ce format, le résultat ne contient que les composants, pas les résultats de vulnérabilités.

trivy image --format cyclonedx --output sbom.cdx.json acme/app:2.1.0
trivy fs --format cyclonedx --output sbom.cdx.json ./my-product

cdxgen

Détecte seul les langages d'un dossier de projet ; ajoutez un type quand il se trompe.

npm install -g @cdxgen/cdxgen
cdxgen -o sbom.cdx.json .
cdxgen -t java -o sbom.cdx.json .

Par langage

Chaque écosystème a un outil CycloneDX qui lit son propre fichier de verrouillage. Ces outils voient les versions exactes résolues par la build.

Python

À partir de l'environnement où tourne la release, ou d'un fichier requirements. JSON est la sortie par défaut.

pip install cyclonedx-bom
cyclonedx-py environment --output-file sbom.cdx.json
cyclonedx-py requirements requirements.txt --output-file sbom.cdx.json

JavaScript (npm)

Intégré à la ligne de commande npm dans les versions actuelles. Laissez les dépendances de développement hors de ce que vous livrez.

npm sbom --sbom-format=cyclonedx --omit=dev > sbom.cdx.json
npm sbom --sbom-format=spdx --omit=dev > sbom.spdx.json

Java

Maven lance le plugin CycloneDX sans modifier le projet et écrit bom.json dans target. Pour Gradle, ajoutez le plugin org.cyclonedx.bom à la build et lancez sa tâche ; le fichier arrive dans build/reports/cyclonedx.

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom
./gradlew cyclonedxBom

Go

Le mode app suit les mêmes paramètres de build que votre release : réglez-les comme votre build.

go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
GOOS=linux GOARCH=amd64 cyclonedx-gomod app -json -output sbom.cdx.json -main cmd/app .

Rust

À lancer dans le dossier qui contient Cargo.toml. Le fichier est écrit à côté.

cargo install cargo-cyclonedx
cargo cyclonedx --format json

.NET

cdxgen lit les fichiers de projet et de verrouillage. L'outil CycloneDX pour .NET est l'autre choix courant.

cdxgen -t dotnet -o sbom.cdx.json .

C, C++ et Linux embarqué

C and C++

Il n'existe pas de liste de paquets unique : attendez-vous à des trous. cdxgen lit les métadonnées de build C et C++ courantes ; les bibliothèques copiées dans l'arborescence source sont souvent manquées et doivent être ajoutées à la main. Pour un firmware, analysez aussi l'image finale avec Syft et comparez.

cdxgen -t c -o sbom.cdx.json .

Yocto

Les versions actuelles écrivent par défaut un fichier SPDX à chaque build d'image, dans tmp/deploy/images/MACHINE/ sous le nom IMAGE-MACHINE.spdx.json. Les versions plus anciennes écrivent du SPDX 2.2, que SkyQon lit. Les plus récentes écrivent du SPDX 3.0, que SkyQon ne lit pas encore : lancez Syft sur le système de fichiers racine de l'image pour obtenir un fichier CycloneDX à la place.

bitbake core-image-minimal
ls tmp/deploy/images/*/*.spdx.json

Le vérifier avant de s'y fier

Comptez les composants. Un service web avec une poignée d'entrées, c'est presque toujours l'analyse du mauvais dossier. Comparez le nombre avec votre fichier de verrouillage.
Cherchez les package URL. La comparaison aux bases de vulnérabilités s'appuie sur le package URL (purl) ou le CPE de chaque composant. Une entrée qui n'a qu'un nom ne peut pas être comparée.
Trouvez votre produit en tête. Le SBOM doit nommer votre produit et sa version comme composant principal, pour qu'un lecteur sache quelle release il décrit.
Repérez les outils de test. Des linters, des frameworks de test ou des plugins de build dans la liste signifient qu'il a été produit depuis un environnement de développement, pas depuis la release.

Le confier à SkyQon

Avec le module CRA Product Evidence, déposez le fichier sur la page du produit et indiquez la version. SkyQon lit jusqu'à 20 000 composants dans un fichier de 20 Mo au plus, conserve chaque version et compare chaque jour les composants à OSV.dev et à la NVD, en ajoutant CISA KEV et EPSS à chaque correspondance. Seuls les identifiants de paquets quittent la plateforme ; le fichier reste avec vos preuves.

Une correspondance est une piste, pas un verdict : vous notez si elle vous concerne, et cette note entre dans le rapport signé de preuves produit. Ceci n'est pas un avis juridique ; le fabricant reste responsable du SBOM et de ce qu'il montre.

Vous ne savez pas si le CRA couvre votre produit ?

La vérification gratuite du champ et de la classe prend une dizaine de minutes par produit et cite les articles derrière chaque réponse.

Vérifier le champ et la classe, gratuitement Le parcours CRA