Sécurité de la chaîne d’approvisionnement logicielle : pourquoi les SBOM seront indispensables en 2026
⏱ 8 min de lecture
SolarWinds, Log4Shell, 3CX – la liste des attaques réussies sur la chaîne d’approvisionnement logicielle s’allonge chaque année. Sonatype estime à plus de 700 % l’augmentation des attaques sur la chaîne d’approvisionnement des composants open source depuis 2020. Parallèlement, le Cyber Resilience Act de l’UE rendra obligatoires les Software Bills of Materials (SBOM) pour tous les produits numériques à compter de 2027. Les entreprises qui n’agissent pas dès maintenant risquent de se retrouver sans accès au marché.
L’essentiel
- + 700 % d’attaques sur la chaîne d’approvisionnement depuis 2020 : les dépendances open source constituent la porte d’entrée principale – une application utilise en moyenne plus de 200 dépendances transitives (Sonatype, 2025).
- Cyber Resilience Act de l’UE (CRA) : à partir de 2027, tous les produits numériques devront être livrés avec une SBOM, un dispositif actif de gestion des vulnérabilités et des mises à jour de sécurité.
- Intégration DevSecOps : la génération automatique de SBOM, le scanning des dépendances et la signature des conteneurs doivent faire partie intégrante de la pipeline CI/CD – et non d’une simple checklist manuelle.
Anatomie d’une attaque sur la chaîne d’approvisionnement
Les attaques sur la chaîne d’approvisionnement ne visent pas directement le logiciel lui-même, mais ses dépendances – bibliothèques, frameworks, outils de construction et composants d’infrastructure. Ce vecteur d’attaque est particulièrement efficace, car un paquet compromis est automatiquement distribué à des milliers d’utilisateurs en aval.
Les méthodes les plus courantes sont le typosquatting (publier un paquet portant un nom quasi identique à celui d’un paquet populaire), la prise de contrôle de compte (saisir le compte d’un mainteneur de confiance), la confusion des dépendances (remplacer un paquet interne par un paquet public portant le même nom) et la compromission du système de construction (manipuler le serveur de build ou la pipeline CI/CD).
L’incident 3CX de 2023 a révélé toute l’ampleur du phénomène : les attaquants ont compromis une bibliothèque amont utilisée par 3CX. Le code altéré a été intégré au client bureau officiel 3CX, utilisé par plus de 600 000 entreprises. La détection a pris plusieurs semaines.
« Les chaînes d’approvisionnement logicielles constituent le maillon faible de la cybersécurité. Les entreprises font aveuglément confiance à du code qu’elles n’ont ni écrit ni vérifié – et qui est souvent entretenu par des individus bénévoles. »
– Brian Behlendorf, Directeur général, Open Source Security Foundation (2025)
SBOM, signatures et le Cyber Resilience Act de l’UE
Une Software Bill of Materials (SBOM) est un inventaire lisible par machine de toutes les composantes d’un logiciel – y compris leurs versions, licences et vulnérabilités connues. Les deux standards reconnus sont SPDX (Linux Foundation) et CycloneDX (OWASP). Fonctionnellement équivalents, ils sont tous deux pris en charge par les principaux outils du marché.
Le Cyber Resilience Act de l’UE (CRA) rendra les SBOM obligatoires à compter de 2027 pour tous les produits numériques commercialisés dans l’Union européenne. Les fabricants devront gérer activement les vulnérabilités, fournir des mises à jour de sécurité pendant toute la durée de vie du produit et transmettre leurs SBOM à l’ENISA. Cette obligation concerne non seulement les éditeurs de logiciels, mais aussi les appareils IoT, les systèmes de contrôle industriel et les produits grand public connectés.
La signature de code et celle des artefacts viennent compléter les SBOM : des outils comme Sigstore (Linux Foundation) permettent de signer cryptographiquement les artefacts de build et les images de conteneurs – gratuitement et de façon transparente. Ainsi, tout utilisateur peut vérifier qu’un artefact provient bien de la pipeline de build attendue et n’a pas été modifié.
Pipeline DevSecOps : la sécurité comme composante intégrée du processus de build
La sécurité de la chaîne d’approvisionnement ne fonctionne que si elle est intégrée au cœur du cycle de développement – non pas comme un audit post-facto, mais comme une étape automatisée de la pipeline CI/CD :
Scanning des dépendances : des outils tels que Snyk, Grype ou Dependabot analysent automatiquement, à chaque build, toutes les dépendances directes et transitives à la recherche de CVE connues. Les vulnérabilités critiques bloquent le build – aucune fusion n’est autorisée sans correction ou acceptation explicite du risque.
Génération de SBOM : Syft (Anchore) ou cdxgen génèrent automatiquement, à chaque version, une SBOM aux formats CycloneDX ou SPDX. Celle-ci est stockée comme artefact de build et peut être fournie aux clients ou aux autorités réglementaires.
Sécurité des conteneurs : les images de conteneurs sont particulièrement exposées – une image de base type contient des centaines de paquets, dont beaucoup présentent des vulnérabilités documentées. Trivy ou Grype scannent les images avant déploiement. Les images distroless (Google) ou Chainguard réduisent radicalement la surface d’attaque.
Signature des artefacts : chaque artefact de build est signé via Sigstore/Cosign. Les clusters Kubernetes peuvent, grâce à des politiques (ex. Kyverno, OPA Gatekeeper), n’accepter que les images signées – tout déploiement non signé étant automatiquement bloqué.
L’effort d’intégration reste modeste : dans une pipeline GitHub Actions ou GitLab CI existante, ces étapes supplémentaires peuvent être implémentées en une seule journée. Tous les outils mentionnés sont open source et gratuits.
Key Facts auf einen Blick
Questions fréquentes
Qu’est-ce qu’une SBOM ?
Une Software Bill of Materials (SBOM) est un inventaire lisible par machine de toutes les composantes d’un logiciel – bibliothèques, frameworks, dépendances – incluant leurs numéros de version, licences et vulnérabilités connues. Elle est l’équivalent d’une liste d’ingrédients pour le logiciel.
Quel format SBOM dois-je utiliser ?
CycloneDX (OWASP) et SPDX (Linux Foundation) sont les deux standards établis. CycloneDX offre une meilleure intégration des données de vulnérabilité, tandis que SPDX excelle dans l’analyse des licences. Pour une approche centrée sécurité, CycloneDX est privilégié ; pour une démarche axée conformité, SPDX est recommandé. La plupart des outils supportent les deux formats.
Quand le Cyber Resilience Act de l’UE entre-t-il en vigueur ?
Le CRA a été adopté en 2024. Les fabricants disposent d’une période transitoire jusqu’en 2027 pour mettre leurs produits en conformité. À compter de cette date, tous les produits numériques commercialisés dans l’UE devront être livrés avec une SBOM, un dispositif actif de gestion des vulnérabilités et des mises à jour de sécurité.
Comment commencer avec la sécurité de la chaîne d’approvisionnement ?
Trois mesures immédiates : 1) Intégrez le scanning des dépendances à votre pipeline CI/CD (Snyk, Dependabot – des offres gratuites sont disponibles). 2) Automatisez la génération de SBOM (Syft, cdxgen). 3) Scannez vos images de conteneurs avec Trivy. L’ensemble peut être mis en œuvre en une seule journée.
Qu’est-ce que Sigstore ?
Sigstore est un projet open source de la Linux Foundation dédié à la signature cryptographique des artefacts logiciels. Il permet aux développeurs de signer gratuitement leur code, leurs images de conteneurs et autres artefacts – sans avoir à déployer leur propre infrastructure PKI. Les signatures sont transparentes et vérifiables publiquement.
Les composants open source sont-ils moins sûrs que les logiciels propriétaires ?
Non, pas fondamentalement – mais ils sont plus transparents, donc plus facilement exploitables. Leur code étant public, cela profite autant aux attaquants qu’aux défenseurs. Le principal risque réside dans les projets mal entretenus, souvent pilotés par un seul mainteneur. Des outils comme OpenSSF Scorecard évaluent automatiquement la maturité sécuritaire des projets open source.
Weitere Artikel zum Thema
→ Cyber Resilience Act de l’UE : ce qui attend les éditeurs de logiciels
→ Passkeys 2025 : guide pratique pour leur déploiement en entreprise
Weiterführende Lektüre im Netzwerk
Cloud & DevOps : Bonnes pratiques de sécurité des conteneurs (CloudMagazin)
Développement logiciel : DevSecOps : intégrer la sécurité au cœur du développement logiciel (MBF)
Source de l’image : Pexels / cottonbro studio
