SBOM

Fonctionnement technique

Le SBOM (Software Bill of Materials) est un inventaire formel et structuré de tous les composants logiciels d'une application : bibliothèques, frameworks, modules, dépendances directes et transitives, avec leurs versions, licences et origines. Comparable à la liste d'ingrédients d'un produit alimentaire, le SBOM fournit la transparence nécessaire pour évaluer les risques de sécurité et de licence d'un logiciel.

Les deux formats standards sont SPDX (Software Package Data Exchange, norme ISO/IEC 5962, soutenu par la Linux Foundation) et CycloneDX (OWASP, format BOM complet incluant SBOM, VEX, HBOM). Les SBOM sont générés à partir du code source (analyse des fichiers de dépendances : package.json, go.mod, requirements.txt), des binaires (analyse des artefacts compilés) ou des images de conteneurs (scan des couches Docker).

Le cycle de vie du SBOM comprend la génération (build time ou analyse), l'enrichissement (ajout des vulnérabilités connues via CPE/PURL), le partage (distribution aux consommateurs du logiciel) et l'exploitation (analyse continue contre les bases CVE, évaluation des licences, identification des composants obsolètes). Le VEX (Vulnerability Exploitability eXchange) complète le SBOM en précisant si les vulnérabilités identifiées sont réellement exploitables dans le contexte de l'application.

Cas d'usage

L'Executive Order 14028 (USA, 2021) rend le SBOM obligatoire pour les fournisseurs du gouvernement américain. L'AI Act et NIS2 en Europe renforcent les exigences de transparence logicielle. Les éditeurs de logiciels doivent fournir un SBOM à leurs clients pour permettre l'évaluation des risques supply chain. Lors de l'incident Log4Shell, les organisations avec un SBOM ont identifié leur exposition en heures, contre des semaines pour les autres.

Les équipes sécurité utilisent le SBOM pour la gestion continue des vulnérabilités : quand une nouvelle CVE est publiée, une requête sur le SBOM identifie immédiatement toutes les applications affectées. Les équipes juridiques l'exploitent pour vérifier la conformité des licences open source et éviter les violations de licence (GPL, AGPL) dans les produits commerciaux.

Outils et implémentation

Syft (Anchore) génère des SBOM en SPDX et CycloneDX depuis les images Docker, les systèmes de fichiers et les répertoires de code. Grype (Anchore) analyse les SBOM pour identifier les vulnérabilités connues. Trivy (Aqua) combine scanning de vulnérabilités, génération de SBOM et détection de secrets en un seul outil.

CycloneDX CLI génère des SBOM au format CycloneDX. SPDX Tools valide et convertit les SBOM au format SPDX. GUAC (Graph for Understanding Artifact Composition, Google) agrège les SBOM dans un graphe de dépendances queryable. Dependency-Track (OWASP) est une plateforme de gestion continue de SBOM avec monitoring des vulnérabilités et des licences.

Défense / Bonnes pratiques

Intégrez la génération de SBOM dans votre pipeline CI/CD : chaque build produit un SBOM versionné et archivé avec l'artefact. Utilisez Syft ou Trivy comme étape de build et stockez les SBOM dans un registre dédié (Dependency-Track, GUAC). Associez chaque release d'application à son SBOM pour permettre le traçage rétrospectif.

Exploitez les SBOM de manière proactive : configurez Dependency-Track pour vous alerter automatiquement quand une nouvelle CVE affecte un composant présent dans vos SBOM. Définissez des politiques de composants : versions minimales, licences autorisées, composants interdits (connus comme vulnérables ou non maintenus).

Ne vous limitez pas aux dépendances directes : les SBOM doivent capturer l'arbre complet des dépendances transitives, car c'est souvent dans les dépendances de dépendances que se cachent les vulnérabilités (comme Log4j dans Log4Shell). Exigez des SBOM de vos fournisseurs de logiciels tiers et intégrez-les dans votre processus d'évaluation des risques supply chain.

Articles associés

Voir nos articles détaillés sur ce sujet.