SBOM : comprendre et gérer la chaîne d'approvisionnement logicielle

Le SBOM (Software Bill of Materials) est devenu en 2026 l'un des artefacts critiques de la cybersécurité. Imposé par les autorités américaines (Executive Order 14028) et de plus en plus exigé en Europe via le Cyber Resilience Act, il liste tous les composants logiciels qui constituent une application — y compris les bibliothèques tierces et open source.

Pourquoi le SBOM est devenu critique

Trois éléments ont rendu le SBOM incontournable : les attaques supply chain (SolarWinds, Log4j, XZ Utils) qui ont démontré qu'un seul composant compromis peut affecter des milliers d'organisations ; l'inflation des dépendances open source (une application moderne contient en moyenne 80% de code tiers) ; les exigences réglementaires qui imposent désormais la traçabilité des composants.

Les 3 cas d'usage prioritaires

1. Réponse rapide à une CVE critique : quand une CVE critique tombe (type Log4Shell), le SBOM permet de savoir en minutes — et non en jours — quelles applications de votre parc sont vulnérables. 2. Conformité fournisseurs : avant d'acheter un logiciel, exiger son SBOM permet de vérifier que les composants sont à jour, sans CVE critique non patchée, et sans licence problématique. 3. Due diligence M&A : lors d'une acquisition, le SBOM des produits acquis révèle l'état réel de la dette de sécurité — ce que les questionnaires ne montrent pas.

Comment démarrer en 4 étapes

1. Choisir un format standard : CycloneDX (OWASP) ou SPDX (Linux Foundation) — pas un format propriétaire. 2. Automatiser la génération : intégrer des outils comme Syft, Trivy ou Anchore dans votre CI/CD. 3. Stocker et versionner : un SBOM par version d'application, conservé dans un référentiel central. 4. Connecter à votre veille CVE : croiser SBOM et flux CVE pour générer des alertes contextualisées.

Sans SBOM, votre réponse à incident est aveugle. Avec, elle devient chirurgicale.