Une faille critique tombe un vendredi soir. Dans l’entreprise, la question n’est pas encore de savoir comment la corriger, mais où se trouve le composant concerné : dans une application métier, une image de conteneur, un outil acheté à un prestataire ? C’est précisément ce brouillard que promet de dissiper le SBOM, la nomenclature des composants logiciels. À l’horizon de septembre 2026, son enjeu dépasse le fichier à fournir aux achats : il s’agit de transformer une liste technique en capacité de réaction.
Le logiciel moderne est un assemblage
Un service numérique contient rarement uniquement le code de son éditeur. Il assemble des bibliothèques open source, des frameworks, des composants système et parfois des modules propriétaires. Chacun peut lui-même embarquer d’autres dépendances. Ces couches accélèrent le développement, mais compliquent la réponse à une question élémentaire : qu’utilisons-nous réellement ?
La crise Log4Shell, fin 2021, a montré le coût de cette opacité. La bibliothèque Java Log4j était présente dans de nombreux produits, parfois plusieurs niveaux sous l’application visible. Identifier les systèmes concernés exigeait de croiser analyses techniques, réponses des fournisseurs et vérifications manuelles. L’absence d’inventaire exploitable faisait perdre un temps précieux avant même le début des corrections.
Le Software Bill of Materials transpose au logiciel la logique d’une nomenclature industrielle. Il décrit des composants, leurs versions et leurs relations ; selon son contenu, il peut aussi renseigner leurs fournisseurs, licences, identifiants ou empreintes cryptographiques. L’ambition est simple : pouvoir interroger cet assemblage plutôt que le reconstituer dans l’urgence.
Une liste, pas un certificat de sécurité
Deux familles de formats structurent notamment cet échange : SPDX, normalisé à l’ISO, et CycloneDX, issu de l’écosystème OWASP. Elles permettent de produire des documents lisibles par des outils. Mais choisir un format reconnu ne garantit ni l’exhaustivité de l’inventaire ni la justesse de ses informations.
Un SBOM généré depuis les fichiers de dépendances du projet ne montre pas nécessairement tout ce qui sera livré. Des bibliothèques peuvent être intégrées directement au code, des paquets système ajoutés à une image, des composants téléchargés pendant la construction. À l’inverse, une dépendance utilisée pour les tests peut apparaître dans un inventaire sans jamais atteindre la production.
Il faut donc connaître le périmètre observé : code source, environnement de construction, binaire distribué ou système déployé. Le SBOM est une déclaration sur un objet précis, à un moment précis. Sans cette information, un document volumineux peut donner une illusion de maîtrise tout en décrivant le mauvais objet.
Le vrai défi : suivre chaque livraison
Le piège classique consiste à produire une nomenclature pour un audit, puis à l’archiver. Entre-temps, les équipes mettent à jour une bibliothèque, changent l’image de base ou reconstruisent un produit. Le fichier reste présent dans le dossier de conformité ; son lien avec le logiciel effectivement utilisé, lui, disparaît.
La bonne unité n’est donc pas seulement le nom commercial d’une application. C’est sa version livrée, idéalement reliée à un artefact identifiable par une empreinte. Deux constructions portant une même étiquette peuvent différer si leurs dépendances ne sont pas verrouillées. La nomenclature doit rester attachée au résultat concret, pas uniquement à la promesse d’une version.
En pratique, la génération gagne à être intégrée aux chaînes d’intégration et de livraison continues. Chaque livraison produit son inventaire, conservé avec les artefacts et relié aux déploiements. Pour les logiciels achetés, cette continuité devient une exigence fournisseur : à quelle fréquence le document est-il renouvelé, comment est-il accessible et quelles versions couvre-t-il ?
Relier l’inventaire à la vulnérabilité réelle
L’utilité opérationnelle apparaît lorsqu’une nouvelle alerte peut être rapprochée des composants recensés. Un inventaire inchangé doit pouvoir être réévalué : une bibliothèque jugée sans problème connu hier peut faire l’objet d’un avis de sécurité demain. Actualiser la connaissance du risque ne signifie pas nécessairement régénérer le SBOM.
Ce rapprochement exige toutefois des identités fiables. Noms ambigus, versions mal renseignées ou paquets renommés produisent des oublis et de fausses alertes. Des identifiants comme les Package URLs facilitent le travail, sans abolir les difficultés : un fournisseur peut avoir rétroporté un correctif sans adopter le numéro de version attendu par un scanner.
La présence d’un composant vulnérable ne prouve pas non plus que la faille soit exploitable dans chaque produit. La fonction touchée peut être absente, désactivée ou inaccessible. Les documents VEX, pour Vulnerability Exploitability eXchange, permettent de communiquer un statut d’impact accompagné d’éléments de justification. Ils complètent la nomenclature ; ils ne remplacent ni l’analyse ni la confiance à accorder à leur émetteur.
Pour trier les urgences, les équipes doivent alors croiser sévérité, exploitation connue, exposition du service et criticité métier. Un score élevé ne suffit pas à ordonner les corrections. À l’inverse, un composant discret sur un service exposé peut demander une intervention immédiate. Le SBOM fournit des indices ; la gestion des vulnérabilités les transforme en décisions.
La réglementation pousse, sans résoudre l’exécution
Le mouvement ne vient pas uniquement des équipes de sécurité. Aux États-Unis, le décret présidentiel de mai 2021 sur la cybersécurité a contribué à installer les SBOM dans les discussions sur la chaîne d’approvisionnement logicielle. Les acheteurs ont ainsi une base pour demander davantage de visibilité à leurs fournisseurs.
En Europe, le Cyber Resilience Act, entré en vigueur en décembre 2024, renforce cette trajectoire. Le calendrier adopté prévoit l’application de certaines obligations de signalement à partir du 11 septembre 2026, puis l’essentiel des obligations en décembre 2027. Il prévoit notamment une nomenclature lisible par machine dans le cadre de la gestion des vulnérabilités, couvrant au moins les dépendances de premier niveau. Cela ne signifie pas que toutes les nomenclatures devront être publiées librement.
Pour les entreprises, la conséquence stratégique est claire : demander un fichier sans organiser son exploitation risque de créer une conformité de façade. Les contrats doivent préciser le périmètre, l’actualisation et le traitement des anomalies. La documentation réglementaire ne dispense jamais de savoir qui corrige quoi.
Mesurer la capacité à agir
Un programme utile commence par quelques applications critiques et des exercices concrets. Peut-on retrouver les versions affectées par une alerte ? Identifier leur propriétaire ? Distinguer les instances retirées de celles encore exposées ? La couverture des livraisons, le délai d’identification et la capacité à vérifier une correction sont plus parlants que le nombre de fichiers collectés.
Et maintenant ? La perspective pour septembre 2026 est celle d’un passage progressif du document exigé à la donnée exploitée. Cette évolution restera inégale : générer une liste est plus simple que maintenir le lien entre composants, produits et déploiements. Les organisations qui réussiront ne seront pas celles possédant le plus de SBOM, mais celles capables de répondre rapidement à trois questions : sommes-nous concernés, où, et quelle action entreprendre ?
