SBOM en CI/CD : utile ou encore trop théorique ?

Le SBOM, pour Software Bill of Materials, n’est plus seulement un sujet de conformité réservé aux grands groupes ou aux appels d’offres sensibles. En 2026, il s’impose surtout comme un objet opérationnel dans les pipelines CI/CD : savoir ce qu’on embarque, retrouver rapidement une dépendance exposée, documenter un artefact livré, et éviter de découvrir trop tard qu’un composant critique était déjà présent depuis des mois.

Le problème, c’est que beaucoup d’équipes ont encore une image très théorique du SBOM. Sur le terrain, la question n’est pas “faut-il un SBOM ?” mais plutôt : où le générer, à quel format, avec quels outils, et pour quel usage concret sans ralentir les builds ni multiplier les couches de sécurité décoratives.

Dans un pipeline existant, le SBOM n’a de valeur que s’il s’insère proprement dans les étapes déjà en place : build, packaging, signature, publication d’artefacts, scan de vulnérabilités, déploiement et traçabilité. Sinon, il devient vite un fichier de plus stocké quelque part, jamais relu, rarement exploité, et souvent source de bruit.

Cet article prend volontairement un angle pratique. Pas de grand discours sur la gouvernance abstraite : l’objectif est de voir où le SBOM apporte vraiment de la valeur dans un pipeline CI/CD, où il devient coûteux, et comment le mettre en place de façon progressive avec des outils réellement utilisés comme CycloneDX, SPDX, Syft, Trivy, Sigstore ou encore les registres d’artefacts modernes.

Pourquoi le SBOM revient au centre des pipelines en 2026

Le retour du SBOM au premier plan tient à plusieurs réalités très concrètes.

D’abord, la chaîne d’approvisionnement logicielle est devenue plus complexe. Une application moderne assemble souvent : des dépendances directes, des dépendances transitives, des images de base, des paquets système, des bibliothèques embarquées, parfois des binaires téléchargés au build, et de plus en plus d’artefacts produits par plusieurs équipes. Sans inventaire exploitable, la visibilité est fragmentée.

Ensuite, les incidents de sécurité récents ont ancré une attente simple : pouvoir répondre vite à la question “sommes-nous concernés ?” lorsqu’une bibliothèque, une image de base ou un composant tiers est touché. Le SBOM ne remplace ni le scan de vulnérabilités ni l’analyse de risque, mais il accélère la phase de qualification. Quand l’inventaire est déjà attaché à l’artefact livré, on évite de reconstruire l’historique dans l’urgence.

Il y a aussi un effet d’écosystème. Les formats se sont stabilisés autour de standards connus, principalement CycloneDX et SPDX. Les outils de génération et de lecture se sont multipliés, et de nombreux scanners savent désormais consommer ces formats. Le sujet est donc moins “expérimental” qu’il y a quelques années.

Enfin, le SBOM intéresse de plus en plus les équipes produit et infra pour des raisons qui dépassent la sécurité pure :

mieux comprendre ce qui est réellement déployé en production ;
garder une trace des composants embarqués par version d’artefact ;
faciliter les audits internes ou contractuels sans travail manuel de dernière minute ;
raccorder plus proprement la sécurité aux pipelines déjà existants.

Un SBOM utile n’est pas un document de conformité. C’est un inventaire versionné, rattaché à un artefact, exploitable par des humains et des outils.

Dit autrement : le SBOM revient au centre des pipelines parce qu’il répond à un besoin très terre à terre de traçabilité logicielle. La conformité peut en bénéficier, mais elle n’est pas le seul moteur.

Ce qu’un SBOM apporte vraiment dans un pipeline CI/CD

Avant de parler intégration, il faut clarifier la promesse réelle. Beaucoup d’équipes attendent trop du SBOM, ou au contraire le rejettent parce qu’elles le comparent à tort à un scanner de vulnérabilités.

