La génération de SBOM entre équipes d'ingénierie : une politique, chaque pipeline

Pourquoi des scanners par équipe ne font pas un programme SBOM

Lancez cinq outils sur le même produit et vous obtenez cinq SBOM. Les différences sont structurelles, ce ne sont pas des bugs :

• Des entrées différentes, lues à des moments différents. Un outil lit le lockfile, un autre l'arbre de dépendances installé, un autre l'image de conteneur, un autre le binaire. Chacun voit une partie différente du produit.
• Des noms différents pour la même chose. Un outil identifie les composants par package URL, un autre par CPE, un autre uniquement par nom de fichier. Deux SBOM qui décrivent la même bibliothèque ne peuvent pas être rapprochées sur une clé commune.
• Une profondeur différente. Certains ne listent que les dépendances directes, d'autres l'arbre transitif complet, et certains listent aussi les outils de build. Pourquoi les générateurs ne s'accordent pas sur le même dépôt est montré dans générateurs de SBOM open source.
• Certains outils répondent à une autre question. Les scanners de vulnérabilités d'infrastructure signalent ce qui est installé sur les hôtes en fonctionnement. C'est utile pour l'exploitation, et ce n'est pas une description du produit que vous livrez.

La conséquence : vous ne pouvez pas fusionner, dédupliquer ni comparer des SBOM d'un produit à l'autre, et vous ne pouvez pas montrer à un auditeur un processus unique, parce qu'il n'y en a pas.

Méthode	Entrée lue	Quand	Ce qu'elle manque	Identifiant typique
Scanner de lockfile ou de manifeste	Lockfiles et manifestes du checkout	Avant ou après le build	Tout ce qu'aucun lockfile ne liste : hooks d'installation, téléchargements par les scripts de build, images de base	Package URL
Scanner d'images de conteneur	Bases de données de paquets et fichiers de l'image	Après le build	Outils servant uniquement au build, code compilé dans le binaire, tout ce qui n'a pas d'enregistrement de paquet	Package URL pour les paquets du système et des langages
Scanner de binaires ou de firmware	Chaînes et signatures dans le binaire	Après le build	La certitude : versions et composants sont déduits	CPE ou nom déduit
Scanner de vulnérabilités des hôtes	Logiciels installés sur les serveurs en fonctionnement	En exploitation	Le produit tel que livré aux clients	CPE ou nom de produit de l'éditeur
Enregistrement pendant le build	Ce que le build de release a récupéré	Pendant le build	Les logiciels que vous n'avez pas construits ; ce qu'il n'a pas pu voir est signalé comme incomplet	Package URL

La politique SBOM : ce qu'il faut standardiser

Standardisez la SBOM, pas le scanner. La politique fixe le résultat et le processus ; chaque pipeline s'y conforme avec le meilleur générateur qu'il peut exécuter. Chaque ligne ci-dessous est vérifiable.

Exigence	La règle	Pourquoi	Comment la vérifier
Périmètre	Chaque release de produit livrée à un client, firmware et images de conteneur compris. Outils internes facultatifs.	Les clients et les régulateurs posent des questions sur ce que vous livrez.	Chaque release du registre des releases a une SBOM.
Format et version	Un format principal, CycloneDX ou SPDX, avec une version minimale. Accepter l'autre sur demande.	Un format signifie un parseur, un validateur et un lieu de stockage. La BSI TR-03183-2 exige CycloneDX 1.6 ou plus récent ou SPDX 3.0.1 ou plus récent, un plancher raisonnable pour les clients de l'UE.	La validation de schéma indique le format et la version.
Champs minimaux	Une package URL sur chaque composant qui en a une, un CPE seulement là où il n'en existe pas, fournisseur, version, licence déclarée, relations de dépendance, nom et version de l'outil, horodatage et contexte de génération.	C'est ce qu'utilisent la correspondance, la revue des licences et les audits. Alignez-les sur les éléments minimaux de qu'est-ce qu'une SBOM.	Un contrôle des champs dans le pipeline compte les valeurs manquantes.
Moment de génération	Dans le build CI qui produit la release, à chaque fois. Pas au moment de l'audit, pas sur un ordinateur portable.	Un nouveau build n'est pas le même build ; voir SBOM générées au build.	L'identifiant de build de la SBOM correspond à celui de la release.
Profondeur	L'arbre transitif complet, pas seulement le premier niveau.	Le minimum du CRA, ce sont les dépendances de premier niveau ; les vulnérabilités et les clients vont plus loin.	Des relations de dépendance existent sous le premier niveau.
Lieu de stockage	Avec l'artefact de release, récupérable par produit et par version.	Une SBOM que personne ne retrouve quand un avis de sécurité tombe n'est pas une preuve.	Récupérez la SBOM d'une release prise au hasard par produit et par version.
Conservation	Au moins la période de support du produit, plus la durée de conservation de la documentation exigée par vos réglementations.	Le CRA fixe une durée de conservation pour la documentation technique, et la SBOM en fait partie.	Comparez la durée de la politique avec la conservation de chaque outil.
Validation	Chaque SBOM est validée par rapport au schéma dans le pipeline ; une SBOM invalide fait échouer le build ou le contrôle de release.	Les SBOM invalides échouent sans bruit dans les outils du client.	Le journal du contrôle de release montre une étape de validation.
Responsabilité	L'équipe produit est responsable de la génération ; la sécurité produit est responsable de la politique, des règles de validation et du reporting de couverture.	La génération a besoin du responsable du pipeline ; la cohérence a besoin d'un seul responsable des règles.	Chaque pipeline désigne un responsable.
Exceptions	Un registre d'exceptions nominatives et limitées dans le temps : équipe, motif, date de fin.	La politique résiste aux équipes qui ne peuvent pas encore s'y conformer.	Aucune exception n'a dépassé sa date de fin.

