Outils SBOM Comparés : Syft vs Trivy vs CycloneDX CLI

Pourquoi les SBOMs sont importants : l’impératif réglementaire et sécuritaire

Un Software Bill of Materials (SBOM) est un inventaire formel et lisible par machine de chaque composant, bibliothèque et dépendance qui constitue un logiciel. Considérez-le comme l’étiquette nutritionnelle de votre application — sauf qu’au lieu des calories et du sodium, vous répertoriez les paquets, versions, licences et données de provenance.

Les SBOMs sont passés du statut de « nice-to-have » à celui d’exigence réglementaire. Deux politiques majeures stimulent leur adoption dans tous les secteurs :

Executive Order 14028 (États-Unis)

Signé en mai 2021, l’EO 14028 — « Improving the Nation’s Cybersecurity » — impose que tout logiciel vendu au gouvernement fédéral américain inclue un SBOM. Ce décret a chargé le NIST de définir les éléments minimaux d’un SBOM, ce qui a abouti à des recommandations alignées sur les normes SBOM de la NTIA. Si votre organisation vend à des agences gouvernementales, la génération de SBOMs n’est plus optionnelle — c’est un prérequis d’approvisionnement.

EU Cyber Resilience Act (CRA)

Le EU Cyber Resilience Act, entré en vigueur en 2024, exige des fabricants et distributeurs de produits comportant des éléments numériques qu’ils fournissent des SBOMs dans le cadre de leur évaluation de conformité. Le CRA s’applique largement — des appareils IoT aux plateformes SaaS d’entreprise. Avec des échéances d’application qui s’accélèrent en 2026 et 2027, les producteurs de logiciels destinés au marché européen doivent intégrer la génération de SBOMs dans leurs processus de build dès maintenant.

Au-delà de la conformité : la valeur opérationnelle

Outre les moteurs réglementaires, les SBOMs apportent des bénéfices opérationnels concrets :

Réponse aux vulnérabilités : Lorsqu’un nouveau CVE est publié (comme Log4Shell), un SBOM vous permet de déterminer instantanément quels produits et déploiements sont affectés.
Conformité des licences : Les SBOMs énumèrent les licences dans votre arbre de dépendances, signalant les licences copyleft ou incompatibles avant qu’elles ne deviennent des problèmes juridiques.
Transparence de la chaîne d’approvisionnement : Les SBOMs créent une chaîne de traçabilité auditable, permettant aux consommateurs en aval de vérifier exactement ce qu’ils exécutent.
Forensique d’incidents : Lors d’enquêtes sur des violations, les SBOMs accélèrent l’analyse des causes profondes en fournissant un inventaire précis des composants au moment du build.

La question n’est plus de savoir si vous devez générer des SBOMs, mais quel outil utiliser. Dans ce comparatif, nous évaluons trois générateurs SBOM open source de premier plan : Syft, Trivy et CycloneDX CLI.

Syft : le générateur SBOM dédié d’Anchore

Syft est développé par Anchore et est conçu pour faire une seule chose exceptionnellement bien : générer des SBOMs précis et complets. C’est un outil SBOM dédié, et non un scanner qui produit des SBOMs comme effet secondaire.

Capacités clés

Formats de sortie : SPDX (JSON, tag-value), CycloneDX (JSON, XML), JSON natif de Syft, et format de snapshot de dépendances GitHub.
Types de sources : Images de conteneurs (depuis des registres, tarballs ou le daemon Docker), systèmes de fichiers, répertoires et fichiers d’archives (tar, zip, jar, war).
Écosystèmes de langages : Excellente couverture — Go, Java (Maven/Gradle), JavaScript (npm/yarn), Python (pip/Poetry/Pipenv), Ruby, Rust, PHP (Composer), .NET (NuGet), C/C++ (Conan), Swift, Dart, Haskell, et plus encore.
Catalogueurs de paquets : Syft utilise une architecture de catalogueurs modulaire. Chaque écosystème possède son propre catalogueur qui comprend les fichiers de verrouillage natifs, les manifestes et les artefacts binaires. Cela produit des résultats très précis.
Support des attestations : Syft s’intègre étroitement avec les frameworks d’attestation cosign et in-toto. Vous pouvez diriger la sortie SBOM de Syft directement dans cosign attest pour produire des attestations SBOM signées.

Points forts

