Bonnes pratiques SBOM

Générer les SBOM

1. Générez en CI, à chaque release

Une SBOM faite à la main est périmée avant que quiconque ne la lise. Faites-en une étape du pipeline qui construit la release, ou utilisez un runner qui en produit une sans aucune étape, pour qu'aucune release ne parte sans elle. Pour GitHub Actions, voir comment générer une SBOM dans GitHub Actions.

2. Décrivez le build qui a été livré

Les builds ne sont pas reproductibles par défaut. Construire deux fois le même commit ne garantit pas les mêmes dépendances, car les versions sont résolues au moment du build et les étapes peuvent varier. Une SBOM issue d'un ordinateur portable ou d'un scan ultérieur décrit un build similaire, pas celui que vous avez livré. Seule une SBOM issue du build CI qui a produit la release prouve ce qu'elle contient. Consultez les SBOM générées au build.

3. Couvrez plus que le lockfile

Un lockfile n'est pas un enregistrement de ce qui a été livré. Les scripts d'installation téléchargent du code, les scripts de build Rust récupèrent des fichiers, et les builds de conteneurs apportent une image de base avec ses propres paquets de système d'exploitation. Décidez ce que la SBOM doit couvrir, puis testez-la : cherchez dans votre SBOM un paquet de votre image de base et un outil de build.

4. Incluez les dépendances transitives et les relations

Les vulnérabilités se trouvent généralement sous vos dépendances directes. Une liste à plat montre qu'un composant est là, mais pas ce qu'il faut mettre à niveau. Conservez le graphe de dépendances dans la SBOM, pour qu'un résultat s'accompagne du paquet qui l'entraîne.

5. Indiquez ce que vous n'avez pas pu voir

Les 2026 Minimum Elements demandent aux auteurs de SBOM d'identifier explicitement les informations inconnues. Une SBOM partielle qui le dit vaut plus qu'une SBOM partielle qui paraît terminée. Enregistrez aussi l'outil, sa version et le contexte de génération, pour qu'un lecteur puisse juger ce que couvre le fichier.

Conserver les SBOM

6. Conservez une SBOM par release, liée à l'artefact

Quand un client sur une ancienne version demande s'il est exposé, il vous faut la SBOM de cette version plutôt que la plus récente. Stockez chaque SBOM avec le build et l'artefact qu'elle décrit, et décidez de la durée de conservation en fonction de la durée de support de la release. Les hachages présents dans la SBOM aident à la lier à l'artefact exact.

7. Choisissez un format et un identifiant, et tenez-vous-y

Standardisez sur CycloneDX ou SPDX, une version de format et les package URL comme identifiants. L'essentiel de la difficulté à comparer des SBOM vient d'outils qui nomment différemment la même chose. Validez chaque fichier dans le pipeline, et demandez le même format à vos fournisseurs.

Utiliser les SBOM

8. Surveillez ce qui a été livré, pas seulement ce que vous construisez

Le moment où une SBOM a le plus de valeur est le lendemain d'un avis de sécurité visant un logiciel publié l'an dernier. Un scan dans une pull request ne peut alors rien pour vous. Réévaluez les SBOM stockées des releases prises en charge par rapport aux nouvelles données de vulnérabilité, pour qu'un nouvel avis de sécurité se transforme en liste de releases concernées.

9. Transmettez les résultats à un responsable et consignez la décision

Une SBOM avec un millier de vulnérabilités détectées est une liste, pas un plan. Classez les résultats avec une méthode de priorisation, envoyez chacun à l'équipe responsable de la correction, et consignez pourquoi vous n'avez pas agi sur le reste, par exemple dans une déclaration VEX.

10. Utilisez la même SBOM pour les clients et les auditeurs

Clients, auditeurs et régulateurs posent des questions similaires. Répondez-y à partir de la SBOM qu'utilisent vos propres équipes, plutôt que de produire un document distinct qui s'en écarte peu à peu. Si vous partagez des SBOM, décidez qui peut les voir et comment ces personnes reçoivent les mises à jour, et demandez la même chose à vos fournisseurs.

Erreurs courantes

Erreur	Pourquoi c'est un problème	À faire plutôt
Une SBOM par dépôt	Elle ne dit rien d'une release précise	Une par release, liée à l'artefact
Ne générer qu'au moment de l'audit	Elle décrit un build que personne n'a livré	À chaque release, en CI
Considérer la SBOM comme terminée	De nouveaux avis de sécurité arrivent après la release	Continuer à la surveiller
Comparer uniquement le nombre de composants	Plus n'est pas mieux si les entrées sont fausses	Vérifier des paquets précis dont vous connaissez la présence

Comment CRACI s'en charge

CRACI couvre les pratiques qui dépendent du build. C'est un runner GitHub Actions qui enregistre chaque paquet récupéré par chaque job, y compris les dépendances cachées qu'aucun lockfile ne liste, dans une SBOM CycloneDX ou SPDX dotée d'un état de complétude. Il conserve chaque build passé et sa SBOM pendant la durée de conservation de votre offre, réévalue les SBOM surveillées à mesure que de nouvelles vulnérabilités apparaissent, et montre quels builds contenaient une dépendance vulnérable. Les équipes sécurité trient les résultats et les transmettent aux équipes chargées de la correction. Consultez la gestion des SBOM pour comparer les outils de gestion, ou les meilleurs outils SBOM.

Bonnes pratiques SBOM : questions fréquentes

Quand faut-il générer une SBOM ?

Pendant le build CI qui produit la release, à chaque fois. Une SBOM produite à ce moment décrit ce qui a été livré, alors qu'une SBOM produite plus tard décrit un nouveau build ou un scan.

Combien de temps faut-il conserver les SBOM ?

Au moins aussi longtemps que vous prenez en charge la release, plus ce qu'exigent vos régulateurs ou vos contrats. Il vous faut la SBOM d'une ancienne version pour savoir si ses utilisateurs sont touchés par une nouvelle vulnérabilité.

Faut-il automatiser les SBOM ?

Oui. Une SBOM manuelle est périmée dès la release suivante. Générez les SBOM dans le pipeline, validez-les à cet endroit et stockez-les avec le build.

Faut-il partager votre SBOM avec vos clients ?

Partagez-la quand un client ou un régulateur la demande, à des conditions qui vous conviennent. Une SBOM révèle ce que vous utilisez : de nombreuses entreprises la partagent donc sur demande plutôt que de la publier.

Quelle est la différence entre une SBOM et la gestion des SBOM ?

Une SBOM est un fichier. La gestion des SBOM est le travail continu qui consiste à stocker les SBOM par release, à les surveiller pour détecter de nouvelles vulnérabilités et à les mettre à la disposition de ceux qui en ont besoin.