En décembre 2021, la faille Log4Shell a paralysé des milliers d’entreprises dans le monde. Le point commun ? Elles utilisaient toutes une bibliothèque open source vulnérable sans le savoir. En 2024, l’attaque XZ Utils a démontré qu’un contributeur malveillant pouvait infiltrer un projet open source critique pendant des années.
Les attaques supply chain logicielle sont devenues l’une des menaces les plus redoutables en cybersécurité. Ce guide explique comment s’en protéger.
Qu’est-ce qu’une supply chain attack ?
Une attaque supply chain cible la chaîne d’approvisionnement logicielle plutôt que votre code directement. L’attaquant compromet un composant que vous utilisez (bibliothèque, outil de build, conteneur Docker, mise à jour logicielle) pour atteindre votre système.
Les vecteurs les plus courants
- Dépendances compromises : package malveillant sur npm, PyPI ou Maven (typosquatting, account takeover)
- Compromission du pipeline CI/CD : injection de code dans le processus de build
- Mise à jour piégée : l’attaquant compromet le serveur de mise à jour d’un éditeur (cas SolarWinds)
- Conteneurs Docker corrompus : images Docker Hub contenant des backdoors ou des cryptominers
- Contributeur malveillant : infiltration d’un projet open source (cas XZ Utils, 2024)
Cas concrets marquants
| Incident | Année | Vecteur | Impact |
|---|---|---|---|
| SolarWinds Orion | 2020 | Mise à jour compromise | 18 000 organisations, dont le gouvernement US |
| Log4Shell (Log4j) | 2021 | Vulnérabilité dans une dépendance | Des millions de systèmes exposés mondialement |
| Codecov | 2021 | Script de CI modifié | Exfiltration de secrets CI/CD de centaines d’entreprises |
| XZ Utils | 2024 | Contributeur malveillant (Jia Tan) | Backdoor dans sshd, détectée avant exploitation massive |
| 3CX | 2023 | Application desktop compromise | 600 000 entreprises clientes potentiellement touchées |
Comment se protéger : le framework en 7 couches
1. Inventorier vos dépendances (SBOM)
Le SBOM (Software Bill of Materials) est la liste exhaustive de tous les composants logiciels utilisés dans vos applications. C’est la première étape indispensable. Outils : Syft, CycloneDX, SPDX.
2. Scanner les vulnérabilités connues (SCA)
L’analyse de composition logicielle (SCA) détecte les vulnérabilités CVE dans vos dépendances. Intégrez-la dans votre CI/CD. Outils : Dependabot (GitHub), Snyk, Trivy, Grype.
3. Verrouiller les dépendances
Utilisez des fichiers de verrouillage (package-lock.json, Pipfile.lock, go.sum) et vérifiez les checksums. Epinglez les versions exactes pour les dépendances critiques.
4. Signer et vérifier
Signez vos artefacts de build (Sigstore/Cosign pour les conteneurs, GPG pour les packages). Vérifiez les signatures avant tout déploiement.
5. Sécuriser le pipeline CI/CD
- Principe du moindre privilège pour les tokens CI/CD
- Revue de code obligatoire avant merge
- Build reproductible et déterministe
- Secrets stockés dans un vault (HashiCorp Vault, AWS Secrets Manager), jamais dans le code
6. Utiliser des registres privés
Mirrorez vos dépendances critiques dans un registre interne (Nexus, Artifactory, GitLab Registry). Scannez-les avant de les autoriser.
7. Surveiller en continu
Abonnez-vous aux flux de vulnérabilités (NVD, GitHub Security Advisories). Configurez des alertes automatiques quand une CVE touche l’une de vos dépendances.
SBOM : bientôt obligatoire ?
Aux Etats-Unis, l’Executive Order 14028 (2021) impose le SBOM pour les fournisseurs du gouvernement fédéral. En Europe, le Cyber Resilience Act (CRA), adopté en 2024, imposera aux fabricants de produits numériques de fournir un SBOM. L’entrée en vigueur est prévue pour 2027.
Même sans obligation légale immédiate, le SBOM devient un standard de l’industrie et un différenciateur commercial.
FAQ
Les PME sont-elles concernées ?
Oui. Si vous développez du logiciel (même un site web avec des dépendances npm), vous êtes exposé. Les attaquants ciblent les dépendances les plus utilisées, pas les plus grandes entreprises.
Par où commencer ?
Activez Dependabot ou Snyk sur vos repositories. C’est gratuit pour les projets de taille raisonnable et ça couvre 80% du risque avec un effort minimal.
Comment détecter une dépendance malveillante ?
Vérifiez la popularité (nombre de téléchargements, stars GitHub), l’ancienneté du mainteneur, l’activité récente. Méfiez-vous des packages au nom très proche d’un package populaire (typosquatting).
Besoin d’un audit de votre chaîne logicielle ? Contactez RM3A pour un diagnostic supply chain.
