Le SBOM — Software Bill of Materials — est devenu en 2025-2026 une exigence concrète, pas un mot-clé d'analyste. Le CRA européen le rend obligatoire pour les éditeurs en 2027. Les acheteurs grand compte le demandent dans leurs DDQ. Et les régulateurs sectoriels (DORA, HDS) commencent à l'inscrire dans leurs questionnaires. Voici comment le produire correctement.
Ce qu'est vraiment un SBOM
Un SBOM est une liste structurée et machine-lisible des composants logiciels qui constituent une application. Pour chaque composant : son nom, sa version, son fournisseur, sa licence, ses dépendances transitives, idéalement son hash et sa provenance.
Pourquoi maintenant ? Trois facteurs :
- Supply chain attacks post-SolarWinds, Log4j, xz/liblzma : on a réalisé qu'on ne savait pas ce qu'on déployait.
- Régulation : Executive Order 14028 (US 2021), CRA (EU 2027), exigences sectorielles.
- Industrialisation des outils : ce qui prenait 3 jours en 2022 prend 3 minutes en 2026.
SPDX vs CycloneDX : choisir vraiment
Deux formats standards dominent. Beaucoup d'organisations choisissent par défaut sans comprendre. Voici la lecture honnête.
SPDX
- Maintenu par la Linux Foundation depuis 2010.
- Format originel orienté licence et conformité juridique.
- Plus verbeux, plus rigoureux sur les métadonnées légales.
- Adoption forte côté open source enterprise.
- Standard ISO/IEC 5962:2021.
CycloneDX
- Maintenu par OWASP depuis 2017.
- Format originel orienté sécurité applicative et vulnerability management.
- Plus concis, plus orienté DevSecOps.
- Adoption forte côté outils de sécurité (Snyk, Dependency-Track).
- Support natif des SaaS de SCA.
La recommandation
- Pour la conformité CRA, juridique, licence : SPDX.
- Pour la sécurité opérationnelle, vulnerability management quotidien : CycloneDX.
- Pour les organisations qui font les deux : les deux. La plupart des outils modernes exportent dans les deux formats — choisissez l'un comme primaire et générez l'autre en miroir.
Générer un SBOM automatiquement
L'erreur courante : faire un SBOM manuel une fois et le considérer comme acquis. Le SBOM doit être généré à chaque build, automatiquement, et signé.
Pour des projets Node/JS
``` # CycloneDX npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
# SPDX npx @cyclonedx/cyclonedx-npm --output-format SPDX-JSON --output-file sbom.spdx.json ```
Pour Python
`` # Avec syft (multi-langage) syft scan dir:. -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.json ``
Pour des images Docker
`` # Syft sur image Docker syft scan myapp:latest -o cyclonedx-json=sbom.cdx.json ``
Multi-langage générique
syft (Anchore) couvre JS, Python, Go, Rust, Java, Ruby, .NET, et les images Docker en une commande. C'est le meilleur défaut pour un pipeline polyglotte.
Signature et provenance
Un SBOM non signé est inutilisable juridiquement. Tout le monde peut en produire un fictif. Pour qu'il ait valeur de preuve, il doit être :
- Signé cryptographiquement.
- Lié à un build identifiable (hash de l'artefact final).
- Lié à une provenance (qui l'a produit, comment, quand).
Sigstore + cosign
Sigstore (CNCF) est le standard 2024-2026 pour la signature sans clé persistante (keyless signing via OIDC). Tutorial complet : voir Sigstore et signature de containers.
``` # Signer un SBOM cosign sign-blob --bundle sbom.cdx.json.bundle sbom.cdx.json
# Vérifier cosign verify-blob --bundle sbom.cdx.json.bundle sbom.cdx.json ```
SLSA provenance
SLSA (Supply chain Levels for Software Artifacts) définit des niveaux de provenance reproductible. Pour un SaaS B2B en 2026, viser SLSA Level 2 est un objectif réaliste.
Distribution du SBOM
Le SBOM doit être accessible à vos clients qui en ont besoin. Plusieurs patterns :
1. Inline dans l'image (containers)
`` docker buildx build --sbom=true -t myapp:latest . ``
L'attestation est attachée à l'image et publiée avec elle dans le registry.
2. Endpoint dédié sur votre site
`` https://yourapp.example/.well-known/sbom/v1.cdx.json ``
Pratique pour les acheteurs DDQ. À mettre en place quand un client le demande, pas avant.
3. À la demande via portail client
Pour les SaaS multi-tenant avec SBOM par client — rare mais existe.
Maintenance vivante
Un SBOM produit en septembre 2025 et oublié en mai 2026 est aussi nuisible que pas de SBOM. Les vulnérabilités de vos dépendances évoluent, les versions changent.
Continuous SBOM
Le pattern moderne : votre pipeline régénère le SBOM à chaque déploiement, et un système comme Dependency-Track ou GUAC croise en continu votre SBOM avec les nouvelles CVE publiées.
Outils 2026 :
- Dependency-Track (OWASP) : open source, ingère CycloneDX, alerting CVE temps réel.
- GUAC (Google/CNCF) : graphe de provenance et vulnérabilités, plus récent, prometteur.
- Snyk SBOM : SaaS payant, intégré à leur stack SCA.
Les pièges courants
"Mon Dependabot suffit"
Non. Dependabot scanne pour vous mais ne produit pas un SBOM exportable et signé que vous pouvez fournir à un acheteur ou un régulateur. C'est complémentaire, pas équivalent.
"Je génère un SBOM par release"
Insuffisant en 2026. La bonne fréquence est par déploiement, pas par release. Si vous déployez 10 fois par semaine, vous avez 10 SBOM par semaine.
"Mon SBOM contient mes secrets"
Si votre SBOM contient des chemins absolus vers des fichiers de configuration ou des URL avec credentials, il y a un bug dans votre tooling. Le SBOM ne doit jamais contenir de secrets, par construction.
Conformité CRA : le SBOM exigé
Le Cyber Resilience Act (application complète décembre 2027) demande pour les produits "important" et "critical" :
- SBOM tenu à jour.
- Format machine-lisible.
- Disponibilité pendant la durée de support du produit (5 ans minimum).
- Pour les "critical" : signature et provenance.
Voir CRA roadmap des jalons 2026-2027 pour le contexte complet.
