Meilleurs outils SBOM en 2026

En bref

• Des SBOM gratuites pour les images de conteneur et les systèmes de fichiers : Syft, ou Trivy si vous voulez aussi un scanner de vulnérabilités, de secrets et d'IaC.
• Du CycloneDX à partir du code source : cdxgen, de la communauté CycloneDX.
• Du SPDX pour une sortie de build que vous empaquetez déjà : le Microsoft SBOM Tool.
• Des workloads sur AWS : l'Amazon Inspector SBOM Generator, qui alimente Amazon Inspector.
• Une SBOM rapide d'un dépôt GitHub : l'export du graphe de dépendances de GitHub.
• Un endroit gratuit et auto-hébergé pour surveiller les SBOM : OWASP Dependency-Track.
• La conformité des licences d'abord : FOSSA. Les SBOM de fournisseurs et de portefeuille : Manifest ou Cybeats. Les flottes de conteneurs et les packs de politiques gouvernementales : Anchore Enterprise.
• Une SBOM de ce que vos propres builds ont réellement récupéré, avec surveillance des vulnérabilités et données de provenance : CRACI, pour GitHub Actions.

Ce que fait un outil SBOM

Une nomenclature logicielle liste les composants, bibliothèques et dépendances d'un logiciel, dans un format lisible par machine tel que CycloneDX ou SPDX. Il existe deux types d'outils SBOM. Les générateurs écrivent la SBOM. Les gestionnaires stockent les SBOM de nombreux produits et fournisseurs, les confrontent aux données de vulnérabilité, appliquent des politiques et les partagent. Les gestionnaires dépendent de ce que leur fournissent les générateurs.

Le moment où la SBOM est établie compte autant que l'outil qui l'établit. Les recommandations de la CISA sur les types de SBOM distinguent une SBOM source, créée à partir de l'environnement de développement et des fichiers source, une SBOM build, générée lors de la construction de l'artefact publiable, et une SBOM analyzed, générée en analysant des artefacts tels que des exécutables et des images de conteneur après le build. La plupart des générateurs ci-dessous produisent des SBOM source ou analyzed. CRACI produit une SBOM build. La page SBOM générées au build explique la différence en détail.

À qui s'adresse cette page

Cette page s'adresse aux équipes qui ont besoin de SBOM, pour le Cyber Resilience Act, un questionnaire client ou leur propre travail sur les vulnérabilités, et qui font le tri parmi les options. Nous développons CRACI : tenez-en compte. Chaque affirmation sur un autre outil provient de sa propre documentation, et chaque outil dispose d'une page CRACI vs X plus détaillée.

Comment choisir un outil SBOM

• Devez-vous produire des SBOM, les gérer, ou les deux ? Un générateur vous donne un fichier. Un gestionnaire vous donne un endroit où conserver les fichiers de nombreux produits et fournisseurs, les enrichir et agir en conséquence.
• Le logiciel est-il le vôtre ou acheté ? Pour vos propres builds, vous contrôlez l'entrée et pouvez donc l'enregistrer. Pour les logiciels de fournisseurs, il vous faut de la collecte, de la validation et parfois de l'analyse de binaires.
• À quel point devez-vous être sûr que la liste est complète ? Les générateurs lisent des fichiers après coup, et ils se contredisent plus que la plupart des gens ne le pensent (voir ci-dessous). Une SBOM build décrit ce que le build a utilisé.
• Quel format vos clients demandent-ils ? CycloneDX et SPDX sont tous deux largement acceptés ; la plupart des outils écrivent au moins l'un des deux.
• Quelle CI utilisez-vous, et doit-elle être auto-hébergée ? Les générateurs open source s'exécutent partout. CRACI prend en charge GitHub Actions sous Linux aujourd'hui, en tant que service managé, et GitLab CI, Jenkins et les runners hébergés par le client figurent sur la roadmap.

Générateurs de SBOM

Ce comparatif porte sur ce que fait chaque générateur, et non sur le nombre de composants qu'il renvoie.

CRACI

