SBOM : l'obligation de nomenclature logicielle imposée par le CRA

Le SBOM (Software Bill of Materials) est l’une des obligations les plus structurantes du Cyber Résilience Act. Derrière cet acronyme se caché un concept simple : dresser l’inventaire complet de tous les composants logiciels intégrés dans un produit numérique. En pratique, cette obligation va transformer la manière dont les entreprises concoivent, documentent et maintiennent leurs logiciels. Voici ce qu’il faut savoir pour s’y préparer.

Qu’est-ce qu’un SBOM ?

Un SBOM est une nomenclature formalisée qui recense l’ensemble des composants logiciels constituant un produit : bibliotheques tierces, frameworks, modules open source, dépendances directes et transitives. On peut le comparer à la listé d’ingredients d’un produit alimentaire, mais appliquée au logiciel.

Concrètement, un SBOM répond à 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 dépendance avec les autres composants.

Cette transparence n’est pas un luxe. Lorsque la vulnérabilité Log4Shell a été découverte fin 2021, des milliers d’organisations ont mis des semaines a déterminer si elles étaient affectées, faute de savoir précisément quels composants étaient embarques dans leurs produits. Un SBOM aurait permis de répondre à cette question en quelques minutes.

Pourquoi le CRA impose-t-il un SBOM ?

Le Cyber Résilience Act part d’un constat : la majorité des produits numériques reposent sur des composants tiers – souvent open source – dont la sécurité n’est ni suivie ni documentée par le fabricant. L’article 13 du CRA et son annexe I imposent aux fabricants de produits comportant des éléments numériques de réaliser une analyse de risque en matière de cybersécurité, ce qui suppose nécessairement de connaître la composition logicielle du produit.

Plus spécifiquement, l’annexe I, partie II, exigé que la documentation technique accompagnant le produit inclue un SBOM couvrant au minimum les dépendances de premier niveau (top-level dependencies). Cette exigence s’applique a tous les acteurs concernés par le CRA, qu’il s’agisse de fabricants, d’importateurs ou de distributeurs de produits numériques.

Les objectifs poursuivis sont multiples :

• Gestion des vulnérabilités : identifier rapidement si un composant affecte par une faille est présent dans un produit, facilitant ainsi la procédure en cas de fuite de données lorsque des données personnelles sont en jeu.
• Traçabilité de la chaîne d’approvisionnement : savoir d’où vient chaque brique logicielle et qui en est responsable, une exigence qui rejoint les obligations de la directive NIS2 en matière de sécurité de la chaîne d’approvisionnement.
• Conformité des licences : vérifier que les conditions d’utilisation des composants open source sont respectées.
• Reaction aux incidents : accélérer le diagnostic et la correction en cas de découverte d’une vulnérabilité.

Que doit contenir un SBOM conforme au CRA ?

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

Informations obligatoires

• Nom du composant : identifiant unique et non ambigu.
• Version : numéro de version exact déployé dans le produit.
• Fournisseur ou auteur : l’origine du composant (éditeur, projet open source, développement interne).
• Relations de dépendance : quels composants dépendent de quels autres (arbre de dépendances).
• 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 recommandées

• Hash du composant : empreinte cryptographique (SHA-256) permettant de vérifier l’intégrité du binaire.
• Vulnerabilites connues : références CVE associées au composant dans la version utilisée.
• Date de dernière mise à jour : pour évaluer l’obsolescence du composant.

Exemple concret d’une entrée SBOM

Pour illustrer concrètement 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 structuré est repetee pour chaque composant du produit, y compris les dépendances transitives (les dépendances des dépendances). Pour une application web moderne, il n’est pas rare de compter plusieurs centaines, voire plusieurs milliers d’entrees.

Les deux formats de référence : 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 sécurité applicative. Il se distingue par :

• Une structuré native orientee sécurité (support des vulnerabilites, des analyses de composition).
• Un support natif du JSON et du XML.
• Une adoption croissante dans l’écosystème 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 sécurité.

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 privilégié 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 sécurité, 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 à l’aide d’outils dedies. Voici les trois solutions les plus robustes du marche.

Syft (Anchore)

Syft est un outil open source développé 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 sécurité 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 génère 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 complète 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 étapes cles

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

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 à chaque build ou release. Un SBOM génère manuellement sera inevitablement incomplet ou obsolete. Integrez Syft ou Trivy comme étape de votre pipeline de déploiement.

3. Valider le contenu du SBOM

Verifiez que le SBOM génère contient bien toutes les informations requises : noms, versions, licences, dépendances. Des outils comme sbom-scorecard ou les validateurs intégrés de CycloneDX permettent de contrôler la qualité du SBOM produit.

4. Mettre en place un suivi continu des vulnérabilités

Le SBOM n’est pas un document statique. Il doit être correle en permanence avec les bases de vulnérabilités connues. Deployez Dependency-Track ou un outil équivalent pour recevoir des alertes lorsqu’une nouvelle CVE affecte l’un de vos composants.

5. Documenter et archiver

Le CRA exigé que la documentation technique soit conservée pendant dix ans après la mise sur le marché du produit ou pendant la durée de vie du support, selon la plus longue des deux périodes. Archivez chaque version du SBOM en lien avec la version du produit correspondante.

SBOM et gestion des vulnérabilités : le lien essentiel

Le SBOM n’est pas une fin en soi. Sa valeur réelle réside dans sa capacité a alimenter un processus continu de gestion des vulnérabilités, ce que le CRA exigé par ailleurs dans son annexe I.

Le mécanisme est le suivant :

1. Le SBOM identifie tous les composants présents dans le produit.
2. Ces composants sont correles avec les bases de données de vulnérabilités (NVD, EPSS, bases éditeurs).
3. Lorsqu’une nouvelle vulnérabilité est publiée, le système déterminé immédiatement quels produits sont affectés.
4. L’équipe sécurité peut alors prioriser les correctifs en fonction du risque réel.

Sans SBOM, cette chaîne est rompue. L’entreprise découvre les vulnérabilités au hasard, reagit tardivement et ne peut pas démontrer aux autorités de surveillance qu’elle respecte ses obligations de diligence.

Points de vigilance

Plusieurs écueils sont a anticiper dans la mise en oeuvre :

• Les dépendances transitives : un SBOM qui ne listé que les dépendances directes est insuffisant. Les vulnérabilités se nichent souvent dans les sous-dépendances (dependencies of dependencies).
• Les composants natifs et les binaires : les outils de génération de SBOM ont des limités avec le code compilé (C, C++, Rust). Des analysés complémentaires peuvent être nécessaires.
• La fréquence de mise à jour : un SBOM périmé est un faux sentiment de sécurité. La génération doit être liée au cycle de release du produit.
• La confidentialité : le CRA impose de fournir le SBOM aux autorités de surveillance du marché sur demande, mais il n’exigé pas sa publication intégrale. Évaluez ce que vous rendez public et ce que vous conservez en interne.

Conclusion

L’obligation de SBOM imposée par le Cyber Résilience Act n’est pas une formalité administrative supplémentaire. C’est un changement de paradigme dans la manière dont les fabricants de produits numériques documentent et suivent la composition de leurs logiciels.

Les entreprises qui intègrent des aujourd’hui la génération automatisée 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 équipes DevSecOps déjà structurées.

La vraie difficulté ne sera pas technique. Elle sera organisationnelle : faire du SBOM un réflexe systématique, le maintenir à jour, et l’intégrer dans une démarche globale de gestion des vulnérabilités conforme aux exigences du CRA.