Un SBOM sert d’abord à décrire la composition d’un artefact. Il peut inclure selon l’outil et le périmètre :

les dépendances applicatives ;
les paquets système présents dans une image ou un conteneur ;
les versions identifiées ;
les relations entre composants ;
des métadonnées de build ou de fournisseur.

En pratique, cela permet plusieurs usages utiles en CI/CD :

Accélérer l’analyse d’impact

Lorsqu’une faille affecte une bibliothèque connue, disposer d’un SBOM stocké avec l’artefact évite de relancer des builds ou des scans exploratoires juste pour savoir si le composant est présent. Ce n’est pas toujours suffisant pour qualifier l’exposition réelle, mais c’est un excellent point de départ.

Rendre les livrables plus traçables

Si chaque image ou paquet publié a son SBOM associé, on sait mieux ce qui a été livré à un instant donné. C’est particulièrement utile quand plusieurs pipelines publient dans le même registre ou quand un produit mélange composants internes et externes.

Fiabiliser les échanges entre équipes

Les équipes sécurité, plateforme, produit et exploitation ne regardent pas les mêmes signaux. Le SBOM peut servir d’objet commun : il ne dit pas si un composant est acceptable, mais il dit clairement qu’il est là.

Préparer la suite : signatures, attestations, provenance

Dans beaucoup d’organisations, le SBOM devient plus intéressant quand il s’insère dans une chaîne plus large de confiance : artefact signé, attestation de build, provenance, politique d’admission. Des outils de l’écosystème Sigstore, comme cosign, sont souvent utilisés dans cette logique.

En revanche, il faut rester lucide sur ses limites. Un SBOM n’indique pas automatiquement :

si une vulnérabilité est exploitable dans votre contexte ;
si le composant est réellement utilisé à l’exécution ;
si la version détectée est correcte dans tous les cas ;
si votre build est reproductible ou sain par construction.

Le bon réflexe consiste donc à voir le SBOM comme une couche de visibilité, pas comme une preuve complète de sécurité.

À quel moment générer un SBOM dans la chaîne CI/CD

C’est le point le plus important, et souvent le plus mal traité. Générer un SBOM “quelque part dans le pipeline” ne suffit pas. Le moment choisi détermine sa qualité, son coût et son utilité.

Génération au moment du build applicatif

Pour une application Java, Node.js, Python, Go, .NET ou autre, un SBOM peut être produit pendant le build à partir du graphe de dépendances du projet. C’est souvent la méthode la plus simple pour récupérer les dépendances applicatives avec un bon niveau de précision.

Avantages :

bonne visibilité sur les dépendances du projet ;
intégration naturelle dans les outils de build ;
coût généralement faible.

Limites :

ne couvre pas forcément les paquets système ou l’image de base ;
peut manquer des composants ajoutés plus tard dans le packaging.

Exemple concret : une équipe qui construit une application Java avec Maven peut produire un SBOM applicatif pendant le job de build, puis le publier comme artefact intermédiaire du pipeline.

Génération au moment du packaging ou de l’image conteneur

Pour les applications déployées en conteneur, produire un SBOM à partir de l’image finale est souvent plus représentatif de ce qui sera exécuté. Des outils comme Syft ou Trivy savent analyser une image OCI et lister à la fois les dépendances applicatives détectables et les paquets système.

Avantages :

meilleure représentation du runtime réel ;
prise en compte de l’image de base et des paquets OS ;
alignement fort avec l’artefact déployé.

Limites :

scan parfois plus coûteux qu’un simple export depuis l’outil de build ;
résultats dépendants de la qualité de détection de l’outil.

Sur le terrain, beaucoup d’équipes finissent avec deux niveaux complémentaires : un SBOM applicatif au build, puis un SBOM de l’image finale avant publication. Ce n’est pas toujours nécessaire, mais c’est souvent le meilleur compromis pour les environnements conteneurisés.

Génération après publication : rarement le meilleur choix

