Le SBOM (Software Bill of Materials) est l’une des obligations les plus structurantes du Cyber Resilience Act. Derriere cet acronyme se cache un concept simple : dresser l’inventaire complet de tous les composants logiciels integres dans un produit numerique. En pratique, cette obligation va transformer la maniere dont les entreprises concoivent, documentent et maintiennent leurs logiciels. Voici ce qu’il faut savoir pour s’y preparer.

Qu’est-ce qu’un SBOM ?

Un SBOM est une nomenclature formalisee qui recense l’ensemble des composants logiciels constituant un produit : bibliotheques tierces, frameworks, modules open source, dependances directes et transitives. On peut le comparer a la liste d’ingredients d’un produit alimentaire, mais appliquee au logiciel.

Concretement, un SBOM repond a une question fondamentale : de quoi est fait ce logiciel ? Pour chaque composant, il identifie sa provenance, sa version exacte, sa licence et ses relations de dependance avec les autres composants.

Cette transparence n’est pas un luxe. Lorsque la vulnerabilite Log4Shell a ete decouverte fin 2021, des milliers d’organisations ont mis des semaines a determiner si elles etaient affectees, faute de savoir precisement quels composants etaient embarques dans leurs produits. Un SBOM aurait permis de repondre a cette question en quelques minutes.

Pourquoi le CRA impose-t-il un SBOM ?

Le Cyber Resilience Act part d’un constat : la majorite des produits numeriques reposent sur des composants tiers – souvent open source – dont la securite n’est ni suivie ni documentee par le fabricant. L’article 13 du CRA et son annexe I imposent aux fabricants de produits comportant des elements numeriques de realiser une analyse de risque en matiere de cybersecurite, ce qui suppose necessairement de connaitre la composition logicielle du produit.

Plus specifiquement, l’annexe I, partie II, exige que la documentation technique accompagnant le produit inclue un SBOM couvrant au minimum les dependances de premier niveau (top-level dependencies). Cette exigence s’applique a tous les acteurs concernes par le CRA, qu’il s’agisse de fabricants, d’importateurs ou de distributeurs de produits numeriques.

Les objectifs poursuivis sont multiples :

• Gestion des vulnerabilites : identifier rapidement si un composant affecte par une faille est present dans un produit, facilitant ainsi la procedure en cas de fuite de donnees lorsque des donnees personnelles sont en jeu.
• Tracabilite de la chaine d’approvisionnement : savoir d’ou vient chaque brique logicielle et qui en est responsable, une exigence qui rejoint les obligations de la directive NIS2 en matiere de securite de la chaine d’approvisionnement.
• Conformite des licences : verifier que les conditions d’utilisation des composants open source sont respectees.
• Reaction aux incidents : accelerer le diagnostic et la correction en cas de decouverte d’une vulnerabilite.

Que doit contenir un SBOM conforme au CRA ?

Le CRA ne prescrit pas un format unique, mais le contenu minimal attendu peut etre deduit des exigences de l’annexe I et des standards internationaux de reference. Un SBOM conforme doit documenter, pour chaque composant :

Informations obligatoires

• Nom du composant : identifiant unique et non ambigu.
• Version : numero de version exact deploye dans le produit.
• Fournisseur ou auteur : l’origine du composant (editeur, projet open source, developpement interne).
• Relations de dependance : quels composants dependent de quels autres (arbre de dependances).
• Licence applicable : le type de licence sous laquelle le composant est distribue (MIT, Apache 2.0, GPL, etc.).
• Identifiant unique : de preference un identifiant standardise tel que le CPE (Common Platform Enumeration) ou le Package URL (purl).

Informations recommandees

• Hash du composant : empreinte cryptographique (SHA-256) permettant de verifier l’integrite du binaire.
• Vulnerabilites connues : references CVE associees au composant dans la version utilisee.
• Date de derniere mise a jour : pour evaluer l’obsolescence du composant.

Exemple concret d’une entree SBOM

