Le Software Bill of Materials (SBOM) est passé d'artefact optionnel à obligation contractuelle plus rapidement que la plupart des contractants défense ne s'y attendaient. En 2021, c'était une recommandation enfouie dans l'Executive Order 14028. En 2026, c'est une condition de porte — chaque binaire livré à un client américain ou NATO doit être accompagné d'un SBOM actuel, signé, lisible par machine, et le pipeline qui a produit le binaire doit pouvoir prouver, au moment de l'audit, que le SBOM a été généré depuis les mêmes sources, dans la même build, qui ont produit l'artefact. Cet article parcourt les décisions d'ingénierie qui déterminent si votre pipeline CI/CD survit à cet audit.

1. Pourquoi le SBOM est devenu obligatoire pour la défense

Quatre fils réglementaires ont convergé. L'Executive Order 14028 (mai 2021) a exigé que les fournisseurs de logiciels fédéraux fournissent des SBOM et a posé les bases des « éléments minimums » NTIA. NDAA Section 1655 (FY2023, raffiné par les amendements FY2026) a étendu les exigences SBOM aux achats défense, imposant que les primes-contractants DoD et leurs sous-traitants fournissent des SBOM pour tout logiciel livré au Département, avec des dispositions spécifiques sur les composants d'origine chinoise et les fournisseurs de nations adverses. NIS2 a appliqué une pression parallèle à travers la base de défense UE, exigeant une gestion documentée du risque chaîne d'approvisionnement pour les entités essentielles et importantes. NIST SP 800-218 — le Secure Software Development Framework (SSDF) — a codifié la génération de SBOM comme pratique attendue de tout fournisseur s'auto-attestant sous OMB M-22-18 et M-23-16.

L'effet pratique est qu'un fournisseur de logiciel défense sans outillage SBOM en 2026 n'est pas un fournisseur compétitif. Les RFP incluent des clauses SBOM. Les audits incluent des vérifications SBOM. Et un SBOM manquant est traité de la même manière qu'un rapport de test manquant — comme preuve que le processus d'ingénierie du fournisseur est incomplet. La bonne nouvelle pour les équipes d'ingénierie est que la génération de SBOM, une fois correctement instrumentée, est bon marché à maintenir. La mauvaise est que « correctement instrumentée » cache une longue liste de décisions architecturales, dont la plupart sont mal prises la première fois.

2. CycloneDX vs SPDX

Deux formats SBOM comptent : CycloneDX (originaire de l'OWASP, désormais standard Ecma) et SPDX (originaire de la Linux Foundation, ISO/IEC 5962:2021). Ils couvrent le même territoire conceptuel — composants, versions, licences, hashs, relations — mais les dialectes divergent sur des points qui comptent pour l'outillage.

CycloneDX est optimisé pour les cas d'usage sécurité : support VEX natif, champs vulnérabilité de première classe, JSON léger, intégration étroite avec l'écosystème OWASP (Dependency-Track, dependency-check). C'est le format que la plupart des équipes sécurité produisent par défaut. SPDX est optimisé pour les cas d'usage licence et provenance : langage d'expression de licence plus riche, antériorité plus longue dans les audits de conformité open-source, le tampon ISO que les équipes juridique et achats demandent dans les industries régulées.

Les clients défense demandent les deux. Les contrats alignés NDAA spécifient de plus en plus « SPDX 2.3 ou ultérieur, ou CycloneDX 1.5 ou ultérieur », laissant le choix du format au fournisseur — jusqu'à ce que l'outillage aval du client force l'un ou l'autre. Le motif pragmatique est la double émission : générer un SBOM CycloneDX dans la build pour l'outillage vulnérabilité interne, puis transformer en SPDX à la livraison via un convertisseur (les open-source cyclonedx-py, cdx2spdx, ou la chaîne d'outils SPDX). Traitez l'un comme source de vérité et l'autre comme artefact dérivé ; gardez les deux versionnés aux côtés du binaire.

3. Génération SBOM build-time vs post-build

Le plus grand déterminant unique de la crédibilité du SBOM est le moment où, dans le pipeline, le SBOM est produit. Il y a deux camps. Les scanners post-build (Trivy, Snyk, le graphe de dépendances natif GitHub en mode scan) ingèrent une image conteneur ou un binaire fini et reverse-engineerent ses composants. Les générateurs build-time (Syft câblé dans la build, cdxgen, outillage spécifique au langage comme cargo cyclonedx, mvn cyclonedx, npm sbom) observent le processus de build réel et émettent le SBOM depuis le graphe de dépendances résolu que la build a utilisé.

