Le Cyber Resilience Act, applicable totalement en décembre 2027, exige un SBOM (Software Bill of Materials) pour les produits "important" et "critical". Au-delà de la simple génération, le CRA impose des exigences spécifiques que les implémentations basiques ne couvrent pas. Voici ce qui distingue un SBOM CRA-compliant et l'architecture pour le tenir à jour pendant les 5 ans de support obligatoire.
Les exigences CRA pour le SBOM
D'après l'Annexe I, partie 2 du règlement et les actes délégués attendus :
1. Format machine-lisible
Le SBOM doit être dans un format standard machine-lisible. Les formats acceptés :
- SPDX (ISO/IEC 5962:2021).
- CycloneDX (OWASP).
- Tout autre format qui couvre les éléments de données minimaux.
2. Éléments de données minimaux
Le SBOM doit a minima contenir, pour chaque composant :
- Nom du composant.
- Version.
- Fournisseur (supplier).
- Identifiant unique (PURL, CPE).
- Hash cryptographique.
- Licence.
- Relation avec les autres composants (dépendances).
- Auteur du SBOM (qui l'a généré).
- Date de génération.
3. Mise à jour continue
Le SBOM doit être maintenu à jour pour la durée de support :
- Mise à jour à chaque release.
- Mise à jour à chaque correction de vulnérabilité.
- Capacité à fournir un SBOM pour toute version commercialisée pendant la durée de support (5 ans minimum).
4. Disponibilité
- Disponible aux autorités à la demande.
- Pour les produits "critical" : disponible aux utilisateurs (avec format machine-lisible).
5. Provenance vérifiable (pour "critical")
- Signature cryptographique.
- Lien vérifiable avec l'artefact (hash de l'artefact correspondant).
- Provenance reproductible (idéalement SLSA Level 2+).
Les gotchas typiques
Gotcha 1 — SBOM partiel
Beaucoup de SBOM générés automatiquement omettent des couches :
- Système d'exploitation embarqué dans les images Docker.
- Outils de runtime (interpréteurs, JVM).
- Composants téléchargés au runtime (plugins, modules).
Pour le CRA, le SBOM doit couvrir tout ce qui est livré. Une image Docker complète, pas seulement vos node_modules.
Gotcha 2 — Versions non précises
Un SBOM qui dit "lodash ^4.17.0" n'est pas un SBOM. Il faut "lodash 4.17.21" exact.
Solution : générer le SBOM après le npm install ou pip install, à partir des fichiers lockfiles.
Gotcha 3 — Pas de hash
Le hash cryptographique du composant est exigé. Beaucoup de générateurs l'omettent par défaut.
Configurer le générateur (Syft, CycloneDX, etc.) pour inclure les hashes systématiquement.
Gotcha 4 — SBOM non lié à l'artefact
Un SBOM doit être rattaché à un artefact spécifique. La relation se fait via :
- Hash de l'artefact final dans le SBOM.
- Ou attestation Sigstore qui lie SBOM et artefact (recommandé).
Voir Sigstore et signature de containers.
Gotcha 5 — Conservation insuffisante
Si vous supportez un produit pendant 5 ans, vous devez pouvoir produire le SBOM de la version livrée il y a 4 ans. Cela suppose un archivage organisé.
L'architecture pour tenir 5 ans
`` ┌─────────────────────────────────────────────────┐ │ CI/CD │ │ ├─ Build artefact │ │ ├─ Generate SBOM (Syft/CycloneDX) │ │ ├─ Sign SBOM (Sigstore) │ │ ├─ Attach SBOM to artefact (Sigstore attest) │ │ └─ Push to registry + archive │ └─────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────┐ │ Long-term archive │ │ ├─ S3 with Object Lock (5+ years) │ │ ├─ SBOM in SPDX + CycloneDX format │ │ ├─ Index by version + timestamp │ │ └─ Public endpoint for client retrieval │ └─────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────┐ │ Dependency-Track / GUAC │ │ ├─ Continuous CVE matching │ │ ├─ Alerts on new vulnerabilities │ │ └─ Reporting compliance │ └─────────────────────────────────────────────────┘ ``
Pipeline CI/CD type
```yaml
- name: Build artifact
run: docker build -t myapp:${{ github.sha }} .
- name: Generate SBOM (CycloneDX)
run: syft scan myapp:${{ github.sha }} -o cyclonedx-json=sbom.cdx.json
- name: Generate SBOM (SPDX)
run: syft scan myapp:${{ github.sha }} -o spdx-json=sbom.spdx.json
- name: Sign and attach SBOM
run: | cosign attest --yes --predicate sbom.cdx.json --type cyclonedx myapp:${{ github.sha }} cosign attest --yes --predicate sbom.spdx.json --type spdx myapp:${{ github.sha }}
- name: Archive SBOM
run: | aws s3 cp sbom.cdx.json s3://sbom-archive/myapp/${{ github.sha }}/ aws s3 cp sbom.spdx.json s3://sbom-archive/myapp/${{ github.sha }}/
- name: Notify Dependency-Track
run: | curl -X POST -H "X-Api-Key: $DT_KEY" \ -F "project=myapp" -F "version=${{ github.sha }}" \ -F "bom=@sbom.cdx.json" \ https://dt.example.com/api/v1/bom ```
Endpoint public pour les clients
Pour les produits critical, vous devez fournir le SBOM aux utilisateurs :
`` GET https://yourapp.example/.well-known/sbom/v1.cdx.json GET https://yourapp.example/.well-known/sbom/v1.0.42.cdx.json # version spécifique ``
Convention well-known URI proposée (en cours de normalisation IETF en 2026).
Le coût opérationnel
Pour une équipe de 30-100 devs :
- Setup initial : 2-4 semaines de travail.
- Coût récurrent : moins de 5% de surcharge pipeline.
- Stockage : <1 GB par 1000 builds, négligeable.
- Outillage : Dependency-Track (open source, gratuit) ou Snyk SBOM (~5-15 k€/an selon volume).
ROI : tu es prête pour CRA et pour les questions DDQ enterprise sur la supply chain.
Articulation avec les autres exigences CRA
Le SBOM s'inscrit dans l'ensemble des exigences CRA :
- Voir CRA roadmap des jalons 2026-2027 pour la vue complète.
- Voir Vulnerability disclosure CRA : monter le programme pour le canal de signalement.
Le piège — le SBOM "fait au stylo"
Certaines équipes maintiennent leur SBOM dans une feuille Excel ou un Notion. C'est un signal alarmant. À l'audit CRA, un SBOM non automatisé sera systématiquement considéré comme non-conforme parce que :
- Risque d'erreurs humaines.
- Pas mis à jour à chaque release.
- Pas reproductible.
- Pas de hash automatique.
L'automatisation par CI/CD est la seule approche viable.
Open source et CRA
Le CRA traite spécifiquement l'open source : les contributeurs occasionnels ne sont pas concernés, mais les "open source stewards" (organisations qui maintiennent du logiciel open source à but commercial) ont des obligations partielles. Si vous embarquez beaucoup d'OSS, vous restez responsable de la conformité du produit final, OSS inclus.
Conséquence pratique : pour chaque dépendance OSS critique, vérifier qu'elle a un SBOM disponible et qu'elle a un VDP. Sinon, c'est à vous de faire le travail.
