La gestion des SBOM pour la chaîne d'approvisionnement logicielle

Deux formats ouverts dominent la pratique. CycloneDX est issu de la communauté OWASP et est standardisé au niveau international via le comité Ecma TC54 : la version 1.6 a été publiée en juin 2024 sous la référence ECMA-424 (1re édition), et la version 1.7, parue en octobre 2025, a été publiée en décembre 2025 comme ECMA-424 (2e édition) – avec une modélisation étendue, notamment pour les artefacts cryptographiques et les modèles de ML. SPDX est développé sous l'égide de la Linux Foundation ; la norme ISO/IEC 5962:2021 encadre la version 2.2.1, tandis que la spécification actuelle 3.0.1 (décembre 2024) suit la procédure ISO en tant qu'ISO/IEC DIS 5962. SPDX trouve ses racines dans la conformité des licences, CycloneDX est davantage orienté vers les cas d'usage de sécurité – les deux satisfont l'exigence du CRA d'un « format couramment utilisé et lisible par machine ».

En 2021, la NTIA a défini pour la première fois les éléments minimaux d'une SBOM en trois catégories : champs de données (notamment fournisseur, nom du composant, version, identifiants uniques, relations de dépendance, auteur de la SBOM, horodatage), prise en charge de l'automatisation et processus d'accompagnement. En juillet 2026, la CISA, la NSA, le FBI et des agences partenaires internationales ont publié les « 2026 Minimum Elements for a SBOM », qui remplacent la version NTIA. Parmi les nouveautés figurent notamment les hachages de composants, les informations de licence, le nom de l'outil de génération et le contexte de génération ; les champs existants ont été précisés et nommés de manière plus cohérente. Ce contenu minimal constitue expressément un plancher – selon le cas d'usage, des informations supplémentaires sont recommandées.

Le moment le plus fiable pour générer une SBOM est le build : toutes les dépendances résolues, versions exactes comprises, y sont connues – ce que ni une simple analyse du code source ni une analyse binaire a posteriori ne peuvent reconstituer intégralement. En pratique, cette tâche est assurée par des plugins pour gestionnaires de paquets et systèmes de build ou par des générateurs comme cdxgen et Syft, intégrés comme étape fixe de la pipeline CI/CD. Chaque version publiée reçoit ainsi sa propre SBOM versionnée, archivée avec les artefacts de build et idéalement signée. Le contexte de génération exigé par les CISA Elements 2026 rend en outre transparent la phase du cycle de vie dans laquelle une SBOM a été créée.

Une SBOM ne révèle sa valeur que par une corrélation continue avec des données de vulnérabilités issues de sources comme la NVD, OSV ou les GitHub Advisories – permettant, dès la publication d'une nouvelle CVE, de déterminer immédiatement quels produits contiennent des composants concernés. Comme un composant vulnérable ne signifie pas automatiquement un produit vulnérable, VEX (Vulnerability Exploitability eXchange) complète la SBOM par des déclarations éditeur lisibles par machine sur l'exposition réelle ; la CISA a publié des exigences minimales à ce sujet en avril 2023. Le Common Security Advisory Framework (CSAF 2.0, standard OASIS depuis novembre 2022, doté d'un profil VEX dédié) et CycloneDX avec VEX intégré servent de formats d'échange. Bien utilisée, cette combinaison réduit considérablement les faux positifs et concentre la remédiation sur les vulnérabilités réellement exploitables.

Le Cyber Resilience Act (règlement (UE) 2024/2847, en vigueur depuis le 10 décembre 2024) rend la SBOM obligatoire : l'annexe I partie II impose aux fabricants de documenter les vulnérabilités et les composants, y compris une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau (top-level dependencies). La SBOM fait partie de la documentation technique et doit être présentée aux autorités de surveillance du marché sur demande ; il n'existe pas d'obligation de publication. Les obligations principales s'appliquent à partir du 11 décembre 2027, les obligations de notification dès le 11 septembre 2026. Le BSI précise ces exigences dans la directive technique TR-03183 partie 2 (version 2.1.0, août 2025) avec des prescriptions formelles et métier pour chaque champ de données – y compris des recommandations de correspondance vers SPDX et CycloneDX ainsi que, depuis la version 2.1.0, le traitement des composants virtuels et référencés.

Pour l'exploitation courante, le modèle d'une plateforme SBOM centrale s'est imposé, dont OWASP Dependency-Track est l'exemple open source le plus connu. La plateforme consomme et produit des SBOM et des documents VEX au format CycloneDX, inventorie les composants à travers tous les projets et toutes les versions, et les confronte en continu à des sources de vulnérabilités comme la NVD, OSV, les GitHub Advisories ou Snyk. Un moteur de politiques applique automatiquement les règles de sécurité, de licence et d'exploitation ; la conception API-first permet un raccordement direct aux pipelines CI/CD. Le point décisif est le changement de paradigme : au lieu de scans ponctuels, l'ensemble du portefeuille est automatiquement réévalué à chaque nouvelle publication de vulnérabilité.