La checklist de bonnes pratiques SBOM couvre les règles d'une SBOM individuelle ; cette politique est la couche au-dessus. Chaque équipe déclare comment son pipeline respecte la politique, dans un fichier placé à côté du pipeline :

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Générer dans le build, pas après coup équipe par équipe

La génération pendant le build est le standard à viser. Elle décrit le build qui a été livré, elle inclut les dépendances cachées qu'aucun lockfile ne liste, et un seul mécanisme produit des SBOM de même forme pour chaque équipe de ce pipeline. La différence s'explique le plus simplement avec une cuisine : un scanner goûte la soupe et devine la recette ; un enregistreur observe ce qui entre dans la cuisine.

Un scanner reste le bon outil pour les images que vous n'avez pas construites, pour les binaires tiers et pour les produits historiques sans CI. Indiquez-le dans la politique et consignez le contexte de génération, afin que le lecteur sache ce que chaque SBOM a vu.

Situation	Méthode de génération	Contexte de génération à consigner
Release construite dans une CI que vous maîtrisez	Enregistrer le build, ou exécuter un générateur dans le job de release	« Enregistré pendant le build » ou « après l'installation, à partir des fichiers »
Image de conteneur construite dans la CI	Enregistrer le build de l'image ; scanner le résultat pour ses paquets système si l'enregistreur ne les couvre pas	Identifiant de build et digest de l'image
Image ou appliance tierce	Scanner d'images, plus la SBOM de l'éditeur s'il y en a une	« Résultat de scan, non construit par nous »
Binaire d'un fournisseur	Demander la SBOM de build du fournisseur ; l'analyse binaire comme vérification	Fournisseur, version, mode d'obtention
Produit historique sans pipeline	Scanner l'artefact livré ; planifier un pipeline	« Résultat de scan » et une exception avec une date de fin

CI mixte : GitHub Actions, GitLab et Jenkins dans une même organisation

La politique est indépendante de la CI par conception : elle définit le résultat, si bien qu'un pipeline GitLab ou Jenkins peut s'y conformer avec une étape de générateur, et qu'un pipeline GitHub Actions peut utiliser l'enregistrement pendant le build. Règles pour une étape de générateur :

• Exécutez-la dans le job de release, après l'étape d'installation, pas dans un job séparé qui réinstalle.
• Épinglez la version du générateur, et épinglez les actions CI sur un commit, pas sur un tag. Pourquoi cela compte en particulier pour les scanners est expliqué dans générateurs de SBOM open source.
• Consignez le contexte de génération comme « après l'installation, à partir des fichiers », afin que les lecteurs sachent ce qu'elle a vu.
• Validez le résultat par rapport au même schéma que tous les autres pipelines.

Les générateurs open source comme Syft, Trivy et cdxgen savent tous écrire du CycloneDX et du SPDX : la règle de format n'impose donc pas le choix d'un outil. Pour les comparer, consultez comparatif des outils SBOM.

CRACI prend aujourd'hui en charge GitHub Actions ; GitLab CI et Jenkins sont sur la feuille de route, sans date. La conséquence pour le déploiement : commencez l'enregistrement pendant le build là où GitHub Actions est utilisé, conservez les étapes de générateur ailleurs, et suivez les deux dans le même rapport de couverture.

Quand un client demande une version de format précise

Un client demande CycloneDX 1.6, et vos outils produisent du 1.7. Cela arrive parce que son outil d'ingestion ou sa propre politique est figé sur une version ; le plancher du BSI est 1.6, c'est pourquoi les clients de l'UE la citent souvent. Vos options :

