Attaque par la chaîne d’approvisionnement

Définition

Une attaque par la chaîne d’approvisionnement (également appelée attaque tierce ou attaque par dépendance) est une cyberattaque où l’attaquant compromet un fournisseur de confiance, une bibliothèque logiciel, un système de build ou un prestataire de service pour obtenir un accès à ses clients ou utilisateurs en aval. Au lieu d’attaquer directement la cible, l’attaquant exploite la relation de confiance entre les organisations et leurs fournisseurs, dépendances ou mécanismes de mise à jour.

Le principe fondamental est l’amplification : compromettre un composant largement utilisé pour atteindre simultanément des centaines ou des milliers d’organisations. Cet « effet multiplicateur » rend les attaques par chaîne d’approvisionnement disproportionnellement impactantes par rapport à l’effort requis.

Comment ça fonctionne

Les attaques par chaîne d’approvisionnement suivent un schéma commun :

  1. Identifier un intermédiaire de confiance — un fournisseur logiciel, un mainteneur open-source, une plateforme CI/CD, un fournisseur cloud ou un fournisseur matériel
  2. Compromettre l’intermédiaire — via des identifiants volés, des vulnérabilités exploitées, de l’ingénierie sociale ou un accès interne
  3. Insérer du code ou des configurations malveillants — dans les mises à jour logiciel, les bibliothèques, les pipelines de build ou le firmware
  4. Distribuer l’artefact compromis — via des canaux de mise à jour légitimes, des registres de paquets ou des systèmes de déploiement
  5. Activer la charge utile — dans les environnements des victimes en aval, souvent avec une persistance à long terme

L’essentiel est que l’artefact malveillant semble légitime car il provient d’une source de confiance. Les défenses périmétriques traditionnelles et les outils basés sur des signatures le manquent souvent.

Exemples récents (2023-2026)

Shai-Hulud npm Worm (2025)

Le premier ver auto-propagateur réussi ciblant l’écosystème npm. Les attaquants ont compromis des comptes de mainteneurs et auto-publié des versions malveillantes de plus de 500 packages. Le ver s’est propagé aux dépôts GitHub et aux miroirs Maven, démontrant comment un point de compromis unique combiné à des pipelines automatisés peut engendrer une attaque à l’échelle de l’écosystème.

Campagne GitHub Actions tj-actions (2025)

Des tags d’actions GitHub populaires ont été redirigés vers des commits malveillants. Tout build dépendant de ces tags a exfiltré des secrets CI/CD. Cela a exploité l’hypothèse de confiance selon laquelle les versions taguées restent immuables, ciblant la couche d’infrastructure CI/CD.

GlassWorm extension VS Code (2025)

Premier ver connu se propageant via des extensions VS Code. Utilisé une injection de code invisible basée sur Unicode pour masquer la logique malveillante. Les mises à jour automatiques ont propagé le malware silencieusement. L’infrastructure de commande-et-contrôle utilisait des transactions blockchain Solana et des événements Google Calendar, rendant le démantèlement difficile.

Campagne PhantomRaven npm (2025)

Déploiement de 126 packages npm malveillants utilisant le « slopsquatting » — des fautes de frappe de noms de packages populaires. A accumulé ~86 000 téléchargements avant détection. A opéré discrètement pour voler des tokens et secrets, ensemencant un compromis à long terme dans les pipelines.

Backdoor XZ Utils (2024)

Un contributeur malveillant a inséré un backdoor dans la bibliothèque de compression XZ, utilisée par les principales distributions Linux. Le backdoor a permis un accès SSH non autorisé. A démontré les risques dans les composants open-source et la difficulté de détecter un compromis à long terme dans les bibliothèques système de bas niveau.

Attaque SolarWinds Orion (2020)

Du code malveillant a été inséré dans les mises à jour de la plateforme de gestion réseau par un acteur étatique. A permis un espionnage à long terme à travers les gouvernements et les entreprises. A élevé la sécurité de la chaîne d’approvisionnement au rang de priorité de board et a conduit à la création du Software Supply Chain Working Group.

Log4Shell (Apache Log4j) (2021)

Exécution de code à distance via des messages de log transformés dans la bibliothèque de logging Java. A souligné la crise de visibilité dans les dépendances logiciel et accéléré la demande de normes de Software Bill of Materials (SBOM).

NotPetya via MeDoc (2017)

Ransomware propagé via des mises à jour compromises de logiciels comptables ukrainiens. A affecté Maersk, Merck et FedEx. Dommages totaux estimés à plus de 10 milliards de dollars. A établi le modèle pour abuser des mises à jour logiciel de confiance.

Langages de programmation et environnements les plus touchés

Écosystèmes les plus ciblés

  1. JavaScript/Node.js (npm) — Plus grande surface d’attaque en raison du volume immense de packages, du faible seuil de publication et de la vérification faible. npm est le registre de packages le plus ciblé, avec le ver Shai-Hulud et les campagnes PhantomRaven démontrant le risque.

  2. Python (PyPI) — Deuxième plus ciblé. L’écosystème Python a grandi rapidement, et de nombreux packages ont des mainteneurs uniques avec une revue de sécurité limitée. Les attaques par typosquatting sont courantes.

  3. Java/Maven — Les applications Java enterprise ont des arbres de dépendance profonds. Log4Shell a démontré comment une seule bibliothèque vulnérable peut affecter des millions de systèmes dans le monde.

  4. Ruby (RubyGems) — Plus petit mais cible de valeur, avec plusieurs incidents de compromis à grand retentissement.

  5. Go (Go modules) — Cible croissante alors que l’adoption de Go augmente dans l’infrastructure cloud-native.

  6. C/C++ (bibliothèques système) — XZ Utils a démontré l’impact catastrophique de la compromission de bibliothèques système de bas niveau utilisées par les distributions Linux.