Il est possible de scanner un artefact déjà poussé dans un registre ou un repository, mais cette approche a un inconvénient majeur : on décorrèle le SBOM du pipeline producteur. Résultat, la traçabilité devient moins évidente, et la génération peut dépendre d’un processus secondaire moins fiable.

Si votre objectif est d’avoir un SBOM exploitable en cas d’incident, il vaut mieux le générer dans le pipeline qui fabrique l’artefact, pas dans un traitement asynchrone ajouté après coup, sauf contrainte forte.

Quand signer et où stocker le SBOM sans alourdir les builds

Une fois le SBOM généré, deux questions arrivent vite : faut-il le signer, et où le stocker ?

Signer après génération, au plus près de l’artefact publié

Si vous signez vos artefacts, il est cohérent de traiter le SBOM comme un objet de supply chain à part entière. Le but n’est pas de “faire plus sécurisé” sur le papier, mais de garantir qu’un inventaire donné correspond bien à un artefact donné et n’a pas été modifié discrètement.

Dans les chaînes modernes, on voit souvent :

une signature de l’image ou du binaire publié ;
une signature du SBOM lui-même ;
ou une attestation liant l’artefact et son SBOM.

L’écosystème Sigstore est fréquemment utilisé pour cela, notamment avec cosign pour signer des images, attestations et artefacts associés. L’intérêt opérationnel est réel si vous avez déjà une logique de vérification à la publication ou à l’admission en cluster.

En revanche, si votre organisation n’a aucune consommation en aval de ces signatures, commencer par signer tous les SBOM sans usage concret peut être prématuré. Mieux vaut d’abord fiabiliser la génération et le stockage.

Stocker le SBOM avec l’artefact, pas dans un dossier isolé

Le meilleur emplacement est généralement celui où vivent déjà vos artefacts de release :

registre d’images conteneur ;
repository Maven ou npm privé ;
gestionnaire d’artefacts comme JFrog Artifactory ou Sonatype Nexus Repository ;
stockage d’artefacts du CI, si c’est la seule option disponible à court terme.

L’idée est simple : un artefact versionné doit avoir son SBOM versionné à côté. Si le fichier est publié dans un bucket ou un répertoire séparé, sans lien fort avec le digest ou la version, sa valeur opérationnelle chute rapidement.

Privilégier les formats standards

En 2026, le débat n’est plus vraiment de savoir s’il faut un format propriétaire. Pour maximiser l’interopérabilité, CycloneDX et SPDX restent les choix naturels. CycloneDX est souvent apprécié pour son orientation sécurité et composants, tandis que SPDX est très présent dans les sujets de licence et d’échange standardisé.

Le choix dépend surtout de vos outils consommateurs. Le plus important est d’éviter les conversions multiples, qui ajoutent de la complexité et parfois des pertes d’information.

Les outils réellement utilisés pour intégrer un SBOM en pipeline

Le marché est large, mais quelques outils reviennent souvent dans les implémentations pragmatiques.

Syft pour générer un SBOM d’image ou de système de fichiers

Syft est largement utilisé pour produire des SBOM à partir d’images conteneur, de répertoires ou de systèmes de fichiers. Il sait exporter notamment en CycloneDX et SPDX. Son intérêt principal est sa simplicité d’usage dans un job CI.

Trivy pour combiner inventaire et sécurité

Trivy, connu pour le scan de vulnérabilités, sait aussi générer des SBOM. Pour des équipes qui veulent limiter le nombre d’outils dans le pipeline, c’est souvent une option attractive, à condition de bien distinguer les usages : générer un inventaire n’est pas la même chose que bloquer un build sur une CVE.

Plugins et générateurs liés aux écosystèmes de build

Selon la stack, il existe des générateurs intégrés ou des plugins pour Maven, Gradle, npm et d’autres environnements. Leur intérêt est de produire un SBOM très tôt, directement depuis les dépendances déclarées et résolues par le build.

