SBOM : creer et maintenir votre inventaire logiciel

Qu’est-ce qu’un SBOM

Un Software Bill of Materials (SBOM) est l’equivalent d’une liste d’ingredients pour un logiciel. Il documente tous les composants (bibliotheques, frameworks, outils) utilises dans une application, avec leurs versions et leurs licences.

L’analogie alimentaire est particulierement juste : tout comme une liste d’ingredients permet d’identifier un allergene ou un ingredient retire du marche, un SBOM permet d’identifier un composant vulnerabilise ou compromis parmi des milliers. Sans cet inventaire, repondre a une alerte de securite necessite des jours d’analyse manuelle. Avec un SBOM a jour, la reponse est immediate.

Pourquoi c’est indispensable

Quand une vulnerabilite critique est divulguee (comme Log4Shell ou XZ Utils), la premiere question est : “est-ce qu’on utilise ce composant ?” Sans SBOM, repondre prend des jours. Avec un SBOM, la reponse est instantanee.

Log4Shell (CVE-2021-44228) a ete une lecon douloureuse pour l’industrie : des organisations ont mis des semaines a determiner si elles utilisaient Log4j, et dans quelle version. Certaines ont decouvert des instances enfouies profondement dans des dependances transitives qu’elles ne connaissaient meme pas. Le SBOM transforme ce processus de detection de semaines en minutes.

Au-dela de la reponse aux incidents, le SBOM apporte une visibilite continue :

• Licences : identifier les composants avec des licences incompatibles (GPL dans un produit commercial)
• Maintenance : detecter les composants abandonnes sans mainteneur actif
• Conformite : demontrer aux clients et regulateurs la maitrise de la supply chain
• Audits : simplifier les audits de securite avec un inventaire formel

Formats standards

• SPDX (Linux Foundation) : format ISO, le plus standardise, recommande pour les echanges inter-organisations
• CycloneDX (OWASP) : leger, optimise pour la securite, le plus utilise dans les outils de securite
• SWID : format plus ancien, moins utilise

SPDX et CycloneDX sont les deux formats dominants. CycloneDX est souvent prefere par les equipes securite pour sa richesse en metadonnees de securite (vulnerabilites, CVSS, exploitabilite). SPDX est prefere pour les echanges contractuels et la conformite reglementaire.

Les deux formats supportent les formats JSON, XML et autres representations, facilitant l’integration dans les pipelines existants.

Outils de generation

Outil	Ecosystemes	Cout
Syft (Anchore)	Multi-langage, containers	Gratuit
Trivy (Aqua)	Multi-langage, containers, IaC	Gratuit
cdxgen	Node, Java, Python, Go	Gratuit
FOSSA	Multi-langage	Commercial

Syft est souvent le choix de reference pour les environnements conteneurisees : il analyse les images Docker et genere des SBOM exhaustifs incluant les packages du systeme d’exploitation et les dependances applicatives.

Trivy a l’avantage d’etre un outil multi-fonctions : il genere des SBOM, scanne les vulnerabilites, analyse les configurations IaC (Terraform, Kubernetes), et s’integre dans pratiquement tous les pipelines CI/CD.

cdxgen est optimal pour les projets polyglotte : il supporte nativement Node.js, Java, Python, Go, Ruby, Rust et d’autres ecosystemes, generant des SBOM CycloneDX precis.

Integration dans le pipeline

Le SBOM doit etre genere automatiquement a chaque build et stocke avec l’artefact de release. Les scans de vulnerabilites doivent etre executes contre le SBOM a chaque mise a jour de la base CVE.

Pipeline CI/CD recommande :

1. Generation du SBOM a chaque build
2. Scan de vulnerabilites contre le SBOM (Grype, Trivy, Snyk)
3. Blocage du build si vulnerabilites critiques non acceptees
4. Stockage du SBOM signe avec l’artefact de release
5. Re-scan quotidien contre les nouvelles CVE publiees

Cette approche de “continuous vulnerability management” permet de detecter les composants qui deviennent vulnerables apres la mise en production, pas seulement au moment du build.

Gestion des vulnerabilites avec un SBOM

Le SBOM est le point de depart, pas la destination. Sa valeur reelle est dans les processus qu’il permet :

Vulnerability triage : toutes les vulnerabilites ne sont pas egales. Un composant vulnerabilise qui n’est pas appele par le code de production ou dont la fonctionnalite vulneable n’est pas utilisee peut etre accepte avec un risque mesure. Sans SBOM, cette analyse est impossible.

Patch prioritization : les vulnerabilites critiques dans des composants directement exposes sur Internet necessitent une action en 24 heures. Les vulnerabilites dans des dependances internes profondes peuvent etre traitees lors du prochain cycle de maintenance.

VEX (Vulnerability Exploitability eXchange) : format complementaire au SBOM qui documente la relation entre les vulnerabilites connues et un produit specifique (“affected”, “not affected”, “fixed”, “under investigation”). Permet de communiquer efficacement sur le statut des vulnerabilites aux clients et partenaires.

Aspects reglementaires

Le Cyber Resilience Act europeen (en application progressive depuis 2024) exige la disponibilite d’un SBOM pour les produits numeriques vendus dans l’UE. Le NIST Cybersecurity Framework 2.0 inclut le SBOM dans ses recommandations de gestion de la supply chain.

Pour les organisations dans le perimetre NIS2, la maitrise de la supply chain logicielle (dont le SBOM est un composant) fait partie des 10 exigences cles de la directive.