SBOM et sécurité de la chaîne logicielle : protéger contre les attaques supply chain

L'attaque XZ Utils de mars 2024 a démontré que même les composants open source les plus utilisés peuvent être compromis par un acteur malveillant infiltré en tant que mainteneur. Le Software Bill of Materials (SBOM) est devenu la réponse réglementaire et technique à ce défi. Rendu obligatoire pour les logiciels vendus aux administrations américaines depuis l'Executive Order de 2021, il arrive en Europe avec le Cyber Resilience Act.

1. Qu'est-ce qu'un SBOM ?

Un SBOM (Software Bill of Materials) est un inventaire formel et structuré de tous les composants logiciels d'une application : dépendances directes, dépendances transitives, bibliothèques open source, composants commerciaux, versions, licences et origines.

Analogie : le SBOM est à un logiciel ce que la liste d'ingrédients est à un produit alimentaire. Il permet de savoir exactement ce que contient votre application et de réagir immédiatement quand une dépendance est compromise.

2. Les formats standards : SPDX et CycloneDX

• SPDX (Software Package Data Exchange, Linux Foundation) : format le plus ancien et le plus utilisé pour les aspects de licence. Formats : JSON, XML, RDF, tag-value. Adopté par l'NTIA (США) comme format de référence.
• CycloneDX (OWASP) : format orienté sécurité, supporte la notion de VEX (Vulnerability Exploitability eXchange) pour indiquer si une CVE est exploitable dans le contexte de l'application. Plus adapté pour les workflows DevSecOps.

Le Cyber Resilience Act européen (CRA, entré en vigueur en 2025) exigera un SBOM pour tous les produits connectés vendus en Europe d'ici 2027.

3. Attaques supply chain majeures : leçons apprises

SolarWinds (2020)

Le groupe APT29 (Cozy Bear) a compromis le processus de build de SolarWinds Orion, injectant un backdoor dans les mises à jour signées numériquement. 18 000 organisations, dont des agences gouvernementales américaines, ont été compromises. Un SBOM n'aurait pas empêché l'attaque mais aurait accéléré la détection et la réponse.

Log4Shell (CVE-2021-44228)

La vulnérabilité dans Log4j 2, présente dans des milliers d'applications Java, a mis des mois à être identifiée et patchée car les entreprises ne savaient pas si elles utilisaient Log4j. Avec un SBOM à jour, la réponse aurait été réduite de semaines à heures.

XZ Utils (CVE-2024-3094)

Un attaquant a passé deux ans à gagner la confiance de la communauté open source avant d'injecter une backdoor dans XZ Utils, un outil de compression présent dans la plupart des distributions Linux. Découvert par hasard avant déploiement massif. Illustre le risque des dépendances maintenues par des volontaires individuels.

4. Générer et maintenir un SBOM

Outils de génération

• Syft (Anchore, open source) : génère des SBOMs SPDX ou CycloneDX à partir d'images Docker, de systèmes de fichiers, de code source.
• Trivy : génère des SBOMs en plus des scans de vulnérabilités.
• CycloneDX CLI : outil officiel OWASP pour créer et valider des SBOMs CycloneDX.
• cdxgen : supporte 20+ langages (npm, Maven, pip, Gradle, cargo, Go modules).

Analyse de vulnérabilités sur SBOM

• Grype (Anchore) : analyse un SBOM SPDX/CycloneDX et corrèle avec les bases de données CVE (NVD, GitHub Advisory, OSV).
• OWASP Dependency-Check : pour les projets Java, .NET, Node.js.
• OSV-Scanner (Google) : intégration avec OSV.dev, base de données ouverte des vulnérabilités.

Intégration CI/CD

Générer le SBOM à chaque build, le stocker dans le registre d'artefacts (avec l'image Docker ou le package), et déclencher automatiquement une alerte si une nouvelle CVE critique est publiée affectant un composant listé dans les SBOMs de production.

5. VEX : Vulnerability Exploitability eXchange

Le VEX est un complément au SBOM qui permet à un éditeur d'indiquer l'exploitabilité réelle d'une CVE dans son produit :

• Not Affected : la CVE existe dans la dépendance mais le code vulnérable n'est pas appelé.
• Affected : la CVE est exploitable dans ce produit — patch nécessaire.
• Fixed : la CVE a été corrigée dans cette version.
• Under Investigation : analyse en cours.

Le VEX réduit drastiquement les faux positifs dans les scans de vulnérabilités et permet aux équipes de sécurité de se concentrer sur les risques réels.

6. Conformité réglementaire

• Cyber Resilience Act (CRA) : SBOM obligatoire pour les produits connectés vendus dans l'UE. Entrée en vigueur progressive jusqu'en 2027.
• NIS2 : gestion des risques de la chaîne d'approvisionnement (art. 21) — le SBOM est un outil clé pour démontrer la maîtrise des dépendances.
• DORA : pour les entités financières, cartographie des dépendances tier-1 et tier-2 avec évaluation des risques.

Conclusion

Le SBOM n'est pas une contrainte bureaucratique mais un outil de visibilité indispensable dans un monde où 80 % du code d'une application moderne provient de sources externes. Intégré dans votre pipeline DevSecOps, il vous permet de répondre en quelques heures à la prochaine Log4Shell plutôt qu'en plusieurs semaines. Avec le CRA et NIS2, c'est aussi une obligation réglementaire inéluctable.