BSI TR-03183 : niveaux de qualité SBOM et conformité CRA

Le règlement sur la cyberrésilience impose un Software Bill of Materials, mais en laisse le détail technique à d'autres. Il exige un SBOM lisible par machine couvrant au moins les dépendances de premier niveau du produit, et c'est à peu près là que s'arrêtent les spécifications du règlement. Aucune liste de champs. Aucun plancher de version de format. Aucun schéma pour les avis de sécurité. L'Office fédéral allemand de la sécurité des systèmes d'information (BSI) a comblé cette lacune avec la BSI TR-03183, un guide technique en trois parties qui désigne des versions de format précises, liste l'ensemble des champs requis et associe la génération de SBOM à la publication d'avis de vulnérabilité. Traitez-la comme la spécification pratique qui sous-tend l'obligation légale, et non comme un règlement concurrent.

Présentation de la BSI TR-03183

Le BSI est l'agence nationale de cybersécurité allemande. Son guide technique TR-03183 porte le titre complet Cyber Resilience Requirements for Manufacturers and Products, avec des parties numérotées et versionnées de façon indépendante. Le guide cible les fabricants qui se préparent au règlement sur la cyberrésilience, en traduisant les obligations de l'Annexe I du CRA en exigences techniques concrètes et vérifiables.

Les trois parties du document, avec les versions en vigueur au moment de la rédaction :

Partie	Version	Publiée	Périmètre
Part 1	v0.10.0	2025-09-12	Exigences générales de cyberrésilience au titre du CRA, issues de l'Annexe I, de l'Annexe II et de l'Annexe VII
Part 2	v2.1.0	2025-08-20	Software Bill of Materials (SBOM) : formats, champs, génération et mises à jour
Part 3	v1.0.0	2025-08-20	Rapports et notifications de vulnérabilités, notamment CVD, security.txt et avis CSAF

Le BSI présente le guide comme un instrument transitoire :

"This Technical Guideline will be superseded in the current form as soon as its content is covered by the corresponding standardisation deliverables under the aforementioned standardisation request."

Cette phrase résume la manière dont vous devez appréhender la TR-03183. Il s'agit de la lecture faite par le BSI de ce à quoi devrait ressembler un programme SBOM et de vulnérabilités conforme au CRA, tant que les normes harmonisées CEN/CENELEC sont encore à l'état de projet. Lorsque celles-ci seront publiées, les normes harmonisées prévaudront ; dans l'intervalle, la TR-03183 est la spécification publiquement disponible la plus détaillée, alignée sur l'Annexe I du CRA.

graph LR
    A[BSI TR-03183]
    A --- P1[Partie 1
Exigences générales
du règlement]
    A --- P2[Partie 2
SBOM]
    A --- P3[Partie 3
Rapports de
vulnérabilités]
    P2 --- F1[CycloneDX 1.6
ou SPDX 3.0.1]
    P2 --- F2[Champs obligatoires, additionnels
et optionnels]
    P3 --- C1[CSAF 2.0
avis]
    P3 --- C2[Balise CSAF dans security.txt]
    style A fill:#008080,stroke:#005f5f,color:#fff
    style P1 fill:#e8f4f8,stroke:#008080,color:#333
    style P2 fill:#e8f4f8,stroke:#008080,color:#333
    style P3 fill:#e8f4f8,stroke:#008080,color:#333
    style F1 fill:#f8fafc,stroke:#008080,color:#333
    style F2 fill:#f8fafc,stroke:#008080,color:#333
    style C1 fill:#f8fafc,stroke:#008080,color:#333
    style C2 fill:#f8fafc,stroke:#008080,color:#333

Les lacunes du CRA comblées par la TR-03183

Vous pouvez lire les clauses SBOM du CRA de bout en bout sans apprendre quels champs doivent figurer dans votre document, quelle version de format satisfait à l'obligation, ni comment publier les avis qui en découlent. La TR-03183 comble trois lacunes précises.

