SBOM CycloneDX : guide pratique pour la conformité CRA et NIS2

Le Software Bill of Materials (SBOM) est passé d'un artefact de recherche à une obligation réglementaire en moins de cinq ans. Le Cyber Resilience Act (CRA, UE 2024/2847) l'impose pour tous les produits à éléments numériques ; NIS2 en fait une attente implicite pour la sécurité de la chaîne d'approvisionnement ; DORA le cite comme preuve de diligence TIC. Ce guide détaille comment produire, consommer et exploiter un SBOM CycloneDX — le format qui s'est imposé en 2026.

Qu'est-ce qu'un SBOM ?

Un SBOM est une liste structurée de tous les composants logiciels qui constituent un produit : bibliothèques open-source, dépendances transitives, images de conteneurs, licences, suppliers. Pour un SaaS moyen, c'est 200 à 5 000 lignes de dépendances directes et transitives.

Deux formats dominants :

Le CRA n'impose pas explicitement un format mais les règles d'exécution de la Commission Européenne (en cours en 2026) convergent vers CycloneDX JSON pour la standardisation.

Pourquoi c'est obligatoire sous CRA

L'article 14.1 du Règlement (UE) 2024/2847 impose aux fabricants :

« ... identifier et documenter les vulnérabilités et les composants présents dans le produit, notamment en élaborant une nomenclature logicielle (SBOM) dans un format couramment utilisé et lisible par machine... »

Concrètement, cela signifie :

1. SBOM disponible pour chaque version commercialisée d'un PEN
2. Maintenu à jour à chaque nouvelle version ou patch
3. Machine-readable (JSON ou XML structuré)
4. Accessible aux autorités de surveillance du marché sur demande (15 jours ouvrés)

Les entités NIS2 (selon l'Art. 21.2.e sur la sécurité de l'acquisition) exigent de plus en plus le SBOM de leurs fournisseurs critiques en pièce jointe contractuelle.

Pour approfondir le périmètre, consultez notre guide CRA : 8 clauses contractuelles fournisseurs.

Structure d'un SBOM CycloneDX

Un fichier CycloneDX JSON minimaliste ressemble à ceci :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "metadata": {
    "timestamp": "2026-04-18T10:00:00Z",
    "component": {
      "type": "application",
      "name": "MonProduit",
      "version": "2.3.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

Les champs critiques pour la conformité CRA :

• purl (Package URL) — identifiant universel d'un composant, indispensable pour le cross-référencement CVE
• licenses — pour la conformité open-source et la traçabilité juridique
• hashes — intégrité cryptographique du composant (recommandé)
• supplier — l'entité qui a produit le composant, utile pour la cascade supply chain

Générer un SBOM automatiquement

Node.js / JavaScript

npm install --save-dev @cyclonedx/cyclonedx-npm
npx @cyclonedx/cyclonedx-npm --output-format JSON --output-file sbom.json

Python

pip install cyclonedx-bom
cyclonedx-py -e -o sbom.json

Containers Docker

syft packages docker:monimage:latest -o cyclonedx-json > sbom.json

Java / Maven

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <version>2.7.11</version>
</plugin>

Bonne pratique : générer le SBOM dans la pipeline CI/CD à chaque build release. Le stocker à côté des artefacts versionnés (Git tag + SBOM = reproductibilité).

Cross-référencer avec les bases CVE

Un SBOM brut n'a de valeur que si on le croise avec les vulnérabilités connues. Trois sources à consommer :

Pour chaque composant purl, interroger l'une de ces bases et récupérer la liste des CVE applicables avec leur score CVSS. Automatisable via les APIs publiques — exemple OSV :

curl -X POST https://api.osv.dev/v1/query \
  -d '{"package":{"purl":"pkg:npm/lodash@4.17.21"}}'

Dans ResiPlan, le module SBOM effectue ce cross-référencement automatiquement et déclenche des alertes dans le Dashboard CRA quand un nouveau CVE critique affecte un composant de vos produits enregistrés.

Recevoir les SBOM de vos fournisseurs

Si vous êtes intégrateur (vous embarquez des produits tiers dans votre propre SaaS), vous devez exiger un SBOM de chaque fournisseur critique. Clause contractuelle type :

« Le Fournisseur fournit un SBOM au format CycloneDX ou SPDX, mis à jour à chaque version livrée, couvrant l'ensemble des composants logiciels y compris open-source et dépendances transitives. »

Voir notre guide complet des 8 clauses CRA à intégrer pour la rédaction.

Avantages opérationnels concrets :

• Visibilité sur la chaîne d'approvisionnement (qui utilise quoi)
• Réponse rapide aux zero-day affectant un composant commun (type Log4Shell 2021)
• Négociation du support sécurité avec données objectives
• Audit ready pour les autorités NIS2 / CRA

Distribuer votre SBOM aux clients

Trois modalités selon le niveau de confidentialité :

1. SBOM public (recommandé pour open-source et SaaS commerciaux)

Publier le SBOM dans un repo Git public à chaque release :

https://github.com/monorg/monproduit/releases/download/v2.3.1/sbom.cdx.json

2. SBOM sous accord (produits confidentiels)

Héberger sur un portail sécurisé authentifié (Vault, Artifactory). Distribution contrôlée sous NDA.

3. SBOM à la demande (produits critiques ou classifiés)

Fournir sous 15 jours ouvrés à chaque demande légitime (client, autorité). Traçabilité de chaque distribution.

Le CRA ne prescrit pas de modalité mais exige la disponibilité de l'information. ResiPlan vous permet de tracer les distributions et les demandes entrantes.

Pièges fréquents à éviter

1. SBOM "de surface" sans dépendances transitives

Un SBOM qui ne liste que les dépendances directes manque 90 % du contenu réel. Assurez-vous que votre générateur descend sur tout l'arbre (option --include-transitive selon les outils).

2. SBOM obsolète

Un SBOM généré il y a 6 mois est faux aujourd'hui. Automatisation CI/CD obligatoire + rotation à chaque build release.

3. Format incompatible

Générer en CycloneDX XML quand votre client attend du JSON rend le fichier difficile à ingérer. Stabilisez-vous sur CycloneDX JSON 1.5+ (ou SPDX JSON).

4. Composants sans purl

Sans Package URL, impossible de cross-référencer automatiquement avec les bases CVE. Tous les générateurs modernes produisent les purls, mais les SBOM artisanaux les omettent souvent.

5. Pas de suivi dans la durée

Générer ≠ exploiter. Sans outillage pour alerter quand un nouveau CVE affecte votre portefeuille, le SBOM reste un artefact statique.

Comment ResiPlan industrialise votre SBOM

Notre module SBOM Management inclut :

• Import glisser-déposer CycloneDX + SPDX (JSON/XML)
• Parsing automatique des composants, purls, licenses, hashes
• Cross-référence CVE continue sur chaque composant avec alertes
• Diff entre versions de SBOM (nouveau composant, changement de version)
• Ingestion SBOM fournisseur avec normalisation et traçabilité
• Dashboard global : X composants, Y vulnérabilités, Z critiques
• Export client-ready avec composants sensibles masqués au besoin

Couplé aux modules PDE Registry, CVD et Annex I de la suite CRA Compliance, vous obtenez une vision bout en bout de votre posture sécurité produit.

Pour aller plus loin

• CRA : 8 clauses contractuelles pour fournisseurs PEN
• Suite CRA Compliance : 7 modules ResiPlan
• Solution Product Security Officer
• Analyse IA de contrats DORA/NIS2/CRA