La focalisation unique de Syft sur la génération de SBOMs signifie qu’il possède la couverture de catalogueurs la plus approfondie de tous les outils de ce comparatif. Il détecte des composants que d’autres outils manquent — en particulier les paquets binaires compilés dans les binaires Go et Rust, et les dépendances imbriquées dans les uber-jars Java. Sa flexibilité de formats de sortie est inégalée, et il s’intègre nativement avec le scanner de vulnérabilités Grype d’Anchore.

Limitations

Syft n’effectue pas lui-même de scan de vulnérabilités. Vous devez l’associer à Grype ou un autre scanner. C’est sans doute un point fort (philosophie Unix : faire une seule chose bien), mais cela implique un outil supplémentaire dans votre pipeline.

Exemple d’utilisation

# Générer un SBOM CycloneDX à partir d'une image de conteneur
syft packages registry.example.com/myapp:latest -o cyclonedx-json > sbom.cdx.json

# Générer un SBOM SPDX à partir d'un répertoire local
syft dir:/path/to/source -o spdx-json > sbom.spdx.json

# Attester le SBOM avec cosign
cosign attest --predicate sbom.cdx.json --type cyclonedx my-image:latest

Trivy : le scanner tout-en-un d’Aqua Security avec mode SBOM

Trivy est développé par Aqua Security et a débuté comme scanner de vulnérabilités pour les conteneurs. Au fil du temps, il a évolué en un outil de sécurité complet qui génère également des SBOMs. Sa capacité SBOM a été ajoutée comme mode de scan aux côtés du scan de vulnérabilités, de mauvaises configurations, de secrets et de licences.

Capacités clés

Formats de sortie : CycloneDX (JSON), SPDX (JSON), JSON natif de Trivy, SARIF, et sortie tabulaire/lisible par l’humain.
Types de sources : Images de conteneurs, systèmes de fichiers, dépôts git, clusters Kubernetes, comptes AWS et images de VM.
Écosystèmes de langages : Forte couverture — Go, Java, JavaScript, Python, Ruby, Rust, PHP, .NET, C/C++, Elixir, Dart, Swift, et plus encore.
Scan de vulnérabilités intégré : C’est la fonctionnalité phare de Trivy. Générez un SBOM et scannez-le pour détecter des vulnérabilités en une seule passe, ou scannez un fichier SBOM existant produit par un autre outil.
Support des attestations : Trivy peut générer et vérifier des attestations in-toto nativement via trivy image --format cosign-vuln, et s’intègre avec cosign pour les workflows d’attestation SBOM.

Points forts

Le plus grand avantage de Trivy est son architecture tout-en-un. Un seul binaire gère la génération de SBOMs, le scan de vulnérabilités, la détection de mauvaises configurations, le scan de secrets et l’analyse de licences. Cela réduit considérablement la complexité de la chaîne d’outils. C’est également le seul outil de ce comparatif capable de scanner directement des clusters Kubernetes et des comptes cloud. Sa base de données de vulnérabilités est mise à jour fréquemment et couvre de multiples sources (NVD, avis des éditeurs, GitHub Security Advisories).

Limitations

Parce que la génération de SBOMs de Trivy est une fonctionnalité parmi d’autres, la profondeur de ses catalogueurs peut être inférieure à celle de Syft dans les cas limites — en particulier pour l’analyse binaire des binaires Go/Rust compilés et des artefacts Java profondément imbriqués. Le support SPDX a été ajouté plus tard que celui de CycloneDX, de sorte que la sortie CycloneDX tend à être plus complète dans certains scénarios. La nature tout-en-un implique également un binaire plus volumineux et des téléchargements de base de données initiaux plus longs.

Exemple d’utilisation

# Générer un SBOM CycloneDX à partir d'une image de conteneur
trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/myapp:latest

# Générer un SBOM SPDX à partir d'un système de fichiers
trivy fs --format spdx-json --output sbom.spdx.json /path/to/source

# Scanner un SBOM existant pour les vulnérabilités
trivy sbom sbom.cdx.json

# Combiné : générer un SBOM + scanner en une passe
trivy image --format json --list-all-pkgs registry.example.com/myapp:latest

CycloneDX CLI : la boîte à outils SBOM native d’OWASP

CycloneDX CLI fait partie du projet OWASP CycloneDX. Contrairement à Syft et Trivy, ce n’est pas principalement un générateur de SBOMs à partir de code source ou d’images de conteneurs. C’est plutôt une boîte à outils pour manipuler, convertir, valider, fusionner et comparer des SBOMs CycloneDX. L’écosystème CycloneDX plus large inclut des plugins de génération de SBOMs spécifiques aux langages (par ex., cyclonedx-maven-plugin, cyclonedx-npm, cyclonedx-gomod) qui produisent des SBOMs pendant le processus de build lui-même.