CRACI est un enregistreur plutôt qu'un scanner. Vos jobs GitHub Actions s'exécutent sur des runners CRACI, et un proxy qui comprend les paquets enregistre ce que chaque job récupère, y compris les paquets restaurés depuis un cache CI. La SBOM, en CycloneDX ou SPDX, inclut les dépendances transitives utilisées par le build et indique sa complétude par job et par cache. CRACI continue ensuite de réévaluer les SBOM surveillées : il fait donc à la fois le travail d'un générateur et celui d'un gestionnaire. Idéal pour les logiciels que vous construisez dans GitHub Actions. Attention : il ne peut pas scanner une image ou un répertoire, et il exécute aujourd'hui des jobs Linux sur GitHub Actions (d'autres systèmes CI, Windows et macOS figurent sur la roadmap). La génération de SBOM dans CRACI

Syft

Syft est le générateur gratuit d'Anchore, sous Apache-2.0, pour les images de conteneur et les systèmes de fichiers. Il reconnaît des dizaines de types de paquets, écrit du CycloneDX, du SPDX et du Syft JSON, et peut créer des attestations SBOM in-toto signées. Grype, son compagnon, confronte la SBOM aux vulnérabilités. Idéal pour les images et pour tout pipeline qui a besoin d'un générateur gratuit. Attention : les catalogers sont choisis selon le type de scan, si bien que sur un checkout d'express installé, un seul flag décide si les paquets npm apparaissent ou non dans le résultat. CRACI vs Syft et Grype

Trivy

Trivy, d'Aqua Security, est un scanner polyvalent sous Apache-2.0 pour les images, les systèmes de fichiers, les dépôts, les images de VM et Kubernetes. Il trouve les vulnérabilités, les erreurs de configuration IaC, les secrets et les licences, et écrit du CycloneDX ou du SPDX en complément. Idéal pour les équipes qui veulent un seul binaire gratuit pour de nombreux contrôles de sécurité. Attention : pour un dépôt, il lit les lockfiles, si bien qu'express 5.2.1 (pas de lockfile) et claude-code (pas de manifeste) ne lui donnent rien à lire, exactement comme documenté. CRACI vs Trivy

cdxgen

cdxgen est un projet OWASP CycloneDX qui crée des BOM CycloneDX à partir des sources et des images de conteneur, sous Apache-2.0. Idéal pour les équipes standardisées sur CycloneDX qui veulent un générateur issu de la communauté du format. Attention : comme les autres scanners, il ne peut signaler que ce que déclarent les fichiers qu'on lui soumet. CRACI vs une pile SBOM maison

Microsoft SBOM Tool

Le Microsoft SBOM Tool est un générateur sous licence MIT qui écrit du SPDX 2.2, ou du SPDX 3.0 sur demande, et peut valider une SBOM par rapport à la spécification SPDX. Il attend en ligne de commande un dossier de dépôt de build, un nom de paquet, une version et un fournisseur, ce qui en fait une étape post-build, et il s'exécute dans GitHub Actions et Azure Pipelines. Idéal pour les équipes qui veulent du SPDX pour une sortie de build qu'elles empaquettent déjà. Attention : dirigé vers des dépôts tels que commités, plutôt que vers un dossier de dépôt de build, il n'a presque rien à décrire. Comme il prend un fournisseur en ligne de commande, il peut renseigner le champ fournisseur. CRACI vs une pile SBOM maison

Export du graphe de dépendances GitHub

Le graphe de dépendances de GitHub résume les manifestes et les lockfiles d'un dépôt, ainsi que tout ce qui est envoyé via l'API de soumission de dépendances, et s'exporte en SPDX depuis l'interface ou l'API REST. Il alimente les alertes Dependabot et est inclus dans tous les plans GitHub. Idéal pour les équipes déjà sur GitHub qui ont besoin d'une SBOM rapide. Attention : il reflète la branche par défaut plutôt qu'un commit épinglé, et il est construit à partir de ce que GitHub sait du dépôt plutôt qu'à partir de fichiers lus par un scanner. CRACI vs GitHub Advanced Security

Amazon Inspector SBOM Generator

