Générer un SBOM
Le principe
Le SBOM se produit au plus près de l’artefact, dans le pipeline qui le fabrique, jamais à la main a posteriori. Un SBOM rédigé par un humain est faux le jour où il est écrit et obsolète le lendemain.
Les cinq méthodes
| Méthode | Ce qu’elle voit | Angle mort |
|---|---|---|
| Depuis les manifestes de dépendances | Les dépendances déclarées et résolues | Ce qui n’est pas déclaré : code vendorisé, liaison statique |
| Depuis l’image de conteneur | Les paquets système de l’image de base et l’application | Ce qui est compilé dans un binaire |
| Depuis le binaire compilé | Les bibliothèques liées statiquement | Précision variable, dépend des métadonnées laissées par le compilateur |
| Depuis le système de fichiers ou le micrologiciel | Le contenu réel d’une image embarquée | Coûteux, outillage spécialisé |
| Depuis l’exécution | Ce qui est réellement chargé en mémoire | Ne voit que les chemins exercés |
Ces méthodes ne s’excluent pas : elles se combinent. Un pipeline mature produit un Build SBOM depuis les manifestes et un Analyzed SBOM depuis l’artefact, puis compare les deux.
Les familles d’outils
Les fiches détaillées figurent dans Générateurs. En synthèse :
| Famille | Rôle | Représentants |
|---|---|---|
| Générateurs génériques | Produire l’inventaire, multi-écosystèmes | Syft, cdxgen |
| Scanners tout-en-un | Générer et détecter les vulnérabilités en une passe | Trivy |
| Moteurs de détection | Consommer un SBOM et le corréler | Grype, osv-scanner |
| Outils orientés licences | Détecter les licences par analyse de fichiers | ScanCode, OSS Review Toolkit |
| Plugins natifs de chaîne de build | Produire l’inventaire depuis le graphe de résolution réel | CycloneDX Maven/Gradle, npm sbom, équivalents .NET, Rust, Go |
Matrice de choix par contexte
| Contexte | Recommandation | Pourquoi |
|---|---|---|
| Application Java, .NET, Node, Python, Ruby | Plugin natif de la chaîne de build, complété par un générateur générique sur l’artefact | Le plugin voit le graphe de résolution réel, avec les arbitrages de versions |
| Application Go ou Rust | Générateur générique sur le binaire | Les métadonnées de build y sont présentes |
| Application C / C++ | Générateur sur le binaire et sur le système de construction | La liaison statique rend les manifestes insuffisants |
| Image de conteneur | Générateur sur l’image complète | Capte l’image de base |
| Micrologiciel embarqué | Outillage spécialisé, et exigence de SBOM auprès du fournisseur de plateforme | Peu d’outils généralistes couvrent ce cas |
| Monorepo multi-artefacts | Un SBOM par artefact publiable, pas un pour le dépôt | Le SBOM décrit un artefact livré |
Le piège de l’outillage flottant
Deux outils différents produisent deux SBOM différents pour le même artefact : périmètre de détection, granularité, normalisation des identifiants et gestion des dépendances de test varient. C’est normal, et ce n’est un problème que si l’outillage change sans qu’on le sache.
Règle. Figer l’outillage par famille de produits, documenter le choix, versionner la configuration, et traiter tout changement d’outil ou de version majeure comme un événement : recalcul d’une référence, comparaison, note d’explication.
Sans cette discipline, la comparabilité dans le temps est perdue et les écarts entre deux versions deviennent ininterprétables — ce qui vide le dispositif de sa valeur pour le dossier technique.
Ce qui doit sortir du pipeline
Pour chaque artefact publiable :
- un Build SBOM au format pivot, version fixée ;
- un Analyzed SBOM de contrôle croisé ;
- un score de qualité, avec échec de la construction sous le seuil ;
- une signature et une attestation de provenance ;
- une publication vers la plateforme de pilotage ;
- un archivage avec indexation par empreinte.
Le détail figure dans Intégration CI/CD.
Ce qu’il faut documenter
Une fiche par famille de produits : outils utilisés et versions, commandes exactes, format et version de sortie, périmètre couvert, exclusions volontaires et leur motif, seuils de qualité, responsable. Cette fiche est une pièce du dossier technique, parce qu’elle explique comment le SBOM a été produit — information que l’annexe VII attend au titre des processus.