Capacités clés

Formats de sortie : CycloneDX (JSON, XML, Protocol Buffers) — fidélité totale. Peut convertir entre les versions de CycloneDX. Support de conversion SPDX limité.
Opérations SBOM : Fusionner plusieurs SBOMs en un seul, comparer deux SBOMs pour voir ce qui a changé, valider les SBOMs par rapport au schéma CycloneDX, et convertir entre les formats CycloneDX.
Génération au moment du build : Les plugins de langages de l’écosystème CycloneDX génèrent des SBOMs pendant le build en lisant directement le résolveur de dépendances (Maven, npm, Go modules, pip, etc.), ce qui produit le graphe de dépendances le plus précis possible.
Support des attestations : Les SBOMs CycloneDX peuvent être encapsulés dans des attestations CycloneDX BOM-Link, et l’écosystème prend en charge les documents VEX (Vulnerability Exploitability eXchange) comme éléments de première classe.

Points forts

L’approche de génération au moment du build de l’écosystème CycloneDX produit les SBOMs les plus précis car elle exploite la résolution réelle des dépendances de l’outil de build — et non un scan post-hoc du système de fichiers. La capacité de fusion du CLI est inestimable pour les monorepos et les architectures microservices où vous devez combiner des SBOMs par service en un SBOM au niveau du produit. La validation de schéma garantit que les SBOMs sont conformes aux spécifications avant distribution. Le support VEX est le plus mature dans cet écosystème.

Limitations

L’approche CycloneDX nécessite une intégration de plugin par langage dans votre système de build. C’est plus de travail que d’exécuter un seul binaire sur une image de conteneur. Le CLI lui-même ne scanne pas les conteneurs ou les systèmes de fichiers à la recherche de paquets — vous avez besoin des plugins de langages pour la génération. Le support SPDX est limité par rapport à Syft et Trivy. L’outillage est plus fragmenté (CLI + multiples plugins) par rapport à un seul binaire.

Exemple d’utilisation

# Générer un SBOM pendant le build Maven
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

# Générer un SBOM à partir d'un projet npm
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Fusionner plusieurs SBOMs
cyclonedx merge --input-files sbom-api.cdx.json sbom-frontend.cdx.json --output-file product-sbom.cdx.json

# Valider un SBOM par rapport au schéma
cyclonedx validate --input-file sbom.cdx.json --fail-on-errors

# Comparer deux SBOMs pour voir ce qui a changé entre les versions
cyclonedx diff --from v1-sbom.cdx.json --to v2-sbom.cdx.json

Tableau comparatif détaillé

Fonctionnalité	Syft	Trivy	CycloneDX CLI + Plugins
Objectif principal	Génération de SBOMs	Scanner de sécurité tout-en-un	Manipulation de SBOMs + génération au moment du build
Sortie SPDX	JSON, tag-value (excellent)	JSON (bon)	Conversion limitée uniquement
Sortie CycloneDX	JSON, XML (excellent)	JSON (excellent)	JSON, XML, Protobuf (natif, meilleur)
Scan de conteneurs	Oui (registre, daemon, tarball)	Oui (registre, daemon, tarball)	Non (build uniquement)
Scan du système de fichiers	Oui	Oui	Via plugins de langages
Analyse binaire	Forte (binaires Go, Rust)	Modérée	Aucune
Scan de vulnérabilités	Non (utiliser Grype)	Oui (intégré)	Non (utiliser un outil séparé)
Précision (profondeur des dépendances)	Excellente	Très bonne	Meilleure (résolution au moment du build)
Fusion/comparaison de SBOMs	Non	Non	Oui (natif)
Support VEX	Via Grype/Vunnel	Support OpenVEX	VEX CycloneDX natif
Signature d’attestation	Via intégration cosign	Via intégration cosign	Attestation BOM-Link
Intégration CI/CD	GitHub Action, CLI	GitHub Action, CLI, opérateur Kubernetes	Plugin de build par langage
Vitesse (conteneur typique)	Rapide (15–30s)	Modérée (20–60s avec téléchargement de la BDD)	La plus rapide (intégré au build, pas de scan séparé)
Scan de cluster Kubernetes	Non	Oui	Non