Lacune dans le texte du CRA	Ce que la TR-03183 précise
Le CRA exige un SBOM sans lister aucun champ de données (Annexe I partie II (1))	La TR-03183 énumère les champs Required, Additional et Optional, tant au niveau du document SBOM qu'au niveau de chaque composant
Le CRA indique que les formats doivent être « couramment utilisés et lisibles par machine » sans en nommer aucun	La TR-03183 les nomme : « CycloneDX, version 1.6 or higher » ou « System Package Data Exchange (SPDX), version 3.0.1 or higher »
Le CRA exige le signalement au CSIRT coordinateur et à l'ENISA des vulnérabilités activement exploitées, sans préciser de format public pour les avis (Article 14)	La TR-03183 aligne les avis sur CSAF 2.0 et renvoie à la norme ISO/IEC 20153:2025

Pour le détail des obligations CRA associées, consultez les exigences SBOM du CRA. Pour l'horloge de signalement de l'Article 14 qui rend les données de composants actuelles opérationnellement importantes, consultez le signalement des vulnérabilités et incidents CRA.

Champs Required, Additional et Optional

La TR-03183 v2.1.0 n'utilise pas les termes « Basic », « Standard » ou « Comprehensive ». Tout schéma ou résumé de fournisseur qui présente trois « niveaux de qualité » nommés avec ces étiquettes introduit une structure absente de la spécification. Le modèle de conformité de la v2.1.0 est binaire au niveau du champ : un champ est Required (toujours présent), Additional (obligatoire lorsque la donnée existe) ou Optional.

Les trois catégories de champs :

Catégorie	Signification	Exemples
Required au niveau du SBOM	Champs au niveau du document qui DOIVENT toujours être présents	Créateur du SBOM, Horodatage
Required au niveau de chaque composant	Champs au niveau du composant qui DOIVENT toujours être présents	Nom du composant, Version du composant, Licences de distribution, Hachage (SHA-512), Dépendances envers d'autres composants, Nom de fichier, Propriété exécutable, Propriété archive, Propriété structurée, Créateur du composant
Additional au niveau de chaque composant	Obligatoire si la donnée existe, à omettre sinon	URI du code source, URI de la forme déployable du composant, Autres identifiants uniques (CPE, purl), Licences originales
Optional au niveau de chaque composant	PEUT être inclus	Licence effective, Hachage du code source, URL du security.txt

La TR-03183 impose également la résolution récursive des dépendances : vous résolvez les dépendances de chaque composant inclus dans le périmètre de livraison, et non uniquement les dépendances immédiates. C'est sa réponse au plancher vague des « dépendances de premier niveau » fixé par l'Annexe I partie II (1) du CRA : parcourez l'arborescence complète.

Exigences champ par champ

Les champs les plus fréquemment demandés par les équipes, avec leur catégorie v2.1.0.

Champ	Catégorie	Notes
Créateur du SBOM	Required (niveau SBOM)	E-mail ou URL du producteur
Horodatage	Required (niveau SBOM)	ISO 8601
Nom du composant	Required	Toujours renseigné pour chaque entrée
Version du composant	Required	Version exacte, pas une plage
Créateur du composant	Required	Correspond à « Supplier » dans les libellés antérieurs
Nom de fichier du composant	Required	Souvent absent des sorties par défaut des outils
Dépendances envers d'autres composants	Required	Résolues récursivement
Licences de distribution	Required	Licences telles que distribuées
Hachage du composant déployable	Required	SHA-512
Propriété exécutable	Required	Booléen : le composant est-il exécutable ?
Propriété archive	Required	Booléen : le composant est-il une archive ?
Propriété structurée	Required	Booléen : indicateur de charge utile structurée
URI du code source	Additional	Obligatoire lorsque connu
URI du composant déployable	Additional	Obligatoire lorsque connu
Autres identifiants uniques (CPE, purl)	Additional	Obligatoire lorsque disponible ; pas inconditionnellement requis
Licences originales	Additional	Licence amont avant distribution
Licence effective	Optional	Résultat de la réconciliation des licences
Hachage du code source	Optional	Hachage du code source avant compilation
URL du security.txt	Optional	Pointeur vers le point d'entrée de divulgation des vulnérabilités