Cosign et les mécanismes d’attestation

Pour signer ou attester les artefacts et documents associés, cosign est un choix fréquent dans les chaînes cloud-native. Il s’intègre bien avec les registres OCI et permet de rattacher des métadonnées à un artefact publié.

Le bon choix d’outillage dépend moins de la “richesse fonctionnelle” que de trois critères très concrets :

est-ce que l’outil s’intègre facilement dans votre CI actuel ?
est-ce que sa sortie est consommable par vos scanners ou vos équipes ?
est-ce qu’il produit des résultats stables, compréhensibles et reproductibles ?

Si la réponse est non, vous créez de la dette d’outillage avant même d’avoir créé de la valeur.

Les limites terrain : bruit, faux positifs et dette d’outillage

C’est ici que beaucoup de déploiements SBOM déraillent. Non pas parce que le principe est mauvais, mais parce que l’intégration est pensée comme une obligation de plus, sans cadrer l’usage réel.

Le bruit vient souvent de la confusion entre SBOM et scanning

Un SBOM brut peut contenir beaucoup de composants, y compris des éléments peu pertinents pour une équipe produit au quotidien. Si chaque génération déclenche ensuite des alertes sans tri ni politique claire, on retombe dans un problème classique de fatigue opérationnelle.

Le fichier en lui-même n’est pas le bruit. Le bruit vient de la façon dont on l’exploite.

Les faux positifs ne disparaissent pas avec un meilleur format

Qu’un SBOM soit en CycloneDX ou SPDX ne change pas le fait que l’identification de composants peut être imparfaite, surtout dans des images complexes, des binaires compilés statiquement ou des environnements hybrides. Il faut accepter qu’un inventaire automatisé reste une approximation utile, pas une vérité absolue.

La volumétrie peut devenir pénible

Si vous générez un SBOM à chaque commit, pour chaque variante d’image, puis le rescanner dans plusieurs outils, le coût cumulé peut devenir visible. Pas forcément en CPU pur, mais en temps de pipeline, stockage, maintenance et support aux équipes.

Le bon niveau de fréquence dépend du cycle de livraison. Pour certaines équipes, générer un SBOM sur chaque build de merge vers la branche principale est pertinent. Pour d’autres, le réserver aux builds de release ou aux images promues suffit largement.

La dette d’outillage est réelle

Ajouter un générateur, un convertisseur, un scanner, un signataire, un stockage dédié et une policy engine pour un besoin encore mal défini est la recette parfaite pour créer une mini-usine à gaz. On voit parfois des pipelines où le SBOM existe, mais où personne ne sait :

quelle version fait foi ;
qui le consomme ;
quels builds doivent échouer ;
où retrouver le document exact lié à une release.

Si votre équipe ne sait pas quoi faire d’un SBOM une fois généré, le problème n’est pas le format. C’est l’absence de scénario d’usage.

Une mise en place pragmatique pour équipes produit et infra

La bonne approche consiste à intégrer le SBOM comme une extension naturelle du pipeline, pas comme un chantier parallèle. Voici une trajectoire simple et réaliste.

1. Commencer par les artefacts qui comptent vraiment

Inutile de couvrir tout le SI dès le départ. Ciblez d’abord :

les images conteneur déployées en production ;
les binaires ou paquets distribués à des clients ou à d’autres équipes ;
les composants exposés à des exigences contractuelles ou de sécurité plus fortes.

Cette priorisation évite d’équiper des pipelines secondaires sans enjeu immédiat.

2. Générer un SBOM au moment où l’artefact final existe

Pour une majorité d’équipes DevOps, le point le plus rentable est la fin du build d’image ou du packaging final. À ce moment-là, vous savez ce qui va être publié, tagué et éventuellement déployé.

Concrètement, un pipeline peut suivre cette logique :

