Sécurité de la supply chain logicielle

En mars 2024, un développeur curieux remarque que sa connexion SSH prend 500 ms de plus que d’habitude. En creusant, il découvre une backdoor planquée dans XZ Utils, un utilitaire de compression présent sur quasiment tous les serveurs Linux. Le code malveillant permettait une exécution de code à distance via SSH. Cette attaque sophistiquée a été préparée pendant deux ans par un contributeur devenu mainteneur du projet.

Bienvenue dans le monde des attaques supply chain : l’attaquant ne cible plus directement votre application, il compromet un composant en amont pour toucher tous ceux qui en dépendent.

Passer à l'action

Cette page explique les menaces. Pour un parcours pratique étape par étape, consultez Par où commencer.

Qu’est-ce qu’une attaque supply chain ?

Une attaque supply chain cible les composants utilisés pour construire un logiciel plutôt que le logiciel lui-même. L’idée est simple : compromettre un composant utilisé par 10 000 projets, c’est compromettre potentiellement 10 000 projets d’un coup.

Les 6 vecteurs d’attaque

Les attaquants exploitent six portes d’entrée principales :

1. Typosquatting — L’attaquant publie un package au nom quasi identique (lodahs au lieu de lodash). Une faute de frappe lors de l’installation suffit à compromettre votre projet.

2. Dependency confusion — Votre organisation utilise un package privé @company/auth. L’attaquant publie auth sur npm public en version 99.0.0. Certains gestionnaires de paquets privilégient le registre public.

3. Maintainer compromis — Un mainteneur épuisé abandonne son projet. L’attaquant le reprend, gagne la confiance de la communauté, puis injecte du code malveillant dans une mise à jour anodine.

4. CI/CD compromis — Les pipelines ont accès aux secrets et peuvent modifier le code déployé. Une action GitHub modifiée peut exfiltrer vos tokens ou injecter du code dans vos artefacts.

5. Vulnérabilités connues — Des CVE non patchées dans vos dépendances (Log4Shell, XZ Utils) offrent des portes ouvertes aux attaquants.

6. Images non signées — Sans signature, impossible de détecter si une image Docker a été modifiée entre sa création et son déploiement.

Pourquoi ces attaques fonctionnent

Les attaques supply chain exploitent des faiblesses structurelles de notre écosystème logiciel.

La confiance implicite est le cœur du problème. Quand vous tapez npm install, vous faites confiance à des centaines de mainteneurs que vous ne connaissez pas. Personne ne lit le code des 500 dépendances transitives avant de les installer.

L’effet de levier est considérable. Compromettre un seul package populaire comme lodash (200 millions de téléchargements/semaine) touche potentiellement des millions de projets. C’est bien plus rentable que d’attaquer une entreprise à la fois.

La détection est un cauchemar. Le code malveillant vient d’une source “légitime” — un mainteneur de confiance, un registre officiel. Il passe les revues de code parce que personne ne soupçonne une mise à jour mineure.

La surface d’attaque est immense. Un projet moderne embarque des centaines de composants tiers. Chacun est un point d’entrée potentiel. Et les dépendances ont elles-mêmes des dépendances.

Les attaquants jouent le temps long. L’attaquant de XZ Utils a contribué pendant deux ans avant d’injecter sa backdoor. Cette patience rend la menace quasi indétectable.

Menace persistante

Contrairement aux attaques classiques où l’urgence prime, les attaques supply chain sont patiemment préparées. L’attaquant investit des mois, voire des années, pour maximiser l’impact au moment opportun.

Qui attaque et pourquoi

Les profils d’attaquants

Les attaques supply chain attirent des acteurs variés, des opportunistes aux services de renseignement.

Les États-nations mènent les attaques les plus sophistiquées. L’attaque XZ Utils porte les marques d’une opération étatique : deux ans de préparation, code obfusqué, ciblage de l’infrastructure SSH. L’objectif ? Espionnage, sabotage, ou création d’accès persistants pour des opérations futures.

Les groupes criminels cherchent le profit direct. Le worm Shai-Hulud collectait credentials, clés SSH et wallets crypto. D’autres déploient du cryptomining ou préparent des ransomwares.

Les hacktivistes utilisent le “protestware” pour faire passer des messages politiques. En 2022, le mainteneur de node-ipc a saboté son propre package pour protester contre l’invasion de l’Ukraine, effaçant des fichiers sur les machines russes.

Les opportunistes exploitent le typosquatting à grande échelle. Ils publient des milliers de packages aux noms similaires à des packages populaires, espérant capturer des tokens d’authentification ou des variables d’environnement.

Ce qu’ils cherchent

Quel que soit l’attaquant, les objectifs se recoupent : credentials (tokens API, clés SSH), accès persistants (backdoors pour revenir), données sensibles (code source, secrets métier), ressources de calcul (cryptomining), et points de pivot pour attaquer d’autres cibles depuis votre infrastructure.