Sbomgen est le générateur qui sous-tend le scan d'images, de Lambda et d'EC2 d'Amazon Inspector, proposé sous forme de binaire Linux autonome. Il lit les métadonnées de paquets dans les images de conteneur, les répertoires, les archives, les volumes montés et les binaires compilés Go et Rust, couvre les paquets système (APK, DPKG, RPM) et des langages tels que C#, Go, Java, Node.js, PHP, Python, Ruby et Rust, et écrit du CycloneDX. Il peut envoyer la SBOM à l'Amazon Inspector Scan API pour obtenir des résultats de vulnérabilités, ce qui nécessite un compte AWS. Idéal pour les équipes dont les workloads s'exécutent déjà sur AWS. Attention : il ne fonctionne que sous Linux et, comme les autres scanners, il trouve ce que déclarent les fichiers qu'il lit.

Safeguard

La CLI de Safeguard exécute Syft et Grype pour produire des SBOM CycloneDX et SPDX à partir de dépôts, d'images de conteneur et de manifestes téléversés, et sa plateforme ajoute des pull requests de correction écrites par l'IA et des gates de politique. Idéal pour les équipes qui veulent le scan et les corrections automatisées dans un seul abonnement. Attention : comme les autres scanners, il liste ce que déclarent les fichiers qu'il lit. CRACI vs Safeguard

Ce dont dépend une SBOM scannée

Dirigez les générateurs ci-dessus vers le même dépôt et ils renvoient des listes différentes. Voici les schémas que prédit la documentation des outils eux-mêmes :

• Les outils ne s'accordent pas sur ce qui compte comme composant. Chaque générateur décide lui-même des fichiers auxquels il se fie et de la façon de nommer ce qu'il trouve : un même dépôt donne donc à chacun une liste différente.
• Pas de lockfile, pas de dépendances. Express 5.2.1 n'en commite aucun : un générateur qui résout les dépendances à partir des lockfiles ne signale donc aucune de ses dépendances npm et renvoie tout ce qu'il reconnaît par ailleurs.
• Aucun manifeste. Le dépôt claude-code n'a ni manifeste ni lockfile : ce que renvoie chaque outil est donc assemblé à partir d'autres types de fichiers et en dit plus sur l'outil que sur le projet.
• Des métadonnées pauvres. Le champ fournisseur ressort souvent vide, car la plupart des générateurs n'ont aucune source pour le renseigner.

Aucun de ces outils n'est défectueux. Chacun lit les fichiers qu'on lui soumet, comme prévu. La leçon, c'est qu'une SBOM scannée dépend de l'outil, de ses réglages et du fait que quelqu'un ait installé ou non les dépendances au préalable. Pour ce que lisent Syft, Trivy et cdxgen, voir ce qui échappe aux générateurs de SBOM open source.

Gestionnaires de SBOM

Anchore Enterprise

Anchore Enterprise s'appuie sur Syft et Grype et ajoute ce dont les grandes organisations ont besoin : SBOM de conteneurs, de sources et de systèmes de fichiers, SBOM importées dont le schéma est validé, rescan continu sans l'artefact d'origine, et packs de politiques pour FedRAMP, NIST, CIS, PCI DSS et CMMC. Il se déploie sur Kubernetes, Docker Compose ou en environnement air-gapped. Idéal pour les flottes de conteneurs réparties sur plusieurs systèmes CI et pour les projets gouvernementaux. Attention : ses SBOM décrivent toujours ce qu'un scanner a trouvé, et le tarif est sur devis. CRACI vs Anchore

FOSSA

FOSSA a commencé par la conformité des licences : détection des licences en texte intégral, politiques et mentions d'attribution. Il génère et importe des SBOM SPDX et CycloneDX, peut ajouter des déclarations VDR ou VEX, vérifie les imports au regard des éléments minimaux NTIA et FDA, et partage les SBOM via un portail sur Enterprise. Le plan Free couvre 5 projets. Idéal pour les équipes dont la première préoccupation est le risque lié aux licences. Attention : sa CLI interroge vos outils de build lorsqu'un build fonctionnel est disponible et procède par inférence à partir des sources dans le cas contraire, et les scans de binaires et d'extraits de code sont proposés en option. CRACI vs FOSSA

Cybeats SBOM Studio