La ligne qui surprend le plus les équipes est Autres identifiants uniques (CPE, purl). Les équipes traitent les package URLs comme la clé primaire d'un SBOM. Sous la TR-03183 v2.1.0, purl relève de la catégorie Additional, obligatoire uniquement lorsque la donnée existe. L'identifiant de composant inconditionnel est le hachage SHA-512 de l'artefact déployable, associé au nom et à la version. Si vos outils ne peuvent pas calculer de purl pour une bibliothèque interne privée, cela ne compromet pas la conformité. S'ils ne peuvent pas calculer le SHA-512, si. Consultez les erreurs SBOM courantes pour les lacunes de champs associées.

Prise en charge de CycloneDX et SPDX

La TR-03183 désigne les formats acceptés et les versions minimales :

"A newly generated or updated SBOM MUST be in JSON- or XML-format and a valid SBOM according to one of the following specifications in one of the specified versions: CycloneDX, version 1.6 or higher"

"System Package Data Exchange (SPDX), version 3.0.1 or higher"

Le texte en anglais de BSI étant la seule version officielle, voici une reformulation de ces deux exigences : tout SBOM nouvellement généré ou mis à jour doit être au format JSON ou XML, et valide selon l'une des spécifications suivantes dans l'une des versions indiquées : CycloneDX version 1.6 ou supérieure, ou SPDX version 3.0.1 ou supérieure.

Les notes de mise à jour de la v2.1.0 documentent également le chemin de migration : la v2.0.0 (2024-09-20) a fait passer CycloneDX de 1.4 à 1.5 et SPDX de versions antérieures à 2.2.1. La v2.1.0 (2025-08-20) a fait passer CycloneDX de 1.5 à 1.6 et SPDX de 2.2.1 à 3.0.1.

La conséquence concrète est que les outils produisant des sorties CycloneDX 1.4 par défaut (encore fréquent dans les configurations CI plus anciennes) ne sont pas conformes à la v2.1.0. CycloneDX 1.6 a introduit un support affiné des actifs cryptographiques et du ML BOM ; SPDX 3.0.1 est une refonte majeure avec un nouveau modèle de charge utile. Votre base CI doit comporter un indicateur explicite --spec-version 1.6 ou son équivalent. Pour une comparaison des deux formats et de la maturité des outils, consultez CycloneDX vs SPDX.

Squelette CycloneDX 1.6 aligné sur la TR-03183, avec les champs Required au niveau du document renseignés :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2027-01-15T10:00:00Z",
    "tools": [
      { "vendor": "Example", "name": "syft", "version": "1.10.0" }
    ],
    "authors": [
      { "name": "Example GmbH security team", "email": "security@example.de" }
    ],
    "component": {
      "type": "firmware",
      "name": "SmartSensor Pro",
      "version": "2.4.1",
      "supplier": { "name": "Example GmbH", "url": ["https://example.de"] },
      "purl": "pkg:firmware/example/smartsensor-pro@2.4.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.12",
      "purl": "pkg:generic/openssl@3.0.12",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [
        { "alg": "SHA-512", "content": "ddaf35a193617aba..." }
      ],
      "supplier": { "name": "OpenSSL Software Foundation" },
      "properties": [
        { "name": "executable", "value": "true" },
        { "name": "archive", "value": "false" }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:firmware/example/smartsensor-pro@2.4.1",
      "dependsOn": ["pkg:generic/openssl@3.0.12"]
    }
  ]
}

Les entrées authors, timestamp et hashes SHA-512 sont les champs Required au niveau du document et du composant les plus souvent absents des configurations CI par défaut. Validez-les avec cyclonedx-cli validate --input-version 1.6 avant de considérer une sortie comme conforme à la TR-03183.

Relation entre TR-03183, CSAF et VEX

La TR-03183 traite ensemble les mécanismes SBOM et d'avis de vulnérabilité. La règle principale est simple : CSAF est recommandé pour les avis et opérationnellement requis pour la publication via security.txt. VEX n'est jamais imposé.

