Chaîne d’approvisionnement logicielle
SBOM : ce qu’est une nomenclature des logiciels et comment la produire
Un SBOM (software bill of materials, ou nomenclature des logiciels) est un inventaire formel et lisible par machine des composants d’un logiciel et de leurs relations. Le Cyber Resilience Act impose aux fabricants d’en établir un, couvrant au moins les dépendances de niveau supérieur, dans un format couramment utilisé comme CycloneDX ou SPDX.
Offre Free, sans carte bancaire.
Qu’est-ce qu’un SBOM ?
Voyez-le comme la liste des ingrédients d’un produit. Pour chaque composant, il consigne un nom, une version et, idéalement, un identifiant unique comme une package URL (purl), ainsi que le fournisseur et les relations entre composants : quelle bibliothèque en entraîne quelle autre. Le CRA le définit comme « un document officiel contenant les détails et les relations avec la chaîne d’approvisionnement des différents composants utilisés dans la fabrication d’un produit comportant des éléments numériques ».
Un SBOM n’indique pas si un composant est vulnérable. C’est l’inventaire qui permet de répondre à cette question, aujourd’hui et chaque fois qu’une nouvelle vulnérabilité est publiée.
Le SBOM est-il obligatoire ?
Pour les fabricants de produits qui relèvent du Cyber Resilience Act, oui. L’annexe I, partie II, leur impose de recenser et de documenter les vulnérabilités et les composants, notamment par l’établissement d’une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur. Le SBOM fait partie de la documentation technique et doit être fourni à une autorité de surveillance du marché qui en fait la demande motivée ; le règlement n’impose pas de le publier.
La Commission peut préciser le format et les éléments par voie d’acte d’exécution. D’ici là, CycloneDX et SPDX sont les formats que la plupart des outils produisent et acceptent.
CycloneDX ou SPDX
Les deux sont des standards ouverts et largement pris en charge. Le choix dépend généralement des outils qu’utilisent déjà vos clients et vos fournisseurs ; beaucoup d’équipes conservent les deux.
| CycloneDX | SPDX | |
|---|---|---|
| Maintenu par | OWASP et Ecma International (ECMA-424) | La Linux Foundation ; publié sous la référence ISO/IEC 5962:2021 |
| Origines | Sécurité applicative et risques de la chaîne d’approvisionnement | Conformité des licences |
| Sérialisations | JSON, XML, Protocol Buffers | JSON, tag-value, RDF, YAML et autres |
| Données de vulnérabilités | Prise en charge native de VEX | Des documents VEX séparés sont courants |
Comment générer un SBOM
Le SBOM le plus fidèle est produit à partir de ce que vous livrez réellement. Pour le code source, ce sont les fichiers de verrouillage (lockfiles) et les manifestes que votre build résout ; pour le firmware et les images de conteneurs, ce sont les fichiers contenus dans l’image, car les outils utilisés au moment du build peuvent passer à côté de paquets ajoutés plus tard dans la chaîne.
- Le générer dans le pipeline de build, pour chaque version publiée, et non à la main.
- Analyser l’artefact final autant que le code source : images firmware et images de conteneurs comprises.
- Consigner les versions exactes et les package URL, pas des plages de versions.
- Conserver le SBOM de chaque version encore prise en charge ; vous en aurez besoin quand une nouvelle vulnérabilité apparaîtra.
- Revérifier les SBOM stockés au regard des nouvelles données de vulnérabilités au lieu de reconstruire les anciennes versions.
Que faire d’un SBOM une fois qu’on l’a
Un SBOM prend toute sa valeur lorsqu’une nouvelle vulnérabilité est publiée. Avec un inventaire par version, la question « lesquels de nos produits livrent ce composant ? » se règle en quelques minutes au lieu de plusieurs jours. Cette rapidité compte au titre de l’article 14 du CRA, où une vulnérabilité activement exploitée déclenche un délai de notification de 24 heures.
Associez-le à des déclarations VEX (Vulnerability Exploitability eXchange) pour consigner quelles vulnérabilités répertoriées n’affectent pas le produit et pourquoi, afin que clients et autorités voient la décision autant que l’inventaire.
Disponible aujourd’hui dans KROMSE
KROMSE produit et lit des SBOM dès aujourd’hui.
- Chaque analyse d’un dépôt, d’une image de conteneur ou d’une image firmware basée sur Linux produit un SBOM CycloneDX JSON et un SBOM SPDX JSON à télécharger.
- Importez des SBOM CycloneDX (JSON 1.2 à 1.7, ou XML) ou SPDX 2.2 et 2.3 (JSON ou tag-value), ainsi que des manifestes de build Yocto et Buildroot ; chaque import est automatiquement confronté à OSV.dev.
- Envoyez des SBOM depuis votre CI avec un jeton d’API d’espace de travail ; des extraits de configuration existent pour GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, Bitbucket Pipelines, Yocto, Buildroot, Zephyr et ESP-IDF.
- Export VEX aux formats CycloneDX 1.6 VEX et OpenVEX, chaque déclaration VEX importée devant être acceptée par une personne.
- Avec les offres payantes, le dernier SBOM de chaque produit est revérifié auprès d’OSV toutes les six heures.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T1 2027Composants matériels. KROMSE comparera les composants matériels de votre produit aux avis de sécurité publiés pour le matériel.
- À venir · T1 2027Sécurité des agents et des modèles d’IA. KROMSE produira une nomenclature des composants d’IA (AI-BOM), examinera les outils et les permissions que vos agents peuvent utiliser, et détectera les fichiers de modèles non sûrs.
Questions fréquentes
Que signifie SBOM ?
Software bill of materials, soit nomenclature des logiciels : une liste formelle et lisible par machine des composants d’un logiciel, avec leurs versions, leurs fournisseurs et leurs relations. Elle fonctionne comme une liste d’ingrédients et constitue le point de départ pour savoir si un produit contient un composant vulnérable.
Le Cyber Resilience Act impose-t-il un SBOM ?
Oui. L’annexe I, partie II, impose aux fabricants de produits comportant des éléments numériques d’établir un SBOM dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur. Il fait partie de la documentation technique et est fourni aux autorités de surveillance du marché sur demande motivée.
Quel format de SBOM choisir ?
CycloneDX et SPDX sont tous deux couramment utilisés, lisibles par machine et largement pris en charge. Choisissez celui qu’attendent vos clients et vos outils, ou produisez les deux. La cohérence d’une version à l’autre compte davantage que le choix du format.
Dois-je publier mon SBOM ?
Le CRA n’impose pas aux fabricants de rendre le SBOM public. Il doit faire partie de la documentation technique et être fourni à une autorité de surveillance du marché qui le demande. Beaucoup d’entreprises partagent leurs SBOM avec leurs clients dans un cadre contractuel.
Peut-on créer un SBOM pour un firmware ?
Oui. Pour un firmware basé sur Linux, l’approche fiable consiste à extraire le contenu de l’image et à lister les paquets et les binaires qu’elle contient, plutôt que de s’appuyer uniquement sur les fichiers de build. KROMSE le fait aujourd’hui pour les images firmware basées sur Linux ; les images bare-metal et RTOS figurent sur la feuille de route.