Comment ils attaquent

1. Empoisonnement de dépendances

L’attaquant publie un package malveillant qui ressemble à un package légitime.

Typosquatting : un nom proche qui piège les fautes de frappe.

npm install lodahs    # ❌ Malveillant (typo)
npm install lodash    # ✅ Légitime

Dependency confusion : un package public avec le nom d’un package privé interne. Les gestionnaires de paquets privilégient souvent le registre public.

# Votre package privé interne
@company/auth-utils

# L'attaquant publie sur npm public
auth-utils  # Version 99.0.0 — sera installée à la place

Maintainer takeover : reprise d’un package abandonné, puis injection de code malveillant lors d’une mise à jour anodine. Le mainteneur original a souvent disparu, personne ne vérifie.

2. Compromission des pipelines CI/CD

Les pipelines ont accès aux secrets et peuvent modifier le code déployé.

Actions GitHub compromises : une action modifiée exfiltre les secrets ou injecte du code dans les artefacts. C’est ce qui s’est passé avec `tj-actions/changed-files` en mars 2025.

Secrets dans les logs : un script malveillant affiche les variables sensibles dans les logs publics. Le code injecté ressemblait à echo "::debug::$NPM_TOKEN" — une ligne anodine qui exfiltrait les secrets vers les logs accessibles publiquement.

Runners partagés : sur des runners mutualisés, un job malveillant peut accéder aux données des jobs précédents (artefacts, cache, fichiers temp).

3. Attaques sur les registres

Compromission de comptes mainteneurs : sans 2FA, un simple phishing suffit à publier une version malveillante d’un package populaire.

Failles des registres : vulnérabilités permettant de modifier des packages sans authentification. Rare mais dévastateur.

4. Compromission d’infrastructure tierce

Rachat de domaines : un domaine légitime abandonné est racheté par une entité malveillante. C’est ce qui s’est passé avec Polyfill.io — 100 000 sites compromis.

CDN compromis : injection de code dans tous les fichiers distribués. Un changement sur le CDN touche instantanément tous les consommateurs.

Qui est concerné dans votre organisation

La sécurité supply chain n’est pas qu’un problème technique — elle implique toute l’organisation.

Les développeurs sont en première ligne. Chaque npm install, chaque nouvelle dépendance ajoutée au projet est une décision de sécurité. Les scripts postinstall s’exécutent sur leur machine avec leurs droits.

Les DevOps et SRE contrôlent le vecteur d’attaque n°1 : les pipelines CI/CD. Ils gèrent les secrets, les runners, les accès aux registres. Une erreur de configuration peut exposer tous les tokens de l’organisation.

Les architectes définissent les règles : quelles dépendances autoriser, quels registres utiliser, quelle surface d’attaque accepter. Leurs décisions structurent la posture de sécurité pour des années.

Le RSSI porte la responsabilité de la gouvernance. Avec le CRA qui arrive, il doit s’assurer que les processus sont en place : SBOM, évaluation des risques fournisseurs, notification d’incidents.

Le juridique entre dans la boucle avec les nouvelles réglementations. Les contrats clients exigent des SBOM, le CRA impose des obligations de conformité. Les sanctions peuvent atteindre 15 M€.

Les attaques marquantes 2024-2025

XZ Utils Backdoor (mars 2024)

CVE-2024-3094 — L’attaque supply chain la plus sophistiquée documentée.

Un contributeur nommé “Jia Tan” a gagné la confiance du mainteneur pendant deux ans. Il a introduit du code malveillant dans les versions 5.6.0 et 5.6.1 de liblzma. La backdoor modifiait sshd pour permettre une exécution de code à distance.

Impact potentiel : accès root à distance sur tous les serveurs Linux.

Leçons de XZ Utils

• La confiance open source repose sur peu de mainteneurs souvent épuisés
• Les attaques peuvent être préparées sur le très long terme
• Un comportement anormal (500 ms de latence) peut révéler une compromission
• Le code malveillant était caché dans les fichiers de test, pas dans le code principal

Polyfill.io CDN (juin 2024)

Le domaine `polyfill.io`, utilisé par 100 000+ sites web, a été racheté par une entité chinoise. Le nouveau propriétaire a modifié le code servi pour rediriger vers des sites de phishing.

Leçons de Polyfill.io

• Les CDN tiers sont un vecteur sous-estimé
• Un changement de propriétaire peut transformer un service légitime en menace
• Auto-héberger les ressources critiques réduit la surface d’attaque
• Cloudflare et Fastly ont dû créer des miroirs d’urgence

tj-actions/changed-files (mars 2025)

CVE-2025-30066 — Compromission en cascade d’actions GitHub.

