Le règlement sur la cyberrésilience impose un Software Bill of Materials, mais en laisse le détail technique à d'autres. L'Annexe I, section II, point 1 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.
Synthèse
- La BSI TR-03183 est publiée en trois parties : Part 1 (exigences générales de cyberrésilience au titre du CRA), Part 2 (SBOM), Part 3 (rapports et notifications de vulnérabilités). La Part 2 v2.1.0, publiée le 20 août 2025, est le guide SBOM en vigueur.
- La Part 2 §4 exige CycloneDX version 1.6 ou supérieure, ou SPDX version 3.0.1 ou supérieure. Tout autre format est non conforme.
- La spécification organise les champs de données en trois catégories : Required (toujours obligatoire), Additional (obligatoire lorsque la donnée existe) et Optional. La v2.1.0 ne comporte aucun niveau « Basic », « Standard » ou « Comprehensive ».
- CSAF 2.0 est le format recommandé pour les avis de vulnérabilité au titre de la Part 2 §8.1.14. La Part 3 §4.2.8 exige la balise
CSAF:dans votresecurity.txtlorsque vous publiez des documents CSAF. VEX n'est jamais imposé ; il est uniquement décrit comme un profil CSAF. - La Part 1 §1 indique que le guide sera remplacé dès que les normes harmonisées CEN/CENELEC élaborées dans le cadre de la demande de normalisation liée au CRA seront publiées. La TR-03183 est le référentiel de substitution le plus proche disponible jusqu'à cette échéance.
- Les critères de conformité sont les suivants : CycloneDX 1.6 au minimum, hachages SHA-512 pour chaque composant déployable, métadonnées de créateur et d'horodatage au niveau du document SBOM, et une chaîne d'avis CSAF conforme à la Part 3.
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 |
La Part 1 §1 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 |
|---|---|
| L'Annexe I, section II, point 1 exige un SBOM sans lister aucun champ de données | La Part 2 §5.2 é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 Part 2 §4 précise : « CycloneDX, version 1.6 or higher » ou « System Package Data Exchange (SPDX), version 3.0.1 or higher » |
| L'Article 14 exige le signalement à l'ENISA des vulnérabilités activement exploitées, sans préciser de format public pour les avis | La Part 3 §4.2.8 et §5.1.6 alignent les avis sur CSAF 2.0 et renvoient à la norme ISO/IEC 20153:2025 |
Pour le détail des obligations CRA associées, consultez les exigences SBOM du CRA. Pour le contexte des délais et des sanctions qui définit l'urgence, consultez les délais de conformité SBOM et les sanctions.
Champs Required, Additional et Optional dans la Part 2
La Part 2 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, référencées aux sections de la spécification :
| Catégorie | Section de la spécification | Signification | Exemples |
|---|---|---|---|
| Required au niveau du SBOM | §5.2.1 | Champs au niveau du document qui DOIVENT toujours être présents | Créateur du SBOM, Horodatage |
| Required au niveau de chaque composant | §5.2.2 | 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 | §5.2.4 | 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 | §5.2.5 | PEUT être inclus | Licence effective, Hachage du code source, URL du security.txt |
La Part 2 impose également une exigence de résolution récursive au §5.1 : la résolution des dépendances DOIT être effectuée pour chaque composant inclus dans le périmètre de livraison. C'est la réponse de la spécification au plancher vague des « dépendances de premier niveau » fixé par l'Annexe I, section II, point 1 du CRA : la TR-03183 attend que vous parcouriez l'arborescence complète, et non que vous vous arrêtiez aux dépendances immédiates.
Des synthèses publiques antérieures (dont certaines émanant des propres communications du BSI) présentaient la TR-03183 comme définissant trois niveaux de qualité portant ces noms. La v2.1.0 n'utilise pas cette taxonomie. Si votre liste de vérification d'audit fait référence à « Niveau 1 », « niveau Comprehensive » ou à des termes similaires, elle renvoie à un modèle qui ne correspond plus à la spécification publiée. Mettez-la à jour pour adopter les catégories Required / Additional / Optional.
Exigences champ par champ
Le tableau complet des champs les plus fréquemment demandés par les équipes, référencés aux sections de la v2.1.0.
| Champ | Catégorie | Section de la spécification | Notes |
|---|---|---|---|
| Créateur du SBOM | Required (niveau SBOM) | §5.2.1 | E-mail ou URL du producteur |
| Horodatage | Required (niveau SBOM) | §5.2.1 | ISO 8601 |
| Nom du composant | Required | §5.2.2 | Toujours renseigné pour chaque entrée |
| Version du composant | Required | §5.2.2 | Version exacte, pas une plage |
| Créateur du composant | Required | §5.2.2 | Correspond à « Supplier » dans les libellés antérieurs |
| Nom de fichier du composant | Required | §5.2.2 | Souvent absent des sorties par défaut des outils |
| Dépendances envers d'autres composants | Required | §5.2.2 | Récursif conformément au §5.1 |
| Licences de distribution | Required | §5.2.2 | Licences telles que distribuées |
| Hachage du composant déployable | Required | §5.2.2 | SHA-512 |
| Propriété exécutable | Required | §5.2.2 | Booléen : le composant est-il exécutable ? |
| Propriété archive | Required | §5.2.2 | Booléen : le composant est-il une archive ? |
| Propriété structurée | Required | §5.2.2 | Booléen : indicateur de charge utile structurée |
| URI du code source | Additional | §5.2.4 | Obligatoire lorsque connu |
| URI du composant déployable | Additional | §5.2.4 | Obligatoire lorsque connu |
| Autres identifiants uniques (CPE, purl) | Additional | §5.2.4 | Obligatoire lorsque disponible ; pas inconditionnellement requis |
| Licences originales | Additional | §5.2.4 | Licence amont avant distribution |
| Licence effective | Optional | §5.2.5 | Résultat de la réconciliation des licences |
| Hachage du code source | Optional | §5.2.5 | Hachage du code source avant compilation |
URL du security.txt |
Optional | §5.2.5 | 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 Part 2 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 Part 2 §4 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 répartit les mécanismes SBOM et d'avis de vulnérabilité entre la Part 2 et la Part 3. La règle principale est simple : CSAF est recommandé dans la Part 2 et opérationnellement requis pour la publication via security.txt dans la Part 3. VEX n'est jamais imposé.
| Mécanisme | Emplacement TR-03183 | Force | Signification |
|---|---|---|---|
| CSAF 2.0 comme format d'avis | Part 2 §8.1.14 | Recommandé | « The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile) » |
Balise CSAF dans security.txt |
Part 3 §4.2.8 (b) | 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 | Part 3 §4.2.8 (a) | DEVRAIT | Le fabricant DEVRAIT fournir l'URI de provider-metadata.json pour les documents CSAF |
| ISO/IEC 20153:2025 | Part 3 §5.1.6 | Référence | La forme normative internationale de CSAF v2.0 |
| VEX | Part 2 §1 et §8.1.14 | 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 h pour l'alerte précoce, 72 h pour la notification de vulnérabilité, et 14 jours pour le rapport final). Il ne précise pas de format public pour les avis. La Part 3 de 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 Part 2 §8.1.14 mentionne VEX comme un profil CSAF, et la Part 2 §1 le cite comme l'un des canaux possibles pour « l'échange d'informations de vulnérabilité ». La Part 3 ne mentionne pas du tout VEX. 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. Aucune de ses trois parties ne revendique une applicabilité en dehors de l'Allemagne. La Part 1 §1 prévoit explicitement d'être remplacée par les normes harmonisées CEN/CENELEC une fois celles-ci publiées dans le cadre de la demande de normalisation liée au CRA.
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, il n'existe pas, à ce jour, de spécification alternative alignée sur le CRA avec un niveau de détail comparable. Les normes harmonisées CEN/CENELEC relevant de la demande de normalisation liée au CRA sont encore à l'état de projet. La TR-03183 est le référentiel de substitution le plus proche.
Troisièmement, la Part 1 de la TR-03183 s'articule explicitement autour de l'Annexe I, de l'Annexe II et de l'Annexe VII du CRA. Un fabricant qui constitue sa documentation en s'appuyant sur la TR-03183 produira du contenu Annexe VII (notamment les points 2(b) et 8 relatifs aux SBOM) que toute autorité de surveillance du marché de l'UE pourra lire. Consultez la documentation technique Annexe VII pour la liste complète du contenu.
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.
Questions fréquentes
Quels sont les éléments minimaux définis par la NTIA ?
Le document Minimum Elements For a Software Bill of Materials (SBOM) de la NTIA (National Telecommunications and Information Administration), publié le 12 juillet 2021 par le Département américain du Commerce, définit un socle de référence que la plupart des SBOM alignés sur le CRA dépassent largement. Les sept champs de données sont : Supplier Name (nom du fournisseur), Component Name (nom du composant), Version of the Component (version du composant), Other Unique Identifiers (autres identifiants uniques), Dependency Relationship (relation de dépendance), Author of SBOM Data (auteur des données SBOM) et Timestamp (horodatage). Le document définit également trois catégories de premier niveau : Data Fields (champs de données), Automation Support (prise en charge de l'automatisation) et Practices and Processes (pratiques et processus), cette dernière contenant « Known Unknowns » comme sous-élément, et non comme catégorie de premier niveau. La TR-03183 Part 2 v2.1.0 ajoute aux sept éléments NTIA : le hachage SHA-512, le nom de fichier (Filename), ainsi que les propriétés Executable, Archive et Structured, et impose la résolution récursive des dépendances au §5.1. La seule conformité NTIA ne satisfait pas à la TR-03183.
Qu'est-ce que CSAF 2.0 ?
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 : quelles versions de produits sont affectées, lesquelles sont corrigées, quelles mesures d'atténuation existent et comment les clients doivent réagir. La TR-03183 Part 2 §8.1.14 recommande CSAF pour la diffusion des informations de vulnérabilité, et la Part 3 §4.2.8 exige la balise CSAF: dans votre security.txt lorsque vous publiez des documents CSAF. La Part 3 §5.1.6 renvoie à la norme ISO/IEC 20153:2025, qui standardise CSAF 2.0. L'éditeur Secvisogram et le validateur OASIS CSAF constituent les outils de référence. Les CERT allemands publient et consomment CSAF par défaut ; pour tout fabricant disposant de clients allemands, CSAF est opérationnellement requis, et non facultatif.
VEX est-il requis pour chaque CVE ?
Non. La TR-03183 n'impose pas VEX. La Part 2 §8.1.14 présente VEX comme un profil CSAF et traite les deux comme un canal recommandé (et non requis) pour les informations de vulnérabilité. La Part 3 ne mentionne pas du tout VEX. 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. CycloneDX 1.6 prend en charge les assertions VEX directement dans le document SBOM, sans nécessiter un fichier distinct par CVE. Émettre du VEX là où cela apporte de la clarté démontre une diligence raisonnable au titre de l'Article 13(5) du CRA. Émettre du VEX pour chaque CVE de votre SBOM n'est pas une obligation de la TR-03183, et représente rarement un usage pertinent du temps d'analyse.
La TR-03183 s'applique-t-elle en dehors de l'Allemagne ?
Sur le plan juridique, non. La TR-03183 est un guide technique national allemand émis par le BSI, et aucune de ses parties 1, 2 ou 3 ne revendique d'applicabilité en dehors de l'Allemagne. La Part 1 §1 indique explicitement que le guide sera remplacé dès que les normes harmonisées CEN/CENELEC relevant de la demande de normalisation liée au CRA seront publiées. En pratique, trois facteurs la rendent pertinente dans l'ensemble de l'UE : le marché allemand est le plus grand de l'UE, le langage des appels d'offres allemands y fait directement référence, et il n'existe pas, à ce stade, de spécification alternative alignée sur le CRA avec un niveau de détail comparable. 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. Traitez-la comme le référentiel de substitution le plus proche des normes harmonisées du CRA qui ne sont pas encore publiées.