Les SBOM en tant qu'infrastructure de risque vivante

Temps de lecture : 5 minutes • Mars 2026

Le Software Bill of Materials (SBOM) s’est imposé ces dernières années comme un élément incontournable de la transparence logicielle. Comme l’a rappelé Allan Friedman lors du SCANOSS Workshop à Athènes, « SBOM n’est plus controversé » : il est désormais soutenu par les gouvernements, intégré dans les standards sectoriels et mentionné dans les cadres réglementaires à travers le monde.

Cependant, cette adoption massive pourrait paradoxalement en réduire l’impact. Friedman met en garde : le SBOM risque de devenir « une case à cocher » sans véritable utilité opérationnelle. C’est précisément ce défi que l’industrie doit relever : faire évoluer le SBOM d’un artefact statique de conformité vers une infrastructure dynamique d’analyse et de gestion des risques.

Bien que la base soit posée, avec les NTIA Minimum Elements ou les directives renforcées de la CISA, la conformité réglementaire ne garantit pas la maturité opérationnelle. Les organisations doivent dépasser la simple production d’un fichier SBOM pour créer une source fiable, contextualisée et exploitable par les équipes de sécurité, d’ingénierie et de procurement.

1. Une première fracture : définir ce que couvre réellement un SBOM

Entre firmware, composants runtime, services cloud, appels tiers ou couches système, la portée d’un SBOM peut varier drastiquement.
Sans contexte cohérent de génération, il est possible que deux SBOMs d’un même produit diffèrent fortement, faussant les analyses de risques ou les comparaisons entre versions.


2. Une seconde fracture : qualité et harmonisation des données

Les retours du Plugfest organisé par Carnegie Mellon soulignent un point central :
les outils SBOM produisent encore des résultats divergents pour un même logiciel. Selon Friedman, il faut parfois des analyses statistiques avancées pour distinguer le signal du bruit, preuve que le secteur manque encore d’harmonisation.

Des efforts existent : meilleure interopérabilité SPDX/CycloneDX, traducteurs, prise en charge multiformat, mais le véritable facteur différenciant réside dans :

• la précision des identifiants,
• l’exactitude des graphes de dépendances,
• la reproductibilité des hachages,
• et la transparence complète du processus de génération.

Comme le rappelle Friedman : « un fichier bloc n’est pas transparent ».
Fournir une sortie brute sans contexte ne suffit pas ; la transparence nécessite des données structurées, fiables et consommables par les systèmes.

La maturité du SBOM repose sur sa capacité à devenir un signal vivant, alimentant à la fois :

• la gestion continue des vulnérabilités,
• les inventaires d’actifs logiciels,
• les workflows de sécurité et d’ingénierie,
• les processus d’achat et d’audit,
• les décisions organisationnelles autour de la conformité et de la qualité logicielle.

La vraie transformation consiste à replacer le SBOM au cœur des opérations, et non dans la documentation annexe.

SCANOSS est une plateforme d’intelligence logicielle (SCA) conçue pour fournir une visibilité totale, une détection précise et une gouvernance complète des composants Open Source (OSS) dans vos projets DevSecOps.

Si vous souhaitez transformer vos SBOM en un véritable moteur de gestion des risques, SCANOSS offre les solutions les plus transparentes, extensibles et opérationnelles du marché.