Les six types de SBOM
« Le » SBOM n’existe pas. Il y en a plusieurs, produits à des moments différents du cycle de vie, et ils ne disent pas la même chose. Confondre deux types est une source récurrente d’écarts inexpliqués entre équipes.
| Type | Produit quand | Répond à | Fiabilité |
|---|---|---|---|
| Design | Avant développement | Ce qu’on prévoit d’utiliser | Intention |
| Source | Depuis le code et les manifestes | Ce qui est déclaré | Manque le non déclaré |
| Build | Pendant la construction | Ce qui est effectivement assemblé | La plus fidèle pour le CRA |
| Analyzed | Après coup, sur l’artefact | Ce qu’on retrouve dans le binaire ou l’image | Dépend de la qualité de l’analyse |
| Deployed | Sur l’environnement cible | Ce qui est installé, configuration comprise | Inclut l’environnement |
| Runtime | Pendant l’exécution | Ce qui est réellement chargé en mémoire | Réduit le bruit, manque les chemins non exercés |
Ce que chacun apporte
Design. Utile en amont pour instruire la diligence avant d’adopter un composant, et pour détecter tôt une licence interdite. Sans valeur probante.
Source. Rapide, produit à partir des manifestes de dépendances. Son angle mort est structurel : il ne voit pas ce qui n’est pas déclaré — code vendorisé, bibliothèque copiée, dépendance système.
Build. Produit par la chaîne de construction, il voit le graphe de résolution réel, avec les versions effectivement retenues après arbitrage des contraintes. C’est celui qui doit être versé au dossier technique.
Analyzed. Obtenu en analysant l’artefact fini — binaire, image de conteneur, image de micrologiciel. Il capte ce que le build a manqué : bibliothèques liées statiquement, paquets de l’image de base, fichiers copiés. Sert de contrôle croisé du build.
Deployed. Ajoute l’environnement d’exécution : système hôte, configuration, variables. Utile pour la sécurité opérationnelle, moins pour la conformité produit.
Runtime. Ce qui est effectivement chargé. Permet de réduire le bruit : un composant présent mais jamais chargé n’a pas la même criticité qu’un composant sur le chemin d’exécution. À manier avec prudence : un chemin non exercé pendant l’observation reste un chemin atteignable.
La doctrine retenue
- Le Build SBOM est le SBOM de référence, signé, archivé et versé au dossier technique.
- L’Analyzed SBOM est produit systématiquement en contrôle croisé. Tout écart significatif entre les deux est un défaut à instruire, pas une curiosité : il révèle généralement du code vendorisé ou une dépendance non déclarée.
- Le Runtime SBOM sert à la priorisation, jamais à la conformité.
- Les types Design et Deployed sont produits au cas par cas, selon le besoin.
L’écart build / analyzed
C’est l’indicateur de qualité le plus révélateur du dispositif. Les causes typiques d’écart :
- liaison statique : une bibliothèque C compilée dans le binaire n’apparaît pas au manifeste ;
- code vendorisé : des sources tierces copiées dans votre dépôt ;
- image de base : les paquets système du conteneur, absents des manifestes applicatifs ;
- artefacts multi-langages : un composant Python appelant une bibliothèque native ;
- génération de code : du code produit à la construction, embarquant des dépendances.
Chacune de ces causes est traitée dans Qualité et complétude.