Provetry
ENDEDemander l’accès anticipé
Test gratuit
Demander l’accès anticipé

Provetry ouvre en novembre 2026. Le test CRA gratuit, les outils et les guides sont disponibles dès maintenant.

Le SBOM pour le Cyber Resilience Act : quoi produire, comment le tenir

7 min de lecture

Sur cette page
  1. Ce que demande vraiment le CRA
  2. CycloneDX ou SPDX ?
  3. Ce que contient un SBOM utile
  4. Le tenir à jour, sinon il ne vaut rien
  5. Pas à pas, selon votre écosystème
  6. Micrologiciels et appareils
  7. Ce que fait Provetry
  8. Sources

Une nomenclature logicielle (SBOM, pour software bill of materials) est la liste des composants d’un produit, avec leurs versions et leur provenance. À partir du 11 décembre 2027, le Cyber Resilience Act la rend obligatoire pour tous les produits de son champ. Bien avant cette date, c’est le seul moyen concret de tenir les obligations de signalement qui s’appliquent depuis septembre 2026 : impossible de savoir en 24 heures si une vulnérabilité exploitée vous touche si vous ne savez pas ce que vous livrez.

Ce que demande vraiment le CRA

L’annexe I, partie II du règlement fixe les exigences de gestion des vulnérabilités. La première demande aux fabricants de recenser et documenter les vulnérabilités et les composants de leurs produits, « notamment par l’établissement d’une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits ».

Quatre points en découlent :

  • Lisible par machine, dans un format courant. En pratique, CycloneDX ou SPDX.
  • Au moins les dépendances de niveau supérieur. Les paquets que votre produit déclare directement. Lister tout l’arbre, dépendances transitives comprises, est une meilleure pratique et rend la recherche de vulnérabilités bien plus fiable.
  • Partie de votre documentation technique. Le SBOM appartient au dossier que vous tenez pour les autorités (annexe VII). Les autorités de surveillance du marché peuvent le demander.
  • Pas forcément public. Le CRA ne vous oblige pas à publier votre SBOM. Vous pouvez le partager avec vos clients si vous le souhaitez ; beaucoup de clients professionnels vont commencer à le demander.

CycloneDX ou SPDX ?

Les deux conviennent. CycloneDX (un projet de l’OWASP, normalisé sous le nom ECMA-424) a été pensé pour la sécurité et porte bien les informations de vulnérabilité et d’exploitabilité (VEX). SPDX (Linux Foundation, ISO/IEC 5962) vient de la conformité des licences et sert beaucoup au suivi des licences open source. Sans préférence, commencez par CycloneDX et exportez en SPDX quand un client le demande.

Ce que contient un SBOM utile

Pour chaque composant :

  • son nom, sa version et son fournisseur ;
  • un identifiant unique, idéalement une package URL (purl) comme pkg:npm/express@4.19.2, pour que les bases de vulnérabilités puissent être croisées sans approximation ;
  • une empreinte, quand vous pouvez la produire ;
  • sa relation avec le reste (dépendance directe ou transitive).

Et pour le SBOM lui-même : le produit et la version qu’il décrit, quand il a été produit et par quel outil.

Le tenir à jour, sinon il ne vaut rien

Un SBOM décrit une version. L’échec classique est un document produit une fois pour un audit et jamais repris. Pour l’éviter :

  1. Générez-le dans votre chaîne de build, à chaque version, à partir des fichiers de verrouillage et des images de conteneurs que vous livrez vraiment.
  2. Gardez le SBOM de chaque version avec la version, pour pouvoir dire quelles versions en circulation contiennent un composant.
  3. Croisez-le chaque jour avec les données de vulnérabilités, pas seulement à la sortie : de nouvelles vulnérabilités sont publiées sur des composants livrés il y a des mois. Surveillez aussi l’exploitation (CISA KEV, la base européenne des vulnérabilités), puisque c’est elle qui déclenche l’horloge de signalement.
  4. Notez vos décisions. Quand un composant vulnérable est présent mais n’est pas exploitable dans votre produit, écrivez-le (une déclaration VEX). Cela évite de refaire la même analyse la fois suivante et documente votre diligence.

Pas à pas, selon votre écosystème

Comment produire le SBOM, et ce que chaque écosystème lui cache : npm, pnpm et Yarn, Python, Java, Rust, Go, .NET et images de conteneur.

Micrologiciels et appareils

Pour un appareil connecté, le SBOM doit aussi couvrir le micrologiciel : le système d’exploitation, ses paquets, le chargeur d’amorçage et tout binaire tiers. Si vous achetez des modules à des fournisseurs, demandez-leur leurs SBOM dès maintenant et inscrivez cette demande dans vos conditions d’achat. Au titre du CRA, les composants que vous intégrez sont sous votre responsabilité.

Ce que fait Provetry

Provetry établit le SBOM de chaque produit à partir de votre dépôt ou d’un fichier, à chaque version, en CycloneDX et en SPDX, surveille chaque composant face aux nouvelles vulnérabilités et à leur exploitation, et garde le SBOM de chaque version dans votre documentation technique. L’offre gratuite couvre le SBOM d’un produit, avec un récapitulatif hebdomadaire des vulnérabilités.

Ce guide est une information générale, pas un conseil juridique.

Sources