Pour illustrer concretement a quoi ressemble un SBOM, voici un extrait au format CycloneDX (JSON) pour un composant unique :

{
  "type": "library",
  "name": "express",
  "version": "4.18.2",
  "purl": "pkg:npm/express@4.18.2",
  "supplier": {
    "name": "OpenJS Foundation"
  },
  "licenses": [
    {
      "license": {
        "id": "MIT"
      }
    }
  ],
  "hashes": [
    {
      "alg": "SHA-256",
      "content": "a1b2c3d4e5f6..."
    }
  ],
  "externalReferences": [
    {
      "type": "website",
      "url": "https://expressjs.com"
    }
  ]
}

Dans un SBOM complet, cette structure est repetee pour chaque composant du produit, y compris les dependances transitives (les dependances des dependances). Pour une application web moderne, il n’est pas rare de compter plusieurs centaines, voire plusieurs milliers d’entrees.

Les deux formats de reference : CycloneDX et SPDX

Deux standards dominent le marche du SBOM et sont reconnus par les autorites et les organismes de normalisation.

CycloneDX

Developpe par l’OWASP, CycloneDX est un format concu specifiquement pour la securite applicative. Il se distingue par :

• Une structure native orientee securite (support des vulnerabilites, des analyses de composition).
• Un support natif du JSON et du XML.
• Une adoption croissante dans l’ecosysteme DevSecOps.
• Une specification legere et pragmatique, facile a integrer dans les pipelines CI/CD.

CycloneDX est aujourd’hui le format le plus utilise dans les projets axes securite.

SPDX

Le format SPDX (Software Package Data Exchange) est un standard de la Linux Foundation, devenu norme ISO/IEC 5962:2021. Ses caracteristiques :

• Forte orientation vers la gestion des licences et la conformite juridique.
• Reconnu comme norme internationale ISO.
• Support du RDF, JSON, YAML, XML et du format tag-value.
• Historiquement privilegie pour les audits de licences open source.

Quel format choisir ?

Pour une conformite CRA, les deux formats sont acceptables. Le choix depend du contexte :

• Si votre priorite est la gestion des vulnerabilites et la securite, CycloneDX est le choix le plus naturel.
• Si votre priorite est la conformite juridique et la gestion des licences, SPDX offre une couverture plus mature.
• Dans le doute, CycloneDX est souvent recommande pour sa simplicite d’integration dans les chaines DevSecOps modernes.

Comment generer un SBOM : les outils disponibles

La generation d’un SBOM peut etre automatisee a l’aide d’outils dedies. Voici les trois solutions les plus robustes du marche.

Syft (Anchore)

Syft est un outil open source developpe par Anchore, specialise dans la generation de SBOM.

• Supporte CycloneDX et SPDX.
• Analyse les images de conteneurs, les systemes de fichiers et les repertoires de code source.
• S’integre facilement dans les pipelines CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Commande type : syft packages dir:./mon-projet -o cyclonedx-json > sbom.json

Trivy (Aqua Security)

Trivy est un scanner de securite polyvalent qui inclut la generation de SBOM parmi ses fonctionnalites.

• Combine analyse de vulnerabilites et generation de SBOM en un seul outil.
• Supporte les conteneurs, les depots Git, les systemes de fichiers.
• Formats de sortie : CycloneDX, SPDX, table, JSON.
• Commande type : trivy fs --format cyclonedx --output sbom.json ./mon-projet

OWASP Dependency-Track

Dependency-Track est une plateforme de gestion continue des SBOM, developpee par l’OWASP.

• Ne genere pas le SBOM lui-meme, mais le consomme, analyse et suit dans le temps.
• Correle automatiquement les composants avec les bases de vulnerabilites (NVD, OSV, GitHub Advisories).
• Fournit un tableau de bord avec scoring de risque par projet.
• Ideal pour le suivi continu de conformite CRA.

L’approche la plus complete consiste a combiner un generateur (Syft ou Trivy) avec une plateforme de suivi (Dependency-Track) pour couvrir l’ensemble du cycle de vie.