SBOM Studio se présente comme « le système de référence des SBOM ». Il importe et exporte SPDX 2.2 à 3.0.1 et CycloneDX 1.2 à 1.7, note la qualité des SBOM avant l'import, analyse en continu chaque composant et partage les données SBOM et VEX avec les clients, y compris via la Transparency Exchange API. Idéal pour les équipes de sécurité produit des secteurs ICS, des dispositifs médicaux, des télécoms et de l'automobile qui pilotent un programme SBOM. Attention : il gère les SBOM plutôt qu'il ne les produit, et un score de qualité confirme le format, pas ce que le générateur a manqué. CRACI vs Cybeats et Alternatives à Cybeats

Manifest

Manifest collecte, enrichit et partage les SBOM de vos produits, de vos fournisseurs et de vos modèles d'IA. Les fournisseurs téléversent via un portail sécurisé et, lorsqu'ils n'en fournissent aucune, Manifest peut analyser le binaire et en générer une. Il prend en charge SPDX, CycloneDX et VEX et s'aligne sur les recommandations de la FDA, NIST 800-218 et UNECE R155. Idéal pour les organisations dont la principale exposition tient aux logiciels qu'elles achètent. Attention : sa GitHub Action génère par défaut avec Syft les SBOM de vos propres logiciels. CRACI vs Manifest

OWASP Dependency-Track

Dependency-Track est une plateforme sous Apache 2.0 qui suit les composants de chaque version de chaque application, récupère les données de vulnérabilité de sources telles que la NVD et GitHub Advisories, applique des politiques de sécurité, de licence et d'exploitation, et consomme et produit du CycloneDX VEX. Les pipelines téléversent les SBOM via son API. Idéal pour les équipes qui veulent une plateforme d'analyse transparente et auto-hébergée. Attention : il ne génère pas de SBOM, et vous l'exploitez vous-même (le serveur d'API nécessite au moins 2 Go de RAM et 2 cœurs CPU). CRACI pour les utilisateurs de Dependency-Track

CycloneDX ou SPDX

Les deux formats sont des standards ouverts, et la plupart des outils de cette page écrivent au moins l'un d'eux. CycloneDX est un projet OWASP, normalisé par Ecma International sous le nom ECMA-424, qui transporte les données de vulnérabilité et VEX à côté de la liste des composants. SPDX est un projet de la Linux Foundation et une norme internationale, ISO/IEC 5962:2021. Le Cyber Resilience Act demande « un format couramment utilisé et lisible par machine » sans en citer aucun : choisissez donc le format que lisent vos clients et vos outils en aval. Voir les exemples de SBOM pour comparer les deux côte à côte, et les bonnes pratiques SBOM pour savoir comment les utiliser. Pour stocker et surveiller des SBOM à grande échelle, voir la gestion des SBOM.

La place de CRACI

CRACI n'est ni un scanner ni un gestionnaire. C'est un enregistreur. Vos jobs GitHub Actions s'exécutent sur des runners CRACI (remplacez runs-on par craci), et un proxy qui comprend les paquets enregistre ce que chaque job récupère depuis les sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement. Les paquets restaurés depuis un cache CI conservent leurs preuves. La SBOM, en CycloneDX ou SPDX, inclut les dépendances transitives utilisées par le build et indique sa complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale.

Après le build, CRACI continue de réévaluer les SBOM surveillées, agrège les vulnérabilités de l'ensemble des builds et des dépôts, prend en charge VEX, renvoie les SBOM, les traces réseau et la provenance via son API, et exporte les SBOM sous forme de fichiers CycloneDX ou SPDX. Les SBOM des fournisseurs peuvent être ajoutées, afin que les composants achetés soient surveillés aux côtés de vos propres builds. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA. Voir la génération de SBOM dans CRACI pour l'ensemble de la fonctionnalité.

CRACI fait donc à la fois le travail d'un générateur et celui d'un gestionnaire, pour les logiciels que vous construisez. Ce n'est pas le bon choix lorsque :

• vous avez besoin de SBOM pour des images ou des logiciels que vous n'avez pas construits (utilisez un générateur tel que Syft ou Trivy),
• vous avez besoin d'un moteur de politiques mature, avec de nombreux types de règles, pour un portefeuille de produits et de fournisseurs (utilisez un gestionnaire),
• vos pipelines s'exécutent en dehors de GitHub Actions, sous Windows ou macOS, ou doivent être auto-hébergés (tout cela figure sur la roadmap de CRACI).

