Le SBOM

Le SBOM (software bill of materials, nomenclature logicielle) est l’inventaire structuré, formel et lisible par machine des composants logiciels contenus dans un produit et de leurs relations.

Cette section en est la référence technique. Elle est écrite pour être lue par les deux équipes : les pages Définition, Ce que le CRA exige, VEX et La licence comme donnée du SBOM sont accessibles sans culture technique, les autres supposent de connaître une chaîne de construction.

Pourquoi le sujet est devenu réglementaire

Le CRA n’a pas inventé le SBOM ; il a rendu obligatoire une pratique déjà répandue, en l’inscrivant dans les exigences essentielles :

Annexe I, partie II, point 1 — recenser et documenter les vulnérabilités et les composants contenus dans le produit, notamment en établissant une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau.

Trois expressions y sont décisives, et chacune a une conséquence opérationnelle :

  • « format couramment utilisé » — en pratique CycloneDX ou SPDX. Un tableur n’en est pas un.
  • « lisible par machine » — JSON, XML, tag-value. Un PDF n’est pas lisible par machine.
  • « au minimum les dépendances de premier niveau » — c’est un plancher légal, pas une cible. Les attaques de chaîne d’approvisionnement passent majoritairement par les dépendances transitives.

La chaîne de valeur, en une ligne

SBOM → dossier technique (annexe VII) → déclaration UE de conformité (annexe V) → marquage CE → droit de commercialiser dans l’Union.

C’est la phrase à retenir côté Juridique : le SBOM n’est pas un livrable technique annexe, c’est une pièce constitutive du dossier permettant d’obtenir le marquage CE.

Ce que le SBOM n’est pas

  • Ce n’est pas un rapport de vulnérabilités. C’est la donnée qui permet d’en produire un.
  • Ce n’est pas un audit de licences. C’est la donnée qui permet d’en faire un.
  • Ce n’est pas une preuve d’absence de code malveillant. Un composant peut être correctement inventorié et compromis — voir Risques de chaîne d’approvisionnement.

Le test de réalité

Une seule question suffit à mesurer votre maturité : combien de temps vous a-t-il fallu, la dernière fois, pour répondre à « êtes-vous affectés par cette vulnérabilité ? » Sans SBOM centralisé, la réponse se compte en semaines et repose sur des courriels. Avec, elle se compte en minutes et repose sur une requête.

Dans cette section

  • Transverse

    Qu'est-ce qu'un SBOM

    Définition accessible aux deux équipes, données minimales attendues par composant, usages par public, et ce que le SBOM n'est pas.

  • Transverse

    Ce que le CRA exige du SBOM

    Le texte exact, le décryptage de ses trois expressions clés, la question de la publication, l'habilitation de la Commission, et la chaîne qui mène au marquage CE.

  • Cyber

    Les formats

    CycloneDX et SPDX : origines, normalisation, points forts respectifs, comparatif, et le choix d'un format pivot avec export vers l'autre.

  • Cyber

    Les six types de SBOM

    Design, source, build, analyzed, deployed, runtime : ils ne décrivent pas la même chose et ne se valent pas. Lequel verser au dossier technique.

  • Cyber

    Qualité, complétude et profondeur

    Critères de qualité d'un SBOM, notation automatisée, seuils bloquants en CI, profondeur des dépendances transitives, et les sept pièges qui produisent des inventaires faux.

  • Cyber

    Les identifiants de composants

    PURL, CPE, SWID, empreintes : pourquoi l'appariement entre un composant et une vulnérabilité est la cause numéro un des faux positifs, et comment le fiabiliser.

  • Transverse

    VEX : l'exploitabilité

    Le mécanisme qui distingue « traité » d'« ignoré » : statuts, justifications normalisées, implémentations CycloneDX, OpenVEX et CSAF, et valeur juridique de la décision de ne pas corriger.

  • Legal

    La licence comme donnée du SBOM

    Identifiants et expressions SPDX, ce que le SBOM permet de calculer en matière de conformité juridique, et la qualité de donnée sans laquelle rien n'est exploitable.

  • Cyber

    Signature et intégrité

    Pourquoi un SBOM non signé n'est pas une preuve : signature, attestations de provenance, niveaux SLSA, builds reproductibles et journal de transparence.

  • Legal

    Diffusion et confidentialité

    Faut-il publier son SBOM ? Niveaux de diffusion, clauses contractuelles, régime de confidentialité des informations transmises aux autorités, et la matrice décisionnelle.

  • Cyber

    Le cycle de vie du SBOM

    Un SBOM par construction, immuable et versionné ; conservation alignée sur le dossier technique ; archivage, indexation, restitution et comparaison entre versions.