Seule la génération build-time est crédible à l'audit. La raison est simple : un scanner post-build identifie ce qu'il peut voir — il ne peut pas distinguer entre une bibliothèque statiquement liée dans le binaire et une bibliothèque tirée pour un outil build-time mais jamais livrée. Il ne peut pas voir les registres privés dont il n'a pas les identifiants. Il ne peut pas voir la génération de code à la compilation. Un relecteur demandant « comment savez-vous que ce SBOM est complet ? » obtient une réponse actionnable seulement quand le SBOM a été produit par la build elle-même, avec provenance traçable jusqu'aux lockfiles. Le scan post-build est un second avis utile. Ce n'est pas l'artefact primaire.

En pratique les équipes convergent sur une pile Syft pour les couches OS et conteneur, générateurs natifs au langage (cargo, npm, pip, mvn, go-licenses avec sortie CycloneDX) pour les composants source, cdxgen quand les dépôts polyglotes nécessitent une passe unique, et Trivy ou l'export SBOM natif de GitHub comme contre-vérification post-build. Le pipeline de build fusionne les sorties natives au langage en un seul document CycloneDX, le signe et l'attache à l'artefact publié.

4. Signature et attestation du SBOM

Un SBOM non signé n'est pas une preuve. Un relecteur ne peut pas vérifier qu'il a été produit par la build qui a produit le binaire ; il ne peut pas vérifier qu'il n'a pas été édité ; il ne peut pas prouver que l'environnement de build était de confiance. Le correctif est l'attestation — un énoncé signé, produit par le système de build, liant le SBOM à un hash d'artefact spécifique.