Mise en oeuvre pratique : les etapes cles

La mise en conformite SBOM dans le cadre du CRA peut etre decomposee en cinq etapes.

1. Inventorier les produits concernes

Identifiez tous les produits numeriques que vous fabriquez, importez ou distribuez et qui entrent dans le champ du CRA. Chaque produit devra disposer de son propre SBOM.

2. Integrer la generation de SBOM dans le pipeline CI/CD

La generation du SBOM doit etre automatisee et declenchee a chaque build ou release. Un SBOM genere manuellement sera inevitablement incomplet ou obsolete. Integrez Syft ou Trivy comme etape de votre pipeline de deploiement.

3. Valider le contenu du SBOM

Verifiez que le SBOM genere contient bien toutes les informations requises : noms, versions, licences, dependances. Des outils comme sbom-scorecard ou les validateurs integres de CycloneDX permettent de controler la qualite du SBOM produit.

4. Mettre en place un suivi continu des vulnerabilites

Le SBOM n’est pas un document statique. Il doit etre correle en permanence avec les bases de vulnerabilites connues. Deployez Dependency-Track ou un outil equivalent pour recevoir des alertes lorsqu’une nouvelle CVE affecte l’un de vos composants.

5. Documenter et archiver

Le CRA exige que la documentation technique soit conservee pendant dix ans apres la mise sur le marche du produit ou pendant la duree de vie du support, selon la plus longue des deux periodes. Archivez chaque version du SBOM en lien avec la version du produit correspondante.

SBOM et gestion des vulnerabilites : le lien essentiel

Le SBOM n’est pas une fin en soi. Sa valeur reelle reside dans sa capacite a alimenter un processus continu de gestion des vulnerabilites, ce que le CRA exige par ailleurs dans son annexe I.

Le mecanisme est le suivant :

1. Le SBOM identifie tous les composants presents dans le produit.
2. Ces composants sont correles avec les bases de donnees de vulnerabilites (NVD, EPSS, bases editeurs).
3. Lorsqu’une nouvelle vulnerabilite est publiee, le systeme determine immediatement quels produits sont affectes.
4. L’equipe securite peut alors prioriser les correctifs en fonction du risque reel.

Sans SBOM, cette chaine est rompue. L’entreprise decouvre les vulnerabilites au hasard, reagit tardivement et ne peut pas demontrer aux autorites de surveillance qu’elle respecte ses obligations de diligence.

Points de vigilance

Plusieurs ecueils sont a anticiper dans la mise en oeuvre :

• Les dependances transitives : un SBOM qui ne liste que les dependances directes est insuffisant. Les vulnerabilites se nichent souvent dans les sous-dependances (dependencies of dependencies).
• Les composants natifs et les binaires : les outils de generation de SBOM ont des limites avec le code compile (C, C++, Rust). Des analyses complementaires peuvent etre necessaires.
• La frequence de mise a jour : un SBOM perime est un faux sentiment de securite. La generation doit etre liee au cycle de release du produit.
• La confidentialite : le CRA impose de fournir le SBOM aux autorites de surveillance du marche sur demande, mais il n’exige pas sa publication integrale. Evaluez ce que vous rendez public et ce que vous conservez en interne.

Conclusion

L’obligation de SBOM imposee par le Cyber Resilience Act n’est pas une formalite administrative supplementaire. C’est un changement de paradigme dans la maniere dont les fabricants de produits numeriques documentent et suivent la composition de leurs logiciels.

Les entreprises qui integrent des aujourd’hui la generation automatisee de SBOM dans leurs pipelines CI/CD prendront une avance significative. Les outils existent, les formats sont matures, et la courbe d’apprentissage est raisonnable pour des equipes DevSecOps deja structurees.

La vraie difficulte ne sera pas technique. Elle sera organisationnelle : faire du SBOM un reflexe systematique, le maintenir a jour, et l’integrer dans une demarche globale de gestion des vulnerabilites conforme aux exigences du CRA.