Chronique no 008 — 2026
Du SBOM contractuel au SBOM vivant
Votre SBOM dort dans un tiroir ? Chronique 008 : transformer la liste d'ingrédients logiciels en radar de détection des vulnérabilités et de pilotage du risque tiers.
Du SBOM contractuel au SBOM vivant : quand la liste devient un radar
La supply chain logicielle est la dépendance invisible par excellence. La plupart des organisations ont un SBOM. Presque aucune ne s’en sert.
Introduction
Fin 2021, une vulnérabilité critique est découverte dans Log4j, une bibliothèque Java utilisée par des millions d’applications. Dans les heures qui suivent, une question simple paralyse des milliers d’équipes : « est-ce qu’on utilise ce composant, et où ?» La plupart n’ont pas la réponse. Pas parce qu’elles sont incompétentes. Parce qu’elles n’ont pas d’inventaire vivant de ce qui tourne dans leurs systèmes.
Dans l’épisode 005, nous avons posé un principe fondateur : la transparence des composants doit devenir un critère d’achat. Exiger un SBOM — un Software Bill of Materials, la liste des « ingrédients » logiciels — de ses fournisseurs est un acte de gouvernance. L’épisode 007 a annoncé la suite logique : passer de la demande à l’exploitation.
Nous y sommes. Aujourd’hui, le SBOM n’est plus un sujet d’avant-vente. C’est un sujet d’exploitation. Le Cyber Resilience Act européen (CRA), entré en vigueur en décembre 2024, rend sa production obligatoire. La CISA américaine a publié en 2025 une mise à jour de ses éléments minimaux. Les formats sont matures (CycloneDX, SPDX). L’outillage existe.
Et pourtant, dans la grande majorité des organisations, le SBOM reste ce qu’il était à sa réception : un fichier dans un répertoire. La vraie question n’est pas « avez-vous un SBOM ?». C’est : « qu’en faites-vous ?»
1. Le SBOM contractuel : nécessaire, mais inerte
Obtenir un SBOM de ses fournisseurs est déjà un progrès considérable. C’est la première marche. Mais cette marche, seule, ne protège de rien.
Le SBOM contractuel est un instantané. Il décrit la composition d’un logiciel au moment de sa livraison. Il liste les composants, leurs versions, parfois leurs licences. C’est un document de conformité, pas un outil opérationnel.
Le problème est temporel. Le jour où le SBOM est émis, il est déjà en retard. Les vulnérabilités apparaissent après la livraison. Les composants évoluent, les dépendances changent, les correctifs s’accumulent. Un SBOM figé, c’est une carte routière de 2019 pour naviguer en 2026.
On trouve des SBOM dans les dossiers d’architecture. Mais rarement dans les consoles de sécurité. On trouve des listes de composants. Mais rarement la corrélation avec les vulnérabilités connues (CVE) du jour. Sans exploitation continue, le SBOM est un acte administratif, pas un levier de résilience.
Le SBOM contractuel est un point de départ. S’y arrêter, c’est confondre la prescription avec le traitement.
2. Ce que signifie « vivant » : du fichier au flux
Un SBOM vivant, c’est un SBOM qui travaille en permanence. Concrètement, cela implique trois capacités que le document statique ne possède pas.
Premièrement, la corrélation automatique avec les bases de vulnérabilités. Chaque composant du SBOM est mappé en continu contre les bases CVE/NVD et les flux de Threat Intelligence. Quand une nouvelle faille est publiée, le système identifie en minutes — pas en semaines — quels produits de l’organisation sont concernés.
Deuxièmement, le suivi des versions et du cycle de vie. Le SBOM vivant intègre les mises à jour des composants au fil du temps. Il sait qu’un composant approche de sa fin de support, qu’un autre a été forké, qu’un troisième n’est plus maintenu. C’est un signal d’alerte précoce sur l’obsolescence, le thème central de notre épisode 005.
Troisièmement, l’enrichissement par le VEX. Le Vulnerability Exploitability eXchange (VEX) est le complément naturel du SBOM. Là où le SBOM dit « ce composant est présent », le VEX dit « cette vulnérabilité l’affecte réellement » ou « non, elle ne s’applique pas dans ce contexte ». Sans VEX, chaque CVE génère du bruit. Avec VEX, on obtient du signal.
Le SBOM vivant n’est pas un format différent. C’est un usage différent : passer du document archivé au flux opérationnel intégré.
3. Le cadre réglementaire : une convergence mondiale
L’obligation de produire et d’exploiter des SBOM n’est plus une recommandation. C’est un mouvement réglementaire global.
Côté européen, le Cyber Resilience Act (CRA) impose aux fabricants de produits numériques de documenter leurs composants logiciels dans un format lisible par machine, de maintenir cette documentation tout au long du cycle de vie du produit, et de la tenir à disposition des autorités de surveillance. Les obligations de reporting de vulnérabilités s’appliqueront dès septembre 2026, l’ensemble des exigences d’ici décembre 2027.
Côté américain, la CISA a publié en 2025 une mise à jour des SBOM Minimum Elements, rehaussant les exigences par rapport au cadre NTIA de 2021. Les champs de données sont plus précis, les pratiques de partage mieux définies, l’automatisation attendue plus poussée.
Cette convergence transatlantique envoie un message clair : le SBOM est en train de passer du « nice to have » au « must have ». Les organisations qui n’ont pas encore de processus pour le recevoir, le stocker et l’exploiter accumulent une dette de conformité qui se transformera en dette de sécurité.
La réglementation ne demande pas juste de posséder un SBOM. Elle attend qu’il serve à piloter le risque.
4. Les quatre niveaux de maturité SBOM
Toutes les organisations ne partent pas du même point. Pour évaluer sa posture et définir une trajectoire, voici une grille de maturité en quatre niveaux.
Niveau Intitulé Caractéristique Risque résiduel —————— — — ————————————— 0 — Absent Aucun SBOM Pas de visibilité sur les composants tiers Aveugle face aux supply chain attacks 1 — Contractuel SBOM reçu et archivé Document statique, non exploité, non mis à jour Fausse assurance de couverture 2 — Corrélé SBOM croisé avec les CVE Corrélation manuelle ou périodique avec les bases de vulnérabilités Délai de détection trop long 3 — Vivant SBOM intégré et automatisé Corrélation continue, VEX, alertes temps réel, intégration dans la gestion de vulnérabilités Résiduel maîtrisé et piloté
La majorité des organisations se situent entre le niveau 0 et 1. L’objectif réaliste à 12 mois : atteindre le niveau 2 sur les actifs critiques.
5. L’intégration opérationnelle : où brancher le SBOM
Le SBOM vivant ne fonctionne pas en silo. Il prend sa valeur quand il est connecté aux processus existants de sécurité et d’exploitation. Trois points d’intégration sont prioritaires.
La gestion des vulnérabilités. C’est le cas d’usage premier. Le SBOM alimente le processus de scan et de priorisation des correctifs. Quand une CVE critique sort, l’équipe sécurité sait en minutes quels produits sont exposés, chez quels fournisseurs, sur quels environnements. C’est exactement ce qui a manqué à des milliers d’organisations lors de Log4Shell.
Le pilotage du risque tiers. Le SBOM enrichit la cartographie des dépendances. Un fournisseur utilise un composant en fin de vie ? Un autre embarque une librairie connue pour ses failles récurrentes ? Ces signaux alimentent la gouvernance fournisseur et les comités de risque. Le SBOM donne une profondeur que le questionnaire annuel de conformité n’atteint pas.
La réponse à incident. En cas de compromission d’un composant (scénario SolarWinds, MOVEit), le SBOM permet d’identifier l’exposition en heures au lieu de semaines. C’est un accélérateur de détection et de confinement, deux piliers de la résilience opérationnelle.
Le SBOM vivant ne remplace aucun outil. Il connecte les outils entre eux et leur donne une information qu’ils n’avaient pas : la composition réelle du logiciel déployé.
6. Formats et outillage : le choix pragmatique
Deux formats dominent l’écosystème SBOM : SPDX (porté par la Linux Foundation, normalisé ISO/IEC 5962) et CycloneDX (porté par l’OWASP, orienté sécurité). Les deux sont reconnus par les régulateurs. Les deux supportent l’automatisation.
Le choix du format compte moins que la capacité à l’exploiter. Un SBOM en CycloneDX stocké dans un partage réseau n’a pas plus de valeur qu’un SBOM en SPDX dans une boîte mail. La question déterminante est : avez-vous une plateforme capable de l’ingérer, de le corréler et de générer des alertes ?
Côté outillage, l’écosystème s’est considérablement enrichi. Des solutions open source (Dependency-Track, Grype, Syft) aux plateformes commerciales intégrées, le marché propose désormais des outils capables de gérer le cycle de vie complet du SBOM : ingérer, stocker, corréler, alerter, enrichir par VEX.
Ce qui manque rarement, c’est l’outil. Ce qui manque souvent, c’est le processus : qui réceptionne le SBOM, qui le charge, qui surveille les alertes, qui décide de l’action correctrice. Ce n’est pas un sujet technique. C’est un choix organisationnel.
Ne cherchez pas le format parfait. Cherchez le processus qui transforme un fichier en capacité de détection.
7. Checklist : activer son SBOM en 8 étapes
Pour passer du niveau 1 (contractuel) au niveau 3 (vivant), voici un chemin en huit étapes.
1. Inventorier les SBOM existants. Récupérer tous les SBOM déjà fournis par les éditeurs et fournisseurs. Vérifier leur format (CycloneDX, SPDX, autre) et leur date.
2. Identifier les actifs critiques. Concentrer l’effort sur les applications et composants qui portent les processus métiers essentiels. Pas besoin de tout couvrir d’un coup.
3. Choisir une plateforme d’exploitation SBOM. Open source ou commerciale, l’important est la capacité d’ingérer les formats standard et de corréler avec NVD/CVE.
4. Charger et corréler. Importer les SBOM dans la plateforme. Lancer la première corrélation. Préparez-vous : la liste de vulnérabilités sera probablement longue.
5. Prioriser par le VEX. Demander aux fournisseurs des attestations VEX pour qualifier l’exploitabilité réelle des vulnérabilités identifiées. Pas de VEX ? C’est un signal sur la maturité du fournisseur.
6. Intégrer dans le cycle de vulnérabilités. Les alertes SBOM doivent alimenter le même processus que les scans internes : qualification, priorisation, remeédiation, suivi.
7. Contractualiser la mise à jour. Inscrire dans les contrats l’obligation de livrer un SBOM mis à jour à chaque release majeure ou patch de sécurité.
8. Gouverner. Désigner un propriétaire du processus SBOM. Définir les indicateurs : nombre de composants non couverts, délai de corrélation, taux de réponse fournisseur.
Huit étapes. Pas besoin d’un programme de transformation. Il faut une décision, un responsable et un premier lot d’actifs critiques.
8. Les pièges à éviter
L’activation du SBOM n’est pas sans risques de dérive. Trois pièges reviennent systématiquement.
Le piège de l’exhaustivité. Vouloir un SBOM pour chaque logiciel dès le premier jour, c’est se noyer. La démarche fonctionne par cercles concentriques : commencer par les 10 à 20 applications les plus critiques, puis élargir.
Le piège du bruit. Un SBOM corrélé sans VEX génère des centaines de vulnérabilités théoriques. Sans priorisation, l’équipe sécurité se retrouve submergée par de faux positifs. Le VEX et le contexte métier sont indispensables pour trier le signal du bruit.
Le piège de l’illusion de contrôle. Avoir un SBOM ne signifie pas maîtriser sa supply chain. Le SBOM ne couvre que les composants déclarés. Les dépendances transitives, les composants embarqués dans le firmware, les micro-services tiers non documentés restent des angles morts. La transparence est un chemin, pas une destination.
La résilience ne consiste pas à tout voir. Elle consiste à savoir ce qu’on ne voit pas, et à agir en conséquence.
L’Essentiel pour Agir
1. Sortez vos SBOM du tiroir : récupérez les SBOM déjà en votre possession, chargez-les dans un outil de corrélation (Dependency-Track ou équivalent) et lancez une première analyse sur vos 10 actifs les plus critiques. C’est en général ce premier choc de visibilité qui déclenche la prise de conscience et le soutien de la direction.
2. Inscrivez le SBOM dans votre gouvernance fournisseur : ajoutez à vos contrats et appels d’offres l’obligation de fournir un SBOM au format machine-readable (CycloneDX ou SPDX), avec mise à jour à chaque release. Posez aussi la question du VEX. Un fournisseur qui ne peut pas répondre sur l’exploitabilité de ses vulnérabilités est un fournisseur qu’il faut surveiller de plus près.
3. Désignez un propriétaire et mesurez : le SBOM n’est pas un livrable de plus pour l’équipe sécurité. C’est un flux qui nécessite un processus, un responsable identifié et des indicateurs de suivi (taux de couverture SBOM sur les actifs critiques, délai moyen de corrélation CVE, taux de réponse VEX des fournisseurs). Ce qui ne se mesure pas ne se pilote pas.
Conclusion
Le SBOM est l’un de ces sujets où le fossé entre l’intention et la pratique est le plus large. Tout le monde sait qu’il faut connaître ses composants. Presque personne ne les surveille en continu.
Le passage du SBOM contractuel au SBOM vivant n’est pas un projet technologique massif. C’est une décision de gestion : choisir de transformer un document passif en capteur actif. Les outils existent. Les formats sont stabilisés. La réglementation pousse. Il manque souvent un élément plus simple : la volonté d’y consacrer le temps nécessaire.
Ce sujet de la supply chain logicielle n’est qu’une facette d’un enjeu plus large : celui de la dépendance numérique sous toutes ses formes. La prochaine chronique poursuivra cette exploration, en s’intéressant à un autre territoire où la dépendance se cache en pleine lumière.
Le SBOM dans un tiroir est une bonne conscience. Le SBOM dans un pipeline est un radar. Vous avez le choix.
Bibliographie
CISA — Software Bill of Materials (SBOM)
Page centrale de la CISA regroupant toutes les ressources SBOM : guides, rapports du cycle de vie de partage, spécifications VEX, FAQ, et documents de cadrage. Le point d’entrée de référence pour tout projet SBOM.
CISA — 2025 Minimum Elements for a Software Bill of Materials (SBOM)
https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom
Mise à jour 2025 des éléments minimaux d’un SBOM, successeur du cadre NTIA 2021. Définit les champs de données, pratiques et processus attendus pour la production et l’exploitation des SBOM.
Commission européenne — Cyber Resilience Act (CRA)
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Page officielle du CRA, règlement européen imposant des exigences de cybersécurité pour les produits numériques, incluant l’obligation de production de SBOM par les fabricants. Entré en vigueur décembre 2024, pleine application d’ici décembre 2027.
NTIA — The Minimum Elements For a Software Bill of Materials (SBOM) — 2021
https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
Le document fondateur qui a défini les éléments minimaux d’un SBOM suite à l’Executive Order 14028. Base essentielle pour comprendre l’évolution des exigences entre 2021 et 2025.
CISA / NSA / partenaires internationaux — A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity (2025)
Guide international conjoint définissant la vision partagée du SBOM pour la cybersécurité. Couvre les cas d’usage (gestion des vulnérabilités, inventaire, licences), l’automatisation et le rôle du VEX comme complément essentiel du SBOM.