Environnements les plus touchés

  • Pipelines CI/CD — CircleCI, GitHub Actions et TeamCity ont tous été ciblés. Des pipelines compromis accordent un accès aux secrets de production et peuvent injecter du code malveillant dans chaque build.
  • Registres de packages — npm, PyPI, Maven Central et RubyGems sont les canaux de distribution primaires pour les packages malveillants.
  • Projets open-source — Les projets à mainteneur unique avec des comptes de téléchargement élevés sont des cibles privilégiées pour la compromission.
  • Infrastructure cloud — AWS, Azure et GCP sont ciblés via le vol d’identifiants et l’abus d’API.
  • Hardware/firmware — Les chaînes d’approvisionnement de firmware (par ex. ASUS ShadowHammer) sont difficiles à détecter et à corriger.

Pourquoi ces cibles sont privilégiées

  • Relation de confiance — Les utilisateurs font confiance à la source, donc ils ne scrutinent pas les mises à jour
  • Distribution automatisée — Les gestionnaires de packages installent automatiquement les mises à jour, propageant le compromis à grande échelle
  • Faible barrière d’entrée — Créer un package malveillant coûte presque rien
  • Manque de visibilité — La plupart des organisations ne peuvent pas auditer toutes leurs dépendances
  • Longue durée de vie — Le code malveillant peut rester indétecté pendant des mois ou des années

Stratégies d’atténuation

1. Software Bill of Materials (SBOM)

Maintenir un inventaire de tous les composants logiciel, versions et dépendances. Des normes comme SPDX et CycloneDX fournissent des formats lisibles par machine. Les SBOM permettent une identification rapide des composants vulnérables lors d’incidents.

2. Vérification des dépendances

  • Épingler les versions de dépendances à des commits ou hachages spécifiques, pas à des tags flottants
  • Utiliser des fichiers de verrouillage (package-lock.json, poetry.lock, go.sum) et les committer dans le contrôle de version
  • Vérifier les signatures cryptographiques des packages avant l’installation
  • Utiliser des outils de scan de dépendances (Dependabot, Snyk, Trivy) pour détecter les vulnérabilités connues

3. Sécurité des pipelines CI/CD

  • Appliquer le principe du moindre privilège aux systèmes de build
  • Exiger une approbation multi-personnes pour les modifications de configuration de pipeline
  • Utiliser l’authentification OIDC au lieu d’identifiants à longue durée de vie
  • Scanner les artefacts de build pour du malware avant le déploiement
  • Isoler les environnements de build et rotationner les identifiants régulièrement

4. Sécurité des registres de packages

  • Activer la 2FA/2SV sur tous les comptes de registre de packages
  • Utiliser la vérification de provenance de packages (Sigstore, SLSA)
  • Surveiller les attaques par typosquatting et confusion de dépendances
  • Privilégier les éditeurs vérifiés et les dépôts officiels

5. Architecture Zero Trust

  • Supposer que tous les composants tierce peuvent être compromis
  • Mettre en œuvre la segmentation réseau pour limiter le rayon d’explosion
  • Utiliser la protection runtime (WAF, EDR, RASP) pour détecter un comportement anormal
  • Surveiller l’exfiltration de données et les connexions réseau inhabituelles

6. Gestion des risques fournisseurs

  • Réaliser des évaluations de sécurité régulières des fournisseurs critiques
  • Exiger des fournisseurs qu’ils maintiennent des SBOM et des certifications de sécurité
  • Inclure des clauses de sécurité de chaîne d’approvisionnement dans les contrats
  • Diversifier les fournisseurs critiques pour réduire les points de défaillance uniques

7. Préparation à la réponse aux incidents

  • Développer des playbooks spécifiques aux incidents de chaîne d’approvisionnement
  • Maintenir des sauvegardes hors ligne des dépendances critiques
  • Tester régulièrement les procédures de restauration
  • Coordination avec les ISAC industriels pour le partage de renseignement sur les menaces

8. Sécurité des projets open-source

  • Appliquer des exigences de revue de code pour tous les contributeurs
  • Utiliser CODEOWNERS et des règles de protection de branche
  • Implémenter un scan de sécurité automatisé dans CI
  • Publier des signatures cryptographiques pour les releases
  • Maintenir un SECURITY.md avec un processus de divulgation responsable

Concepts liés

  • software-architecture — Patterns d’architecture qui influencent le risque de chaîne d’approvisionnement
  • Zero Trust — Pratiques DevOps qui peuvent augmenter ou réduire le risque de chaîne d’approvisionnement
  • infrastructure-as-code — Outils IaC qui ont été ciblés dans des attaques par chaîne d’approvisionnement
  • containerization — Images container comme vecteur de chaîne d’approvisionnement
  • Ci Cd — Cadres de conformité adressant la sécurité de la chaîne d’approvisionnement
  • security-framework — Cadres comme NIST SSDF qui adressent le risque de chaîne d’approvisionnement
  • open-source — Projets open-source à la fois comme vecteur de risque et approche d’atténuation

Références