Le moyen le plus rapide de juger est de comparer côte à côte : réservez une démo, exécutez l'un de vos workflows sur CRACI et placez sa SBOM à côté de celle que produit votre outil actuel.

Voir aussi le comparatif des outils SCA, SBOM générées par l'IA vs SBOM au build et pourquoi les SBOM au build diffèrent des SBOM scannées.

Outils SBOM : questions fréquentes

Qu'est-ce qu'un outil SBOM ?

Un outil SBOM produit ou gère une nomenclature logicielle : une liste lisible par machine des composants, bibliothèques et dépendances d'un logiciel. Des générateurs tels que Syft, Trivy et cdxgen écrivent la SBOM en lisant des fichiers. Des gestionnaires tels que Dependency-Track, FOSSA et Anchore Enterprise stockent les SBOM, les confrontent aux données de vulnérabilité et les partagent. CRACI enregistre la SBOM pendant le build lui-même et la surveille ensuite.

Quel est le meilleur outil SBOM gratuit ?

Tout dépend de ce que vous voulez analyser. Syft et Trivy sont des générateurs gratuits sous Apache-2.0 pour les images de conteneur et les systèmes de fichiers. cdxgen écrit du CycloneDX à partir des sources et des images. Le Microsoft SBOM Tool écrit du SPDX pour un dossier de sortie de build. OWASP Dependency-Track est un gestionnaire gratuit et auto-hébergé pour les SBOM produites par ces outils.

Faut-il utiliser Syft ou Trivy ?

Syft se concentre sur la génération de SBOM et s'associe à Grype pour le rapprochement des vulnérabilités. Trivy est un scanner plus large qui trouve aussi les erreurs de configuration IaC, les secrets et les licences, et écrit du CycloneDX ou du SPDX au passage. Tous deux lisent les fichiers qu'on leur soumet : ils dépendent donc tous deux de la présence de lockfiles ou de paquets installés.

CycloneDX ou SPDX : quel format de SBOM utiliser ?

Tous deux sont des standards ouverts et largement pris en charge. CycloneDX est un projet OWASP, normalisé par Ecma International sous le nom ECMA-424, qui transporte aussi des données de vulnérabilité et VEX. SPDX est un projet de la Linux Foundation et une norme internationale, ISO/IEC 5962:2021. Utilisez celui que demandent vos clients et vos outils en aval ; la plupart des générateurs écrivent les deux.

Pourquoi les outils SBOM donnent-ils des résultats différents pour un même projet ?

Chaque générateur décide des fichiers auxquels il se fie et de ce qui compte comme composant. Certains lisent les lockfiles, d'autres les paquets installés, d'autres encore les binaires, et un dépôt sans lockfile ne donne rien à exploiter à un lecteur de lockfiles. Une SBOM scannée dépend de l'outil, de ses réglages et du fait que les dépendances aient été installées ou non avant le scan. Une SBOM au build évite cela en enregistrant ce que le build a réellement récupéré.

Le Cyber Resilience Act impose-t-il un outil ou un format de SBOM précis ?

Non. L'annexe I, partie II du CRA demande aux fabricants d'établir une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de niveau supérieur des produits. CycloneDX et SPDX conviennent tous les deux. Le règlement ne cite aucun outil.

CRACI peut-il générer une SBOM pour un logiciel que je n'ai pas construit ?

Non. CRACI enregistre les builds exécutés sur ses runners : ses SBOM décrivent donc les logiciels que vous construisez. Pour les logiciels que vous achetez, vous pouvez ajouter la SBOM du fournisseur à CRACI et la surveiller aux côtés de vos propres builds. Pour une image de conteneur tierce que vous n'avez pas construite, un scanner tel que Syft ou Trivy est le choix pratique.

Quels systèmes CI CRACI prend-il en charge ?

GitHub Actions aujourd'hui, sur des runners Linux x86-64 et ARM64. Vous remplacez runs-on par craci et les exécutions continuent d'apparaître dans GitHub. D'autres systèmes CI, à commencer par GitLab CI et Jenkins, figurent sur la roadmap.