Précision et complétude : là où cela compte vraiment

La précision du SBOM est le différenciateur le plus important. Un SBOM incomplet est sans doute pire que l’absence de SBOM — il procure une fausse confiance.

Les plugins CycloneDX au moment du build l’emportent en précision pour une raison claire : ils s’intègrent au résolveur du gestionnaire de paquets pendant le build. Quand cyclonedx-maven-plugin s’exécute, il voit exactement le même arbre de dépendances que celui résolu par Maven. Pas de devinettes, pas de correspondance heuristique — il lit directement le graphe résolu.

Syft arrive en deuxième position. Son architecture de catalogueurs est spécifiquement ajustée pour analyser les fichiers de verrouillage, les manifestes et les métadonnées binaires avec une haute fidélité. Syft excelle à trouver des composants que d’autres outils manquent — en particulier les binaires Go (qui intègrent les informations de modules), les binaires Rust et les uber-jars Java avec des dépendances embarquées.

Trivy est très performant pour la plupart des cas d’utilisation mais peut manquer des cas limites dans l’analyse binaire. Sa force réside dans l’étendue — il couvre davantage de types de sources (Kubernetes, cloud) même si la profondeur par source est légèrement inférieure à celle de Syft dans certains scénarios.

Intégration CI/CD : intégrer les SBOMs dans votre pipeline

Les trois outils s’intègrent dans les pipelines CI/CD, mais les schémas d’intégration diffèrent significativement :

Syft en CI/CD

Syft fournit une GitHub Action officielle (anchore/sbom-action) qui génère des SBOMs et les télécharge optionnellement comme snapshots de dépendances GitHub. Pour GitLab, Jenkins ou d’autres systèmes CI, le binaire CLI est simple à installer et à invoquer. Associez-le à anchore/scan-action (Grype) pour les contrôles de vulnérabilités.

Trivy en CI/CD

Trivy offre la surface d’intégration CI/CD la plus large : une GitHub Action (aquasecurity/trivy-action), un opérateur Kubernetes (Trivy Operator), et une sortie SARIF pour l’intégration avec GitHub Code Scanning. Une seule étape Trivy peut produire un SBOM, scanner les vulnérabilités, vérifier les mauvaises configurations et détecter les secrets — remplaçant trois ou quatre outils distincts.

CycloneDX en CI/CD

L’intégration CycloneDX nécessite d’ajouter le plugin de langage approprié à votre configuration de build. Pour Maven, vous ajoutez le plugin à votre POM. Pour npm, vous ajoutez un script appelant @cyclonedx/cyclonedx-npm. Cette approche native au build signifie que le SBOM est généré comme artefact de build aux côtés de votre application, sans étape de scan séparée nécessaire.

Quand utiliser quel outil

Choisissez Syft quand :

La précision de la génération de SBOMs est votre priorité absolue
Vous avez besoin d’une flexibilité maximale des formats de sortie (SPDX + CycloneDX)
Vous scannez des images de conteneurs ou des artefacts pré-construits (pas du code source)
Vous utilisez déjà ou prévoyez d’utiliser Grype pour le scan de vulnérabilités
Vous devez analyser des binaires compilés (Go, Rust)
Vous voulez un outil léger, à usage unique, avec un minimum de dépendances

Choisissez Trivy quand :

Vous voulez un seul outil pour la génération de SBOMs et le scan de vulnérabilités
Vous devez scanner des clusters Kubernetes ou des comptes cloud
La simplicité et la réduction de la complexité de la chaîne d’outils comptent plus que la profondeur maximale du SBOM
Vous voulez la détection intégrée des mauvaises configurations et des secrets en plus des SBOMs
Votre équipe préfère un outil unique et bien maintenu plutôt que d’assembler plusieurs composants
Vous avez besoin d’une sortie SARIF pour GitHub Code Scanning ou l’intégration Azure DevOps

Choisissez CycloneDX CLI + Plugins quand :

Vous avez besoin de la résolution de dépendances la plus précise possible
Votre organisation a standardisé le format CycloneDX
Vous gérez des monorepos et devez fusionner des SBOMs par service en SBOMs au niveau produit
Vous devez comparer les SBOMs entre les versions pour suivre les changements de dépendances
La validation de schéma des SBOMs avant distribution est une exigence
La génération de documents VEX fait partie de votre workflow de divulgation de vulnérabilités

Pipeline combiné : utiliser les trois ensemble

