Sécurité
SBOM : Software Bill of Materials. « Nomenclature logicielle », par analogie avec la liste des ingrédients imprimée au dos d'un paquet de biscuits.
Contenu : La liste des composants d'un logiciel, bibliothèques et dépendances transitives comprises, avec versions, fournisseurs, empreintes et licences. Les formats les plus courants sont SPDX (Software Package Data Exchange) et CycloneDX.
À quoi ça sert : Quand une faille est publiée dans une bibliothèque, on sait en une requête quels produits l'embarquent, au lieu de lancer une enquête dans tous les dépôts.
Bien la produire : Elle se génère automatiquement dans la chaîne CI, à partir de l'artefact réellement livré, puis se signe et s'archive avec lui. Une nomenclature rédigée à la main a la même valeur scientifique qu'un horoscope, avec moins de lecteurs.
Limites : Elle dit ce qui est présent, pas si c'est vulnérable ni si c'est exploitable. Sa variante cryptographique, le CBOM, recense les algorithmes et les clés.
Ce qui arrive si on s'en passe
Sans nomenclature logicielle, l'annonce d'une faille dans une bibliothèque répandue déclenche une chasse au trésor : fouiller chaque dépôt, chaque image de conteneur, chaque logiciel acheté, en espérant n'en oublier aucun. Les dépendances transitives, embarquées par d'autres dépendances, échappent presque toujours à ce recensement manuel ; ce sont elles qui restent exposées le plus longtemps. Le délai entre la publication d'un correctif et son déploiement s'allonge, et c'est précisément la fenêtre qu'exploitent les attaquants. Une nomenclature non générée à la construction, non signée ou non mise à jour à chaque livraison produit le même effet avec une fausse assurance en prime : la liste rassure, le logiciel réel contient autre chose.
Explication de la marmotte
Un logiciel moderne est rarement écrit de zéro : il assemble des centaines de briques écrites par d'autres, comme un gâteau fait avec des ingrédients achetés tout prêts. Cette liste recense toutes ces briques, avec leur version exacte. Le jour où l'on apprend qu'une brique est défectueuse, comme un lot de farine rappelé par le fabricant, il suffit de consulter les listes pour savoir en quelques minutes quels logiciels sont concernés, au lieu de tout démonter pour vérifier.
Où ce terme est utilisé
- SBOM pour inventorier les composants réellement exécutés (37 occurrences)
- Générer un SBOM CycloneDX dans un pipeline CI (24 occurrences)
- SLSA : niveaux Build, provenance in-toto et vérification (8 occurrences)
- Images Docker de base et confiance héritée (6 occurrences)
- L'attaque de la chaîne d'approvisionnement logicielle en une page (6 occurrences)
- La chaîne d'approvisionnement logicielle (6 occurrences)
- Attaques supply chain et protection des dépendances (5 occurrences)
- PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA (5 occurrences)
- Gérer les risques tiers et la chaîne logicielle (4 occurrences)
- AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPD (3 occurrences)