1. Demandez si la version plus récente est acceptée. Elle l'est souvent.
2. Convertissez avec la CLI CycloneDX, puis validez par rapport à la version cible, et vérifiez ce qui a été perdu : les champs qui n'existent que dans la spécification plus récente sont supprimés.
3. Pour une demande SPDX, la même CLI convertit vers et depuis SPDX JSON 2.3. Sa documentation avertit que la conversion entre SPDX et CycloneDX « peut entraîner la perte de certaines informations ».

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

Le validateur vérifie par rapport à CycloneDX 1.7, sauf si vous passez --input-version. Règle de la politique : conservez la SBOM d'origine comme document de référence. Une copie convertie est une livraison dérivée ; stockez la dérivation (outil, version, date) avec elle. Pour en savoir plus sur la réponse à ces demandes, voir demandes de SBOM des clients, et sur les deux formats, CycloneDX vs SPDX.

Les données de licence pour le service juridique

La même SBOM peut servir au service juridique, si la politique exige les bons champs. Le service juridique a besoin de la licence de chaque composant, de la différence entre une licence déclarée (ce que dit le paquet) et une licence conclue (ce que quelqu'un a vérifié), des obligations copyleft, et d'une liste des composants sans licence. CycloneDX 1.6 marque les licences comme déclarées ou conclues, et SPDX a des champs distincts pour les deux.

• Exigez des identifiants ou des expressions de licence SPDX, comme MIT ou Apache-2.0 OR MIT.
• Signalez NOASSERTION et les licences manquantes pour revue. En SPDX, NOASSERTION signifie qu'aucune détermination n'a été faite ou qu'aucune information n'a été fournie ; ce n'est pas une licence.
• Transmettez les licences copyleft au service juridique avant la release, pas après.

Une SBOM contient les licences déclarées. Une revue de conformité des licences, avec licences conclues, mentions et obligations, relève du travail juridique ou d'un outil spécialisé ; voir conformité des licences open source.

Le déploiement, équipe par équipe

Phase	Responsable	Critère de sortie	Obstacle typique
1. Inventaire : produits, pipelines, systèmes CI et générateurs actuels, une ligne par pipeline de release	Sécurité produit	Chaque produit livré a une ligne	Personne ne sait quel pipeline construit une release
2. Publier la politique avec le registre des exceptions	Sécurité produit	Politique approuvée et publiée	Débat sur l'outil à imposer (la politique n'en impose aucun)
3. Piloter avec une ou deux équipes qui ont une raison : une demande client, une échéance, un produit que l'outil actuel ne sait pas traiter	Équipes pilotes	Les releases pilotes sont livrées avec des SBOM conformes	Les équipes sans raison pressante la relèguent au second plan
4. Ajouter des contrôles de validation dans les pipelines pilotes	Équipes pilotes	Une SBOM invalide fait échouer la release	La crainte de bloquer les releases ; commencer par un avertissement
5. Étendre par système CI ; ne retirer un scanner d'équipe que lorsque son remplaçant respecte la politique	Équipes produit	Objectif de couverture atteint par système CI	Des pipelines sans responsable
6. Rendre compte de la couverture chaque mois	Sécurité produit	Le rapport est remis à la direction chaque mois	Des indicateurs calculés à la main

Le tableur d'inventaire de la phase 1 devrait être le dernier ; l'abandon des tableurs est traité dans automatisation des SBOM. Un produit basé sur Yocto est un pilote fréquent, car les scanners généralistes peinent à le traiter ; voir pourquoi les scanners SBOM passent à côté des builds Yocto.

Mesurer la couverture

Les chiffres que demandent la direction et les auditeurs, chacun défini comme un ratio :

• Couverture des releases : releases livrées avec une SBOM conforme à la politique ÷ releases livrées.
• Couverture des produits : produits ayant au moins une SBOM conforme dans la période de support en cours ÷ produits sous support.
• Taux de validation réussie : SBOM qui passent la validation ÷ SBOM générées.
• Couverture des identifiants : composants avec une package URL (ou un CPE) ÷ composants.
• Couverture des licences : composants avec une licence déclarée ÷ composants.
• Complétude : SBOM dont le générateur indique qu'elles sont complètes ÷ SBOM. Possible uniquement là où l'outil le signale.
• Délai jusqu'à la SBOM : temps écoulé entre la release et la disponibilité de la SBOM.

