Sécurité de la chaîne d’approvisionnement logicielle : comment les SBOM créent la transparence qui a fait défaut

SolarWinds, Log4Shell, MOVEit – chaque grande attaque de la chaîne d’approvisionnement de ces dernières années aurait pu être contenue plus rapidement grâce à une Software Bill of Materials (SBOM). Les SBOM recensent tous les composants d’un logiciel et permettent, en quelques minutes, ce qui prendrait des semaines sans elles : déterminer si l’on est affecté.

L’essentiel

  • L’ordre exécutif américain 14028 rend les SBOM obligatoires pour les fournisseurs des agences fédérales
  • Le Cyber Resilience Act de l’UE exige des SBOM à partir de 2027 pour tous les produits numériques
  • Formats : SPDX (Linux Foundation) et CycloneDX (OWASP)
  • La NTIA définit les exigences minimales : Fournisseur, Composant, Version, Dépendance

Ce qu’est concrètement une SBOM

Une SBOM est une liste lisible par machine de tous les composants logiciels : bibliothèques, frameworks, dépendances – avec nom, version, licence et origine. Elle est comparable à une liste d’ingrédients sur un emballage alimentaire : on sait exactement ce qu’elle contient.

En pratique : dès qu’une nouvelle vulnérabilité comme Log4Shell est révélée, une entreprise dotée de SBOM peut identifier en quelques minutes quels de ses produits intègrent le composant concerné. À défaut de SBOM, elle doit entamer une recherche manuelle longue de plusieurs semaines.

La pression réglementaire augmente

Les États-Unis ont pris les devants : l’ordre exécutif 14028 oblige les fournisseurs de logiciels du gouvernement fédéral à fournir des SBOM. L’Union européenne suit avec le Cyber Resilience Act (CRA), qui imposera à compter de 2027 des SBOM pour tous les produits numériques commercialisés dans l’UE.

Pour les éditeurs allemands de logiciels et les fabricants de produits numériques, c’est un compte à rebours : ceux qui ne seront pas en mesure de fournir de SBOM en 2027 perdront l’accès au marché – aussi bien aux États-Unis qu’en Europe.

Intégration dans le processus de développement

Les SBOM ne doivent pas être produites a posteriori, mais générées automatiquement au cours du processus de construction. Des outils tels que Syft, Trivy, CycloneDX CLI ou les outils SPDX s’intègrent nativement dans les pipelines CI/CD et génèrent une SBOM à chaque livraison.

Le flux de travail type : la phase de build produit la SBOM, celle-ci est confrontée aux bases de données de vulnérabilités (NVD, OSV), et tout release présentant des failles critiques est bloqué. C’est là le DevSecOps en action – la transparence transformée en standard qualité automatisé.

Gestion des SBOM : plus que la simple création

Générer une SBOM constitue la première étape. La véritable valeur se crée via une gestion continue : les nouveaux CVE sont vérifiés automatiquement contre les SBOM existantes, les clients reçoivent des alertes proactives dès qu’un composant critique est affecté, et la SBOM est mise à jour à chaque nouvelle version.

Des plateformes telles que Dependency-Track (OWASP, open source) ou des solutions commerciales comme Anchore et Sonatype automatisent ce cycle de vie. L’effort requis est minime – le bénéfice, en revanche, est considérable lorsqu’une crise survient.

Key Facts

Transparence : Une SBOM réduit le temps de réaction face aux nouveaux CVE de plusieurs semaines à quelques minutes

Réglementation : L’ordre exécutif américain 14028 et le CRA européen rendent la SBOM obligatoire d’ici 2027

Adoption : La création de SBOM a bondi de 300 % après Log4Shell (Sonatype)

Questions fréquentes

Quel format dois-je utiliser ?

CycloneDX (OWASP) pour les SBOM axées sécurité, SPDX (Linux Foundation) pour la conformité licence. Les deux formats sont lisibles par machine et convertibles. CycloneDX offre par ailleurs une intégration plus avancée avec VEX (Vulnerability Exploitability eXchange).

Dois-je créer des SBOM pour les dépendances open source ?

Oui – c’est précisément là que réside leur principal intérêt. La plupart des applications modernes reposent à 70-90 % sur des composants open source. Sans SBOM couvrant ces dépendances, la gestion des vulnérabilités devient aveugle.

Comment partager les SBOM avec mes clients ?

Trois modèles s’offrent à vous : livraison directe avec chaque version, accès à un portail dédié, ou fourniture sur demande. Le CRA devrait probablement imposer la diffusion proactive. Mettez dès aujourd’hui en place un processus structuré, avant que l’obligation ne devienne effective.

Articles connexes

Source de l’image : Pexels / Mike Bird

Tobias Massow

À propos de l'auteur: Tobias Massow

Plus d'articles de

Aussi disponible en

EspañolEnglishDeutsch

Lire l'article

Un magazine de Evernine Media GmbH