SBOM (Software Bill of Materials)
La SBOM est l'inventaire formel de tous les composants d'un logiciel, dépendances comprises. Le Cyber Resilience Act en fait une exigence réglementaire.
La Software Bill of Materials, ou SBOM, est la nomenclature d'un logiciel : la liste formelle et machine-exploitable de tous les composants qui le constituent, bibliothèques open source, dépendances transitives, versions précises. Deux formats standards dominent, SPDX et CycloneDX, et les outils de SCA savent les générer automatiquement à partir du code ou des artefacts de build.
Son utilité éclate à chaque crise. Quand Log4Shell a été divulguée fin 2021, la question posée à toutes les DSI du monde était la même : "utilisons-nous Log4j, et où ?". Les organisations qui disposaient de SBOM ont répondu en quelques minutes par une requête ; les autres ont passé des semaines à fouiller leurs applications une par une. La SBOM transforme la réaction à une vulnérabilité de dépendance en simple recherche dans un inventaire.
Le régulateur l'a bien compris : le Cyber Resilience Act impose aux fabricants de produits numériques vendus dans l'Union européenne d'établir et de maintenir une SBOM. Ce qui relevait de la bonne pratique devient une obligation légale.
Ce que le CRA demande exactement
Le règlement européen 2024/2847 ne se contente pas de recommander la SBOM : il l'inscrit parmi les exigences essentielles que le fabricant doit satisfaire pour apposer le marquage CE. Elle doit couvrir au minimum les dépendances de premier niveau du produit, dans un format lisible par une machine, être tenue à jour pendant toute la période de support, et rester disponible pour l'autorité de surveillance du marché qui la demanderait. Le calendrier laisse peu de marge : obligations de notification applicables à partir de septembre 2026, exigences produit en décembre 2027. Notre article sur le Cyber Resilience Act déroule le chemin de mise en conformité.
Une SBOM générée n'est pas une SBOM utile
Produire le fichier est l'étape facile : les outils de SCA le font en une commande. Le reste demande de la discipline, et c'est là que la plupart des démarches s'arrêtent. Une SBOM sert si elle est générée au moment du build, à partir de l'artefact réellement livré et non du fichier de dépendances théorique. Si elle est archivée avec la version qu'elle décrit, faute de quoi personne ne saura plus à quoi elle correspond. Et si elle est interrogeable, parce que l'intérêt le jour d'une crise est de répondre en une requête à la question de savoir quels produits embarquent le composant fautif. Un fichier généré puis oublié dans un dossier partagé ne répond à rien.
Questions fréquentes
SPDX ou CycloneDX, lequel choisir ?
SPDX, normalisé à l'ISO, est plus répandu dans le monde des licences et de la conformité open source. CycloneDX, porté par l'OWASP, est orienté sécurité et décrit mieux les relations entre composants. Les outils convertissent de l'un vers l'autre, le choix n'est donc pas irréversible.
Faut-il publier sa SBOM ?
Rien ne l'impose au grand public. Le CRA exige qu'elle soit disponible pour l'autorité de surveillance du marché, et les clients grands comptes la demandent souvent par contrat. La diffuser largement revient à documenter votre surface pour un attaquant, ce qui se pèse au cas par cas.
Une SBOM prouve-t-elle qu'un produit est sûr ?
Non. Elle dit ce qu'il y a dedans, pas si c'est correctement configuré, à jour ou exploitable. C'est un inventaire, pas un audit, et le confondre avec une preuve de sécurité est une erreur fréquente dans les questionnaires fournisseurs.