En pratique, de nombreuses organisations matures combinent ces outils. Voici un schéma de pipeline qui exploite les forces de chacun :

# Étape 1 : SBOM au moment du build (graphe de dépendances le plus précis)
# Dans votre étape de build Maven/npm/Go :
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom
# Sortie : target/bom.json (format CycloneDX)

# Étape 2 : SBOM au niveau du conteneur (capture les paquets OS + dépendances runtime)
syft packages myapp:${BUILD_TAG} -o cyclonedx-json > container-sbom.cdx.json

# Étape 3 : Fusionner les SBOMs du build et du conteneur
cyclonedx merge \
  --input-files target/bom.json container-sbom.cdx.json \
  --output-file merged-sbom.cdx.json

# Étape 4 : Valider le SBOM fusionné
cyclonedx validate --input-file merged-sbom.cdx.json --fail-on-errors

# Étape 5 : Scanner le SBOM fusionné pour les vulnérabilités
trivy sbom merged-sbom.cdx.json --exit-code 1 --severity CRITICAL,HIGH

# Étape 6 : Signer et attester
cosign attest --predicate merged-sbom.cdx.json \
  --type cyclonedx myapp:${BUILD_TAG}

Ce pipeline atteint le meilleur de tous les mondes : les plugins CycloneDX fournissent la précision au moment du build, Syft ajoute la découverte de paquets au niveau du conteneur, le CLI CycloneDX fusionne et valide le SBOM combiné, Trivy scanne les vulnérabilités comme porte de qualité, et cosign fournit l’attestation cryptographique.

Considérations de performance

La vitesse compte dans les pipelines CI/CD où chaque minute de temps de build a un coût :

Syft est constamment rapide. Un scan typique d’image de conteneur se termine en 15–30 secondes sans téléchargement de base de données externe requis. Le binaire est léger et démarre instantanément.
Trivy nécessite un téléchargement initial de la base de données de vulnérabilités (~30–50 Mo) lors de la première exécution, ce qui ajoute 10–30 secondes. Les exécutions suivantes avec une base de données en cache sont comparables à Syft. L’utilisation de --skip-db-update en CI (avec un cache pré-chargé) élimine cette surcharge.
Les plugins CycloneDX ajoutent un temps négligeable aux builds car ils s’exécutent dans le cadre du processus de build existant. Il n’y a pas de phase de scan séparée — le SBOM est un sous-produit de la résolution de dépendances qui a déjà eu lieu.

Attestation et signature : prouver la provenance du SBOM

Un SBOM non signé est un document « faites-moi confiance ». Pour que les SBOMs aient une réelle valeur dans la sécurité de la chaîne d’approvisionnement, ils doivent être signés cryptographiquement et associés à l’artefact qu’ils décrivent.

Syft + cosign est le workflow d’attestation le plus mature. Anchore a investi massivement dans le support des attestations SLSA et in-toto, et la sortie de Syft est conçue pour alimenter directement cosign attest.

Trivy prend en charge l’attestation basée sur cosign et peut vérifier les attestations existantes. La sortie trivy image --format cosign-vuln produit des rapports de vulnérabilités prêts pour l’attestation.

CycloneDX prend en charge BOM-Link, qui fournit un mécanisme de liaison basé sur les URI entre les SBOMs et les artefacts qu’ils décrivent. Combiné avec Sigstore ou in-toto, cela crée une chaîne vérifiable de la source au déploiement.

Conclusion

Il n’existe pas de « meilleur » outil SBOM unique — le bon choix dépend de vos besoins spécifiques. Pour la profondeur pure de génération de SBOMs, Syft est la référence. Pour la simplicité tout-en-un, Trivy réduit considérablement la complexité de la chaîne d’outils. Pour la précision au moment du build et la gestion du cycle de vie des SBOMs, l’écosystème CycloneDX est inégalé.

L’approche la plus solide consiste à les combiner : utilisez les plugins CycloneDX au moment du build pour une précision maximale, Syft pour la découverte au niveau du conteneur, le CLI CycloneDX pour la fusion et la validation, et Trivy pour le scan de vulnérabilités. Ajoutez l’attestation cosign par-dessus, et vous disposez d’un pipeline SBOM de qualité production qui satisfait l’EO 14028, l’EU CRA et vos propres besoins de sécurité opérationnelle.

Prêt à construire ce pipeline concrètement ? Consultez notre Laboratoire SBOM pour un guide pas à pas avec de vraies images de conteneurs et des templates CI/CD.