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 logiciel augmente chaque année. Sonatype a quantifié une augmentation de plus de 700 pour cent des attaques sur les composants open source depuis 2020. Parallèlement, l’EU Cyber Resilience Act exigera des bilans de matières logiciels (SBOM) pour tous les produits numériques à partir de 2027. Les entreprises qui ne prennent pas d’action risquent de perdre leur accès au marché.
Les points clés en bref
- 700 % plus d’attaques sur la chaîne d’approvisionnement depuis 2020: Les dépendances open source sont le principal point d’entrée — en moyenne, une application utilise plus de 200 dépendances transitives (Sonatype, 2025).
- EU Cyber Resilience Act (CRA): À partir de 2027, tous les produits numériques doivent être livrés avec un SBOM, un gestionnaire de vulnérabilités et des mises à jour de sécurité.
- Intégration DevSecOps: La génération de SBOM, la détection de dépendances et la signature de conteneurs font partie de la pipeline CI/CD — pas dans la liste de vérification manuelle.
Anatomie d’une attaque sur la chaîne d’approvisionnement
Les attaques sur la chaîne d’approvisionnement visent non pas le logiciel en soi, mais ses dépendances — bibliothèques, cadres, outils de build et composants d’infrastructure. Le vecteur d’attaque est particulièrement efficace car un package compromis est automatiquement distribué à des milliers d’utilisateurs en aval.
Les méthodes les plus courantes : Typosquatting (publier un package avec un nom très similaire à un package populaire), préemption d’un compte (prendre le contrôle d’un compte de maintainer fiable), confusion de dépendance (remplacer un package interne avec un package public portant le même nom) et compromission du système de build (manipuler le serveur de build ou la pipeline CI/CD).
Le scandale 3CX 2023 a montré la portée complète : les attaquants ont compromis une bibliothèque utilisée par 3CX. Le code manipulé est tombé dans le client 3CX Desktop officiel utilisé par plus de 600 000 entreprises. La détection a nécessité des semaines.
«Les chaînes de logiciels sont le joint le plus faible de la cybersécurité. Les entreprises font confiance au code qu’elles n’ont ni écrit ni vérifié — souvent géré par des individus non rémunérés.»
— Brian Behlendorf, Gestionnaire général, Open Source Security Foundation (2025)
SBOMs, signatures et l’EU Cyber Resilience Act
Un Software Bill of Materials (SBOM) est un répertoire lisible par machine de toutes les composantes d’une logicielle — y compris les versions, les licences et les vulnérabilités connues. Les deux normes sont SPDX (Linux Foundation) et CycloneDX (OWASP). Elles sont fonctionnellement équivalentes et sont toutes deux largement supportées par les principaux outils.
L’EU Cyber Resilience Act (CRA) rend obligatoire l’utilisation de SBOM pour tous les produits numériques vendus dans l’UE à partir de 2027. Les fabricants doivent gérer activement les vulnérabilités, fournir des mises à jour de sécurité tout au long de la durée de vie du produit et transmettre les SBOM à l’ENISA. Cela concerne non seulement les fabricants de logiciels, mais aussi les appareils IoT, les contrôleurs industriels et les produits de consommation connectés.
La signature de code et les signatures d’artefacts complètent les SBOM : des outils comme Sigstore (Linux Foundation) permettent une signature cryptographique d’artefacts de build et d’images de conteneurs — gratuits et transparents. Ainsi, chaque utilisateur peut vérifier que l’artefact provient effectivement de la pipeline de build attendue et n’a pas été manipulé.
DevSecOps-Pipeline : Sécurité en tant que partie intégrante du processus de build
La sécurité de la chaîne d’approvisionnement fonctionne uniquement lorsqu’elle est intégrée au processus de développement — et non comme une vérification après coup. Elle doit être automatisée et intégrée à la CI/CD-pipeline :
Analyse de dépendances : Des outils comme Snyk, Grype ou Dependabot analysent automatiquement toutes les dépendances directes et transitives à chaque build pour détecter les CVE (Vulnérabilités connues). Les failles critiques empêchent la validation du build — aucun merge sans correction ou acceptation documentée du risque.
Génération d’un SBOM : Syft (Anchore) ou cdxgen génèrent automatiquement une SBOM (Bill of Materials de logiciel) au format CycloneDX ou SPDX à chaque release. L’SBOM est conservé comme artefact de build et peut être partagé avec les clients ou les autorités de régulation.
Sécurité des conteneurs : Les images de conteneurs sont particulièrement vulnérables — un base image classique peut contenir des centaines de paquets, dont de nombreux sont vulnérables. Trivy ou Grype analysent les images avant le déploiement. Les images Distroless (Google) ou Chainguard réduisent drastiquement l’attractivité pour les attaquants.
Signature d’artefacts : Chaque artefact de build est signé avec Sigstore/Cosign. Les clusters Kubernetes peuvent être configurés pour accepter uniquement des images signées (par exemple, avec Kyverno ou OPA Gatekeeper). Les déploiements non signés sont automatiquement bloqués.
L’effort d’intégration est minimal : dans une pipeline GitHub Actions ou GitLab CI existante, les étapes supplémentaires peuvent être ajoutées dans un seul tag. Les outils sont open source et gratuits.
Faits clés à un coup d’œil
Foire aux questions
Qu’est-ce qu’un SBOM ?
Un SBOM (Software Bill of Materials) est un répertoire machinable de toutes les composantes logicielle — bibliothèques, frameworks, dépendances — y compris les versions, les licences et les vulnérabilités connues. Comparable à une liste de composants pour un logiciel.
Quel format SBOM devrais-je utiliser ?
CycloneDX (OWASP) et SPDX (Linux Foundation) sont les deux normes établies. CycloneDX offre une meilleure intégration des vulnérabilités, tandis que SPDX est mieux adapté à l’analyse de licence. Pour un focus sur la sécurité, CycloneDX est recommandé ; pour un focus sur la conformité, SPDX est plus approprié. La plupart des outils prennent en charge les deux formats.
Quand entre en vigueur l’EU Cyber Resilience Act ?
Le CRA (Cyber Resilience Act) a été adopté en 2024. Les fabricants ont une période de transition jusqu’en 2027 pour aligner leurs produits. À partir de cette date, tous les produits numériques livrés dans l’UE doivent inclure un SBOM, un management actif des vulnérabilités et des mises à jour de sécurité.
Comment démarrer avec la sécurité de la chaîne d’approvisionnement ?
Trois mesures immédiates : 1) Intégrez l’analyse de dépendances dans votre pipeline CI/CD (Snyk, Dependabot — des niveaux gratuits disponibles). 2) Automatisez la génération d’un SBOM (Syft, cdxgen). 3) Analysez vos images de conteneurs avec Trivy. Toutes ces mesures peuvent être mises en œuvre dans une journée.
Qu’est-ce que Sigstore ?
Sigstore est un projet open source de la Linux Foundation pour la signature cryptographique d’artefacts logiciels. Il permet aux développeurs de signer gratuitement du code, des images de conteneurs et d’autres artefacts — sans infrastructure PKI personnelle. Les signatures sont transparentes et publiquement vérifiables.
Les composants open source sont-ils plus vulnérables que les propriétaires ?
Non de manière générale — mais ils sont plus transparents et donc plus attirants pour les attaquants. Le code est public, ce qui aide à la fois les attaquants et les défenseurs. Le principal risque réside dans les projets non maintenus par des seuls contributeurs. Les outils comme OpenSSF Scorecard évaluent automatiquement la maturité de la sécurité des projets open source.
Articles supplémentaires sur le sujet
→ EU Cyber Resilience Act : Quels sont les implications pour les fabricants de logiciels
→ Passkeys 2025 : Guide d’implémentation pour les entreprises
Lectures complémentaires dans le réseau
Cloud & DevOps : Meilleures pratiques en sécurité des conteneurs (CloudMagazine)
Logiciels développement : DevSecOps : Sécurité dans le développement logiciel (MBF)
Source image de couverture : Pexels / cottonbro studio
