LA NOMENCLATURE LOGICIELLE · SBOM
La SBOM devient obligatoire pour vos produits
La SBOM devient obligatoire avec le Cyber Resilience Act. Ce qu'elle doit contenir, à partir de quand, et comment la contrôler.
Le Cyber Resilience Act (CRA) impose une nomenclature logicielle (SBOM) aux produits connectés qu'il vise.
Elle doit être lisible par une machine et couvrir au moins vos dépendances de niveau supérieur.
Vous n'avez pas à la publier. Mais elle fait partie de votre dossier technique, et une autorité de contrôle peut la demander.
Ce que c'est
Une SBOM, c'est la liste des ingrédients de votre logiciel
Un plat préparé affiche ses ingrédients. Votre logiciel aussi en a.
Des bibliothèques, des modules, des composants écrits par d'autres. La SBOM en est la liste, avec leurs versions.
À quoi sert-elle ? Une faille est publiée sur une bibliothèque très répandue. Avec une SBOM, vous savez en quelques minutes si vos produits l'utilisent. Sans elle, vous cherchez à la main, pendant que le délai de signalement court.
Annexe I, partie II
Ce que le règlement vous demande
À partir du 11 décembre 2027, chaque produit mis sur le marché doit avoir sa SBOM.
Elle fait partie de votre dossier technique.
| Ce que le règlement exige | Ce que cela veut dire pour vous |
|---|---|
| Un format courant, lisible par une machine | En pratique CycloneDX ou SPDX, produits par vos outils de développement |
| Au moins les dépendances de niveau supérieur | Les composants que votre produit appelle directement |
| Une pièce de votre dossier technique | L'autorité de contrôle peut la demander. La publier reste votre choix |
Le texte en détail : article 3, annexe I et article 13
La nomenclature des logiciels est définie à l'article 3, point 39.
L'annexe I, partie II, point 1 impose de recenser et documenter les composants, notamment par une nomenclature des logiciels dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur. Elle s'applique à compter du 11 décembre 2027.
La nomenclature fait partie de la documentation technique, que l'autorité de surveillance du marché peut demander.
La Commission peut en préciser le format et les éléments par acte d'exécution, ce qui n'est pas fait à ce jour (article 13, paragraphe 24).
Un produit mis sur le marché avant le 11 décembre 2027 n'est soumis à ces exigences que s'il fait ensuite l'objet d'une modification substantielle (article 69, paragraphe 2).
Le piège
Une SBOM incomplète ne vous protège pas
Le piège n'est pas de ne pas avoir de SBOM. C'est d'en avoir une qui ne dit rien.
Beaucoup de fichiers produits automatiquement ne relient aucun composant au produit principal. D'autres oublient les versions. D'autres encore oublient les identifiants qui permettent de rapprocher un composant des failles publiées.
Un tel fichier existe, mais il ne répond pas à ce que le règlement demande.
Le dossier
Vous déposez votre SBOM, le contrôle dit ce qui manque
Vous déposez la SBOM que sortent vos outils de développement. Le contrôle vous dit ce qui manque.
| Contrôle | Pourquoi il compte |
|---|---|
| Le produit décrit est identifié | Sinon, impossible de savoir à quoi s'applique la liste |
| Les dépendances de niveau supérieur sont déclarées | Le minimum fixé par le règlement. Aller plus loin aide à réagir plus vite. |
| Chacune porte une version | Une faille touche une version, pas un nom |
| Chacune porte un identifiant (purl ou CPE) | C'est ce qui permet de la rapprocher des failles publiées |
| Chacune est décrite dans le fichier | Une référence sans description ne sert à rien |
Le contrôle signale chaque point manquant. Chaque SBOM est rattachée à une version de votre produit, et les précédentes sont conservées. Quand une nouvelle version remplace une version déjà couverte, votre espace signale que sa SBOM reste à déposer.
Le contrôle de la SBOM est inclus dans le dossier, à 490 € HT par produit.
Le texte en détail : formats et limites
La SBOM est importée aux formats CycloneDX JSON ou SPDX 2 JSON, jusqu'à 5 Mo et 50 000 composants.
Le contrôle porte sur les dépendances de niveau supérieur, comme l'exige l'annexe I, partie II, point 1.
Le fichier déposé est conservé tel quel et reste téléchargeable à l'identique.
Notre engagement
Ce que nous ne faisons pas
Nous ne fabriquons pas votre SBOM à partir d'un questionnaire.
Une liste de composants fiable ne peut venir que de vos outils de développement. La reconstituer de mémoire serait faux, et vous engagerait.
Nous ne disons jamais « conforme ».
Le contrôle dit ce qui est présent et ce qui manque. C'est vous, fabricant, qui répondez de votre dossier.
Nous ne croisons pas votre SBOM avec les failles publiées.
Les versions et les identifiants que le contrôle exige rendent ce croisement possible. Il reste à faire avec vos propres outils de suivi des vulnérabilités.
Questions fréquentes
Dois-je publier ma SBOM ?
Non. Le règlement ne l'impose pas. Vous pouvez la mettre à disposition de vos clients si vous le souhaitez.
Quel format choisir ?
CycloneDX ou SPDX, en JSON. Ce sont les deux formats ouverts les plus utilisés, et la plupart des outils de développement savent les produire. SPDX 3 n'est pas encore accepté.
Faut-il lister toutes les dépendances, même indirectes ?
Le règlement exige au moins les dépendances de niveau supérieur. Aller plus loin vous aide à réagir plus vite quand une faille sort.
Ma SBOM vaut-elle pour toutes les versions de mon produit ?
Non. Elle décrit une version. Une nouvelle version appelle une nouvelle SBOM.
Le CRA s'applique-t-il à mon produit ?
Faites le diagnostic, sans frais et sans compte.
Savoir si le règlement vous concerne
Treize questions pour savoir si le règlement vous concerne, à quel titre, et ce qui s’applique déjà à vous. Sans frais, sans compte.