L’attaque a commencé par `reviewdog/action-setup@v1`, puis s’est propagée à `tj-actions/changed-files`. Les attaquants ont modifié toutes les versions (v1 à v45) pour exfiltrer les secrets CI/CD dans les logs.

Impact : des milliers de dépôts exposés, dont Coinbase.

Leçons de tj-actions

• Les tags Git mutables (@v1) sont dangereux — un tag peut être modifié
• Toujours épingler sur un SHA immutable
• Une action compromise accède à tous les secrets du workflow
• Effet cascade : une action peut en compromettre d’autres

Shai-Hulud npm Worm (août-novembre 2025)

Un malware auto-réplicant a infecté des packages npm populaires. Le script `telemetry.js` collectait credentials, clés SSH et wallets crypto. Si l’accès GitHub était disponible, il s’auto-propageait vers d’autres packages.

Impact : 500+ packages compromis, milliers de machines infectées.

Leçons de Shai-Hulud

• Les scripts postinstall npm sont un vecteur majeur
• Un malware auto-réplicant peut se propager de package en package
• Les environnements de développement sont des cibles de choix
• La machine du développeur a souvent plus d’accès que la production

Le contexte réglementaire

Face à la multiplication des attaques, les régulateurs passent à l’action.

Le Cyber Resilience Act européen (2027)

Le CRA est le changement majeur à anticiper. Dès 2027, tout produit numérique vendu dans l’UE devra :

• Fournir un SBOM (inventaire des composants) à ses clients
• Être conçu “secure by design” avec documentation des choix de sécurité
• Proposer des mises à jour de sécurité pendant toute la durée de vie
• Notifier les vulnérabilités découvertes dans un délai défini

Sanctions : jusqu’à 15 M€ ou 2,5% du chiffre d’affaires mondial.

NIS2 : déjà en vigueur

Depuis 2024, les entreprises des secteurs critiques (énergie, santé, transport, finance…) doivent évaluer les risques de leurs fournisseurs et notifier les incidents sous 24h. Les dirigeants portent une responsabilité personnelle.

Aux États-Unis

L’Executive Order 14028 impose aux fournisseurs du gouvernement fédéral de produire des SBOM et d’attester leur conformité au NIST SSDF. Pas de conformité, pas de marché public.

Frameworks volontaires

Trois référentiels guident les bonnes pratiques : SLSA (4 niveaux de maturité pour la chaîne de build), NIST SSDF (pratiques de développement sécurisé), et OpenSSF Scorecard (score 0-10 pour évaluer les projets open source avant adoption).

Les erreurs qui coûtent cher

Erreurs critiques

Chaque attaque majeure révèle des erreurs évitables. Ces patterns se répètent systématiquement — les éviter divise drastiquement la surface d’attaque.

Erreur	Conséquence	Incident
Tags mutables (@v1)	Compromission silencieuse	tj-actions 2025
Dépendances transitives ignorées	Vulnérabilité cachée	Log4Shell
Scripts postinstall non audités	Code arbitraire exécuté	Shai-Hulud
CDN tiers pour scripts	Injection de code	Polyfill.io
Un seul mainteneur	Takeover	XZ Utils
Secrets en variables CI	Exfiltration via logs	tj-actions

Glissez pour voir

Ce qu’il faut retenir

1. La confiance est le problème : chaque dépendance est un acte de foi
2. L’effet de levier est énorme : un composant compromis = milliers de victimes
3. Les attaquants jouent le temps long : infiltration pendant des années
4. Les pipelines CI/CD sont la cible n°1 : accès aux secrets et au code
5. La détection est difficile : le code malveillant vient de sources “légitimes”
6. La réglementation arrive : CRA 2027 impose des SBOM et des processus

Passer à l'action

Maintenant que vous comprenez les menaces, consultez Par où commencer pour un parcours pratique en 4 niveaux.

Opérationnaliser : les 3 piliers d’exécution

Au-delà de la compréhension des menaces, trois domaines structurent votre posture opérationnelle supply chain. Ces piliers transforment les concepts (SLSA, SBOM, Sigstore) en contrôles bloquants et processus exécutables.

Programme end-to-end

Ces trois piliers complètent le parcours pratique en 4 niveaux. Ensemble, ils forment un programme complet : comprendre les menaces → construire les contrôles → imposer l’enforcement → réagir aux incidents.

Pour approfondir

Ressources internes

Par où commencer Parcours pratique en 4 niveaux pour sécuriser votre supply chain

Framework SLSA Comprendre les 4 niveaux de maturité SLSA

SBOM Inventorier vos composants logiciels

Sécurité GitHub Actions Protéger vos pipelines CI/CD

Ressources externes

• CISA - Securing the Software Supply Chain
• SLSA Framework
• OpenSSF Scorecard
• OWASP Top 10 CI/CD Security Risks
• EU Cyber Resilience Act

×

📖 Voir la documentation →