Mécanisme	Force	Signification
CSAF 2.0 comme format d'avis	Recommandé	« The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile) »
Balise CSAF dans security.txt	DOIT	La déclaration security.txt référençant les documents CSAF doit commencer par la balise CSAF:
URI des métadonnées du fournisseur	DEVRAIT	Le fabricant DEVRAIT fournir l'URI de provider-metadata.json pour les documents CSAF
ISO/IEC 20153:2025	Référence	La forme normative internationale de CSAF v2.0
VEX	Informatif	VEX apparaît comme un profil CSAF et comme l'un des plusieurs canaux « should » pour les informations de vulnérabilité

CSAF (Common Security Advisory Framework) version 2.0 est une norme OASIS publiée le 18 novembre 2022, avec l'Errata 01 émis le 26 janvier 2024. Elle définit un schéma JSON pour les avis de sécurité lisibles par machine. Les CERT allemands (BSI-CERT, CERT-Bund) publient et consomment CSAF par défaut ; l'éditeur Secvisogram et le validateur OASIS CSAF constituent les outils de référence.

Le lien avec l'Article 14 est plus nuancé que certains commentaires ne le laissent entendre. L'Article 14 du CRA fixe des délais de signalement à l'ENISA et au CSIRT coordinateur (24 heures pour l'alerte précoce, 72 heures pour la notification, et un rapport final 14 jours après la disponibilité d'un correctif pour une vulnérabilité activement exploitée, ou un mois après la notification pour un incident grave). Il ne précise pas de format public pour les avis. La TR-03183 comble cette lacune : une fois que vous avez notifié l'ENISA, le document CSAF que vous publiez sous votre security.txt est l'artefact opérationnel que vos clients ingèrent. Sans chaîne d'outillage CSAF en place avant le 11 septembre 2026, vous pouvez encore satisfaire à l'Article 14, mais vous ne satisferez pas aux attentes de langage contractuel et de security.txt qui découlent de la TR-03183.

VEX mérite une note distincte. La TR-03183 ne mentionne VEX que comme un profil CSAF et comme l'un des canaux possibles pour l'échange d'informations de vulnérabilité ; il n'est jamais requis. Du point de vue du CRA, VEX est utile pour les déclarations not_affected au niveau du composant, qui évitent la fatigue d'alerte lorsqu'un SBOM contient une bibliothèque avec une CVE connue qui n'est pas réellement accessible depuis votre code. Ce n'est pas une obligation de la TR-03183. Utilisez-le là où il apporte une valeur réelle.

La TR-03183 s'applique-t-elle en dehors de l'Allemagne ?

La TR-03183 est un guide technique national allemand émis par le BSI, et non un règlement à portée européenne ; elle ne revendique pas d'applicabilité en dehors de l'Allemagne.

En pratique, trois facteurs rendent la TR-03183 pertinente pour les fabricants établis en dehors de l'Allemagne.

Premièrement, le marché allemand est le plus grand de l'UE, et les acheteurs allemands y font de plus en plus explicitement référence dans leurs appels d'offres. Si vous vendez à un client allemand, attendez-vous à retrouver le vocabulaire de la TR-03183 dans ses questionnaires de sécurité et ses contrats fournisseurs.

Deuxièmement, aucune autre spécification alignée sur le CRA n'atteint à ce jour ce niveau de détail, de sorte que les fabricants se tournent vers la TR-03183 comme référentiel pratique.

Troisièmement, la TR-03183 s'articule autour des mêmes annexes du CRA que vous devez déjà respecter : l'Annexe I, l'Annexe II et l'Annexe VII. Une documentation préparée selon la TR-03183 produit les preuves techniques qu'une autorité de surveillance du marché de l'UE attend dans votre dossier Annex VII, SBOM compris. Consultez la documentation technique pour la liste complète du contenu de l'Annex VII.

Mettre en œuvre la TR-03183 volontairement est un choix d'ingénierie défendable, mais pas une obligation légale en dehors de l'Allemagne. Si vos produits ne comportent pas de composant matériel, cela s'arrête là. Dans le cas contraire, le même document peut accueillir vos entrées HBOM aux côtés des composants logiciels.