build de l’application ;
construction de l’image conteneur ;
génération du SBOM de l’image finale avec Syft ou Trivy ;
publication de l’image et du SBOM ;
signature ou attestation si ce mécanisme existe déjà ;
scan de vulnérabilités ou contrôles complémentaires.

Cet enchaînement reste lisible et n’introduit pas trop de ruptures dans le flux.

3. Ne bloquez pas les builds trop tôt

Au démarrage, le plus sain est souvent de générer et publier avant de chercher à faire échouer. Tant que les équipes n’ont pas confiance dans la qualité des données et dans les usages en aval, transformer le SBOM en garde-fou bloquant crée surtout de la friction.

Une fois les inventaires stabilisés, vous pourrez définir des politiques plus ciblées, par exemple sur certains composants interdits, sur des artefacts non signés, ou sur l’absence de SBOM pour une release de production.

4. Définir un propriétaire opérationnel

Le SBOM traverse plusieurs domaines. Sans propriétaire clair, il devient vite “à tout le monde donc à personne”. En pratique, la responsabilité est souvent partagée :

l’équipe plateforme ou DevOps fournit le mécanisme standard dans les pipelines ;
les équipes produit valident que les artefacts critiques sont bien couverts ;
la sécurité définit les besoins de consommation et les règles minimales.

Ce partage fonctionne à condition qu’un point de vérité soit clairement identifié dans la chaîne de build.

5. Mesurer la valeur avec des cas d’usage simples

Plutôt que de compter le nombre de SBOM générés, mesurez des choses utiles :

peut-on retrouver le SBOM d’une release en quelques minutes ?
est-il lié à l’artefact exact publié ?
permet-il de répondre plus vite lors d’une alerte sur une dépendance ?
évite-t-il des recherches manuelles lors d’un audit ou d’un incident ?

Si la réponse est oui, vous êtes sur une trajectoire saine. Si la réponse est non, il faut simplifier avant d’ajouter de nouvelles couches.

Ce qui apporte vraiment de la valeur en 2026, et ce qui peut attendre

En 2026, la valeur du SBOM dans un pipeline CI/CD ne vient pas du fait d’en produire un “par principe”. Elle vient de quelques pratiques précises.

Ce qui apporte de la valeur rapidement

générer le SBOM dans le pipeline producteur de l’artefact ;
le rattacher clairement à la version ou au digest publié ;
utiliser un format standard comme CycloneDX ou SPDX ;
couvrir en priorité les artefacts réellement déployés ou distribués ;
permettre aux équipes de le retrouver facilement en cas d’incident.

Ce qui peut attendre si votre maturité est encore limitée

les chaînes complexes de conversion entre formats ;
les politiques bloquantes sur tous les builds ;
la signature systématique de tout, sans vérification réelle en aval ;
la couverture exhaustive de tous les jobs techniques non critiques.

Le meilleur indicateur de maturité n’est pas le nombre d’outils branchés, mais la capacité à répondre proprement à une question simple : pour cet artefact en production, savons-nous précisément quels composants il contient, et pouvons-nous le prouver rapidement ?

Conclusion

Le SBOM n’est ni une mode vide, ni une solution miracle. Dans un pipeline CI/CD bien pensé, c’est un outil de traçabilité concret qui aide à mieux comprendre ce que l’on livre, à accélérer l’analyse d’impact et à structurer la sécurité supply chain sans forcément transformer la chaîne de build en usine à gaz.

La clé, c’est la sobriété : générer au bon moment, stocker au bon endroit, signer seulement quand cela sert un usage réel, et éviter de confondre inventaire, conformité et décision de sécurité. Pour beaucoup d’équipes produit et infra, une intégration simple autour de l’artefact final apporte déjà une valeur nette.

Si vous travaillez déjà sur la fiabilisation de vos pipelines, c’est probablement le bon moment pour regarder où un SBOM peut s’insérer sans casser le flux existant. Et si vous voulez garder cette approche terrain du DevOps et de l’automatisation, les autres articles de Pipeline Brut prolongent justement cette logique.