Un exemple de rapport mensuel (chiffres à titre d'illustration) :

Indicateur	Pipelines GitHub Actions	Pipelines GitLab et Jenkins	Total
Couverture des releases	46 / 48	19 / 27	65 / 75
Taux de validation réussie	100%	92%	97%
Couverture des identifiants	99%	88%	95%
Exceptions ouvertes	1	4	5

Comme preuve pour un régulateur ou un auditeur, l'ensemble se compose de la politique, du registre des exceptions, du rapport de couverture et de quelques SBOM d'exemple. Il montre un processus unique, appliqué et mesuré. Pour le volet CRA, consultez le guide du CRA.

La place de CRACI

Pour les pipelines GitHub Actions, CRACI est le runner : vous définissez runs-on: craci, et chaque job obtient une SBOM enregistrée sans étape de générateur. Chaque SBOM porte un état de complétude, les dépendances transitives, une package URL par paquet et la licence déclarée de chaque composant, et s'exporte en CycloneDX ou en SPDX. Des règles de politique de licence peuvent bloquer un build, les SBOM surveillées sont réévaluées en continu, et l'historique des builds montre quels builds contenaient une dépendance vulnérable. Ces équipes satisfont ainsi par défaut les lignes « générée dans le build de release », « identifiant » et « licence » de la politique. Des SBOM tierces peuvent être ajoutées, de sorte que les composants achetés sont surveillés aux côtés de vos builds.

Voir la génération de SBOM avec CRACI et les SBOM dans GitHub Actions.

Quand CRACI n'est pas la réponse

• Équipes sur GitLab CI ou Jenkins : pas aujourd'hui, c'est sur la feuille de route. Utilisez une étape de générateur conforme à la politique.
• GitHub Enterprise Server : non pris en charge aujourd'hui.
• Scan d'infrastructure et d'hôtes, c'est-à-dire ce qui est installé sur les serveurs et les erreurs de configuration : un autre métier ; conservez ces outils.
• Analyse de binaires ou de firmware d'images de fournisseurs que vous ne construisez pas : CRACI enregistre les builds et ne scanne pas les binaires.
• Conservation longue : CRACI conserve les données de build 180 jours par défaut, avec une conservation personnalisée sur Enterprise. Si votre politique exige des SBOM plus longtemps, exportez-les vers votre propre stockage.

Génération de SBOM entre équipes : questions fréquentes

Comment standardiser la génération de SBOM entre des équipes qui utilisent des outils différents ?

Standardisez le résultat, pas l'outil. Rédigez une politique qui fixe le format et la version, les champs minimaux, le moment de génération de la SBOM, son lieu de stockage, sa durée de conservation et qui la valide. Laissez chaque pipeline s'y conformer avec le meilleur générateur qu'il peut exécuter, et mesurez la couverture par rapport à la politique.

Que doit contenir une politique SBOM ?

Le périmètre, le format et la version minimale, les champs minimaux (package URL, fournisseur, version, licence déclarée, dépendances, outil, horodatage, contexte de génération), la génération dans le build de release, la profondeur transitive complète, le stockage avec la release, la conservation, la validation dans le pipeline, la responsabilité, et un registre d'exceptions limitées dans le temps.

Chaque équipe doit-elle utiliser son propre scanner, ou les SBOM doivent-elles venir du build ?

Du build, là où c'est possible. Une SBOM générée au build décrit le build qui a été livré et donne à chaque équipe de ce pipeline des SBOM de même forme. Gardez les scanners pour ce que vous n'avez pas construit : images tierces, binaires de fournisseurs et produits historiques sans pipeline.

Un client veut notre SBOM dans une version plus ancienne de CycloneDX. Que faire ?

Demandez d'abord si la version plus récente est acceptée. Sinon, convertissez une copie avec la CLI CycloneDX (cyclonedx convert avec --output-version v1_6), validez-la par rapport à cette version, et vérifiez quels champs ont été supprimés. Conservez l'original comme document de référence et stockez la façon dont la copie a été dérivée.

Comment transmettre les données de licence de nos SBOM au service juridique ?

Exigez dans la politique des identifiants ou des expressions de licence SPDX, signalez NOASSERTION et les licences manquantes pour revue, et transmettez les licences copyleft au service juridique avant la release. La SBOM contient les licences déclarées ; les licences conclues, les mentions et les obligations nécessitent une revue des licences.

Comment mesurer la couverture SBOM sur l'ensemble des produits ?

Sous forme de ratios : releases livrées avec une SBOM conforme, produits sous support avec une SBOM conforme, taux de validation réussie, composants avec une package URL, composants avec une licence déclarée, SBOM complètes là où l'outil le signale, et délai entre la release et la SBOM. Rendez-en compte chaque mois par système CI.

Quelles preuves faut-il pour montrer à un auditeur que la génération de SBOM est cohérente ?

La politique, le registre des exceptions, le rapport de couverture mensuel et quelques SBOM d'exemple avec leur contexte de génération. Ensemble, ils montrent un processus unique, appliqué à chaque release et mesuré, ce que vérifie un auditeur ou un client.