Les primitives dominantes sont sigstore/cosign pour la signature sans clé (certificats liés OIDC, log de transparence dans Rekor) et les attestations in-toto pour le format d'énoncé. Une attestation in-toto a trois parties : le sujet (le hash de l'artefact attesté), le type de prédicat (par ex. https://cyclonedx.org/bom, ou le type de provenance SLSA), et le corps du prédicat (le SBOM lui-même, ou la provenance de build). Cosign signe l'attestation, l'attache comme artefact OCI aux côtés de l'image conteneur, et pousse la signature vers le log de transparence Rekor.

Le framework SLSA (Supply-chain Levels for Software Artifacts) est le modèle de maturité que les clients défense référencent quand ils veulent un seul nombre pour ancrer leurs exigences. SLSA 1 signifie que la provenance existe. SLSA 2 signifie qu'elle est signée et que le service de build est hébergé. SLSA 3 signifie que la build est isolée et que la provenance n'est pas falsifiable par le projet lui-même. SLSA 4 signifie revue à deux parties et builds hermétiques et reproductibles. La plupart des contrats défense en 2026 demandent SLSA 3 comme plancher pour les logiciels livrés en environnements opérationnels ; SLSA 2 est acceptable pour l'outillage non déployé. SLSA 4 reste rare hors des charges à plus haute classification.

5. Couche de corrélation des vulnérabilités

Un SBOM est une liste de composants ; ce n'est pas, en soi, un rapport de vulnérabilités. La couche de corrélation joint le SBOM contre les bases de vulnérabilités (NVD, OSV, GitHub Advisory Database) pour produire une liste de vulnérabilités par artefact. C'est là que la plupart des équipes découvrent que 80 % des vulnérabilités rapportées dans leur SBOM ne sont pas exploitables dans leur contexte — la fonction vulnérable n'est jamais appelée, la configuration affectée n'est jamais activée, ou le chemin est inaccessible depuis toute surface externe.

La manière standardisée de communiquer cela est VEX (Vulnerability Exploitability eXchange). Un énoncé VEX déclare, pour un CVE spécifique contre une version produit spécifique, l'une de quatre valeurs de statut : not_affected, affected, fixed ou under_investigation, avec une justification (par ex. vulnerable_code_not_in_execute_path). CycloneDX supporte VEX nativement ; SPDX le supporte via le format compagnon CSAF (Common Security Advisory Framework). Un client défense relisant votre SBOM s'attend à voir des énoncés VEX expliquant les CVE ouverts — pas le silence.

Le flux opérationnel ressemble à : SBOM généré dans la build → scan de vulnérabilités contre OSV/NVD → triage dans un outil comme Dependency-Track → l'ingénieur dépose un énoncé VEX avec justification → VEX attaché comme attestation in-toto signée aux côtés du SBOM. L'auditeur du client voit une histoire cohérente pour chaque CVE.

Point clé : Un pipeline de défense qui livre des SBOM sans énoncés VEX noie le client dans le bruit. En six mois, le client cesse de lire les SBOM car il ne peut pas distinguer signal de fond. Le fournisseur qui livre SBOM + VEX obtient l'accréditation ; le fournisseur qui livre SBOM seul reçoit une demande de remédiation pour chaque CVE « high » dans un module Go transitif. Triez vos propres vulnérabilités — votre posture DevSecOps et zero-trust est jugée sur la qualité de votre corrélation, pas sur le nombre de CVE que vous remontez.

6. Logique de porte CI

Les SBOM et les énoncés VEX n'imposent l'hygiène de la chaîne d'approvisionnement que lorsque le pipeline bloque dessus. La porte se trouve entre « build réussie » et « artefact de release promu ». Les équipes modernes écrivent la porte comme une politique en Rego (Open Policy Agent) ou Kyverno, évaluée contre les entrées SBOM et VEX.

Une politique fonctionnelle impose quatre règles. Une : pas de CVE critique sans justification VEX. Deux : pas de composants depuis une liste noire de familles de licences (AGPL dans des livrables propriétaires, tout avec une clause d'origine contrôlée à l'export US). Trois : pas de composants depuis des registres de nations sanctionnées (c'est là que vit NDAA 1655 — paquets d'origine chinoise signalés automatiquement). Quatre : le SBOM doit être signé, la provenance de build doit revendiquer SLSA 3 ou supérieur, et l'entrée du log de transparence Rekor doit exister.

Les dérogations sont l'endroit où la plupart des politiques échouent en pratique. Une dérogation globale « ignorer ce CVE pour toujours » est le motif d'échec d'audit. Le motif qui survit à l'audit est la dérogation avec justification et expiration : le fichier de dérogation vit dans le dépôt, est revu en pull request, nomme le CVE et l'artefact, contient une justification écrite (les mêmes champs de justification VEX), et a une date d'expiration. Le pipeline accepte la dérogation uniquement tant qu'elle n'est pas expirée. Les auditeurs adorent ce motif car il produit une trace écrite des décisions de risque ; les ingénieurs le tolèrent car il s'agit d'un travail fini.

7. Livraison au client

Le SBOM n'est pas seulement un artefact de build — c'est un livrable contractuel. Les contrats défense en 2026 incluent régulièrement des clauses sur format SBOM, signature, mécanisme de livraison et cadence de mise à jour. La négociation de format se fait typiquement à la rédaction du contrat : le fournisseur propose CycloneDX 1.5 JSON, le client contre-propose SPDX 2.3 car son outil aval l'exige, et le fournisseur s'engage sur la double émission. La livraison se fait usuellement via un registre ou portail contrôlé par le client — jamais en pièce jointe email, ce que la politique de sécurité de l'information du client interdit.

L'obligation de mise à jour récurrente est la clause que la plupart des fournisseurs sous-estiment. Les contrats alignés NDAA exigent typiquement un SBOM mis à jour à chaque release de patch, à chaque drop de maintenance trimestriel, et dans les 72 heures de toute divulgation de CVE en portée. Si votre processus de release prend une semaine, vous ne pouvez pas tenir une horloge de 72 heures. Le correctif est de rendre l'émission de SBOM automatique à chaque release, y compris les releases de patch, pour que le SBOM soit toujours à jour avec le binaire que le client fait tourner. Les fournisseurs qui essaient de régénérer manuellement les SBOM après release finissent par expliquer des lacunes aux relecteurs d'accréditation — voir aussi comment les contraintes d'habilitation et de personnel affectent ce que votre équipe peut livrer.

8. Survivre à l'audit

Le relecteur d'accréditation arrive. Il pose trois questions. Montrez-moi le SBOM pour la version 2.4.1, que nous faisons tourner en production. Votre registre retourne le document CycloneDX signé avec une attestation in-toto pointant vers le hash du binaire que le client a installé. Montrez-moi les énoncés VEX pour chaque CVE « high » dans ce SBOM. Votre registre retourne le bundle VEX, avec justifications et dates. Montrez-moi comment vous sauriez, aujourd'hui, si un nouveau CVE était divulgué contre un composant de ce SBOM. Vous lui montrez le scan continu qui tourne contre le corpus de SBOM et le SLA de notification client.

Le pipeline qui répond proprement à ces trois questions est le pipeline qui survit. Le pipeline qui ne le peut pas — parce que le SBOM a été généré a posteriori, ou que les énoncés VEX vivent dans un tableur, ou que personne ne suit les divulgations CVE contre les SBOM publiés — est le pipeline qui perd le contrat au renouvellement. L'investissement est fini ; la conséquence de ne pas le faire ne l'est pas. Pour le cadrage plus large de la chaîne d'approvisionnement, voir notre vue d'ensemble SBOM dans le logiciel de défense, le guide complet de la cybersécurité défense, et l'approfondissement DevSecOps + zero trust qui se situe une couche au-dessus de ce travail de pipeline.