SBOM : de la contrainte réglementaire au socle de la sécurité logicielle
Depuis décembre 2024, les règles du jeu ont changé en Europe. Avec l’entrée en vigueur du Cyber Resilience Act, les fabricants de produits numériques ont désormais jusqu’au 11 décembre 2027 pour fournir une Software Bill of Materials (SBOM) lisible par machine. Cette nomenclature logicielle, qui dresse un inventaire complet et traçable des composants utilisés, devient un passage obligé pour accéder au marché européen et répondre aux obligations de conformité.
« Savoir ce qu’il y a dans son propre logiciel »
Pour Allan Friedman, conseiller principal auprès de la CISA et figure historique du mouvement, la formule est simple : « SBOM est l’idée radicale selon laquelle on devrait réellement savoir ce qui se trouve dans son propre logiciel ». La SBOM ne se limite pas à une liste statique, elle décrit l’élaboration du logiciel, ses dépendances, ses versions et ses licences dans un format standard.
Pour Gonda Lamberink, Senior Global Director Cybersecurity chez Bureau Veritas, son rôle est devenu évident : « Les SBOM représentent une grande partie de la solution au problème de la sécurité de la chaîne d’approvisionnement… elles peuvent devenir un élément essentiel des pratiques de sécurité logicielle en facilitant la collaboration dans la chaîne et la responsabilisation ». Les crises SolarWinds ou Log4j ont prouvé combien le manque de transparence ralentissait les réactions et amplifie les attaques.
Des obligations fortes aux États-Unis
Aux États-Unis, les autorités n’ont pas attendu Bruxelles pour imposer des règles strictes. La FDA exige depuis plusieurs années que tout dépôt préalable à la mise sur le marché d’un dispositif médical inclue une SBOM complète, couvrant composants commerciaux, open source et logiciels prêts à l’emploi. La base légale repose sur le §524B du Federal Food, Drug, and Cosmetic Act, et la dernière mise à jour des lignes directrices, le 26 juin 2025, en fait une condition explicite pour les Cyber-Devices.
Le secteur public fédéral est également concerné. Avec les mémos OMB M-22-18 et M-23-16, la Maison-Blanche impose aux fournisseurs d’attester du respect du NIST SSDF via la procédure de Secure Software Development Attestation gérée par la CISA. Même si toutes les SBOM ne sont pas exigées systématiquement, l’obligation de transparence devient une attente claire et structurante pour les fournisseurs.
Une pratique qui se professionnalise
Pour Kelli Schwalm, Senior Product Manager chez RunSafe Security, l’évolution est radicale : « Les éléments minimaux de SBOM recommandés en 2025 montrent à quel point le secteur a progressé… d’une liste théorique à des exigences pratiques ». L’intégration de hachages cryptographiques, d’informations sur les auteurs ou du contexte de génération impose désormais une génération automatisée et fiable. Schwalm souligne qu’une SBOM produite au moment du build reste la plus fidèle et met en garde contre l’exclusion des logiciels embarqués, souvent parmi les systèmes les plus critiques.
CISA en chef d’orchestre technique
La CISA ne fixe pas seulement des obligations, elle décrit aussi les types de SBOM : source, build, analyse, installation et exécution. Cette classification facilite la mise en œuvre opérationnelle dans les processus de développement et d’exploitation. Elle fournit une boussole commune aux développeurs, intégrateurs, acheteurs et régulateurs.
« BOMs are not a new concept », rappelle Steve Springett, initiateur de CycloneDX et fondateur d’OWASP Dependency-Track. L’inventaire existe depuis longtemps, mais son intégration systématique dans les pipelines CI/CD change la donne en offrant transparence et traçabilité à grande échelle.
Un écart entre ambition et réalité
Les chiffres montrent un retard préoccupant. Selon l’étude Ponemon de 2025, 59 % des entreprises ont subi une attaque contre leur chaîne d’approvisionnement logicielle, la moitié au cours de la dernière année. Plus d’un quart de ces incidents étaient liés à des vulnérabilités open source non corrigées. Pourtant, seules 39 % disposent d’un inventaire complet de leurs dépendances, et une proportion importante ne valide pas les SBOM livrées ou ne les relie pas à une surveillance continue. Résultat : des retards de plusieurs semaines dans la détection et la réponse, avec des coûts accrus et un glissement de la prévention vers la gestion de crise.
L’IA générative, nouveau facteur de risque
L’arrivée massive de l’IA générative ajoute une complexité nouvelle. Les équipes intègrent du code suggéré sans traçabilité sur la provenance, les licences ou les dépendances transitives. Des « phantom packages » apparaissent dans les arbres de dépendances, rendant la surveillance encore plus difficile. Backslash Security s’est emparée du sujet en proposant une plateforme capable d’analyser l’atteignabilité, la vulnérabilité et la traçabilité du code généré par IA, avec une visibilité spécifique sur ces packages fantômes.
Formats, VEX et SBOM vivantes
Du côté des formats, deux standards dominent le marché : SPDX et CycloneDX. Tous deux couvrent les champs minimaux établis par la NTIA et peuvent être générés en continu grâce aux intégrations CI. Synopsys a choisi d’ancrer la SBOM dans son SDLC, en reliant export, import, validation et curation à une gestion des vulnérabilités en plusieurs étapes. Pour Tim Mackey, Principal Security Strategist de l’éditeur, « les applications logicielles modernes ont un problème de dépendances ». La complexité des architectures actuelles impose des nomenclatures exhaustives incluant sources, artefacts, hachages, dépendances et licences, afin de transformer la SBOM en artefact vivant et non en simple instantané.
La VEX, pour Vulnerability Exploitability eXchange, complète ce dispositif en apportant un éclairage sur l’exploitabilité réelle des vulnérabilités identifiées. La CISA a défini des statuts et exigences minimales pour ces documents, qui permettent aux consommateurs de décider avec discernement. En associant SBOM et VEX, les entreprises réduisent les faux positifs et allègent les chaînes de réponse, même lorsque les avis de sécurité se succèdent rapidement.
2025-2026 : l’opérationnalisation
La SBOM cesse d’être un rapport ponctuel pour devenir un artefact produit automatiquement au build, stocké dans des dépôts, signé si nécessaire et intégré par API dans les plateformes de gestion des risques. La classification de la CISA s’impose comme référence, notamment pour éviter les angles morts dans les environnements conteneurisés ou lors des chaînages dynamiques de services à l’exécution. Anchore pose la question de manière directe : « « Quand le prochain zero-day frappera votre infrastructure, passerez-vous cinq minutes à identifier les systèmes affectés ou cinq mois à fouiller dans des inventaires manuels ? » »
La réflexion ne s’arrête pas au code classique. La Linux Foundation propose d’étendre le concept avec un AI-BOM, destiné à documenter les algorithmes, datasets, frameworks et licences. Basé sur SPDX 3.0, ce nouvel artefact vise à renforcer la transparence dans un contexte où l’intelligence artificielle devient un composant central des chaînes de valeur numériques.
Un marché en mouvement
Le marché suit le mouvement avec une offre foisonnante. Dependency-Track s’impose pour l’analyse massive de SBOM et leur corrélation avec les nouveaux avis de sécurité. CycloneDX se distingue par sa proximité avec la pratique terrain, tandis que SPDX s’impose dans les contextes de conformité. Des outils comme LibTracker, intégrés directement à l’environnement de développement, rendent visibles en temps réel les versions, vulnérabilités et aspects de licence, comblant ainsi le fossé entre build, sécurité et juridique.
Pour Josh Bressers, VP Security chez Anchore et co-responsable de l’initiative OpenSSF-SIG « SBOM Everywhere », la valeur pratique ne fait plus débat : sans nomenclature fiable, aucune organisation ne peut accélérer lors d’un zero-day. Avec une SBOM structurée, la réaction gagne en précision et en rapidité. Josh Corman, Vice President of Cyber Safety Strategy chez Claroty, insiste sur la portée intersectorielle : « SBOMs sont un standard apprécié dans chaque secteur ; nous voulons appliquer des principes éprouvés de chaîne d’approvisionnement au développement logiciel – cela ne devrait pas être controversé. »
Gouvernance, contrats et audit
À l’avenir, les SBOM ne seront pas seulement des artefacts techniques, mais des outils de gouvernance intégrés aux contrats et aux audits. Synopsys recommande déjà de définir les exigences selon le contexte, d’identifier les groupes d’utilisateurs et de vérifier la situation juridique. Les clients, de leur côté, attendent des preuves de SDLC sécurisé, des rapports de vulnérabilités et acceptent les documents VEX comme base de décision. L’intégration de ces éléments dans les relations commerciales structure les processus et évite la logique du simple « case à cocher ». Kelli Schwalm recommande même de commencer par une SBOM exhaustive pour identifier et prioriser les vulnérabilités mémoire dans les environnements OT.
Des signaux clairs pour 2025 et 2026
Les chiffres du Ponemon envoient des signaux clairs. Moins de la moitié des entreprises automatisent la validation des dépendances open source et un tiers seulement évalue de manière structurée le code généré par IA. Beaucoup s’appuient encore sur des inventaires manuels incomplets. L’étude recommande l’importation et la validation continue de données SBOM issues de sources tierces, leur confrontation à des listes de paquets malveillants et la surveillance active des applications en production. Les conclusions confirment la corrélation directe entre transparence, rapidité de réaction et réduction du risque.
La SBOM s’impose comme un instrument à double visage : contrainte réglementaire en Europe et aux États-Unis, mais aussi outil opérationnel majeur. En combinant formats standardisés, assertions VEX, intégrations CI/CD et vues à l’exécution, elle comble des angles morts exploités depuis des années par les attaquants. Les échéances réglementaires fixent le minimum et poussent les entreprises à investir. Celles qui, dès 2025 et 2026, intégreront la génération et la validation de SBOM dans leurs pipelines transformeront cette contrainte en avantage compétitif : conformité fluide, gouvernance renforcée et réduction tangible des risques.