Attaques par supply chain : quand vos dépendances logicielles deviennent votre plus grande faille

Vous avez sécurisé votre infrastructure, mis en place votre pare-feu, formé vos équipes au phishing. Et pourtant, l’attaque arrive par un angle mort : une bibliothèque open source que vous utilisez depuis des années, un package NPM mis à jour la nuit dernière, un outil de build partagé par des milliers de développeurs. C’est le principe des attaques par supply chain et elles sont en pleine explosion.

Ces attaques ne ciblent pas directement votre organisation. Elles visent un maillon de votre chaîne d’approvisionnement logicielle pour atteindre, par rebond, toutes les organisations qui en dépendent. La propagation peut être quasi instantanée : un package compromis disponible quelques heures suffit à infecter des milliers d’environnements de développement à travers le monde.

Des acteurs majeurs de la tech française en ont récemment fait les frais, une illustration concrète que personne n’est à l’abri, quelle que soit la maturité supposée de ses pratiques de développement.

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

Une attaque par supply chain (ou attaque de la chaîne d’approvisionnement logicielle) consiste à cibler non pas directement une organisation, mais un composant tiers qu’elle utilise : une bibliothèque open source, un outil de build, un plugin, un package NPM ou PyPI, voire le poste de travail d’un développeur.

L’exemple récent de Mistral AI est à ce titre particulièrement parlant. En mai 2026, le groupe TeamPCP a compromis TanStack, une bibliothèque open source tierce utilisée par la start-up française, pour publier automatiquement des versions vérolées de ses SDK sur NPM et PyPI. C’est un poste de développeur compromis qui a servi de point d’entrée. La propagation a été quasi immédiate : plus de 170 packages npm et 2 packages PyPI touchés, 404 versions malveillantes diffusées. Les packages vérolés sont restés disponibles moins de 3 heures sur PyPI, et pourtant téléchargés par des milliers de développeurs. Jusqu’à 5 Go de dépôts internes auraient été exfiltrés et mis en vente pour 25 000 dollars.

L’efficacité de ce type d’attaque repose sur la confiance implicite que nous accordons à nos dépendances. On ne questionne pas systématiquement le code d’une bibliothèque qu’on utilise depuis des années. C’est précisément ce que les attaquants exploitent.

Avec le Cyber Resilience Act, la chaîne d’approvisionnement devient une obligation légale

Face à l’explosion de ces menaces, l’Union européenne a adopté le Cyber Resilience Act (CRA), entré en vigueur en décembre 2024, avec une application progressive jusqu’en décembre 2027.

Ce règlement impose des exigences de cybersécurité à tous les produits comportant des éléments numériques mis sur le marché européen : logiciels, matériels connectés, composants IoT, SDK, bibliothèques commerciales. Il s’applique aux fabricants, importateurs et distributeurs de ces produits.

Ce que le CRA change concrètement pour les fournisseurs numériques

• Dès septembre 2026 : obligation de notifier les vulnérabilités activement exploitées et les incidents significatifs via la plateforme unique de l’ENISA, avec transmission automatique au CERT-FR.
• D’ici décembre 2027 : les produits non conformes ne pourront plus être commercialisés dans l’UE.
• Le SBOM (Software Bill of Materials) devient obligatoire : chaque fournisseur doit être en mesure de produire un inventaire complet et à jour de tous ses composants logiciels.
• La sécurité s’impose sur tout le cycle de vie du produit : de la conception à la fin de support, en passant par les mises à jour et la gestion des vulnérabilités.

Les sanctions en cas de non-conformité peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.

Le message du CRA est clair : la cybersécurité de vos clients dépend de la solidité de votre chaîne d’approvisionnement. Vous en êtes désormais légalement responsable.

Les bonnes pratiques pour sécuriser sa supply chain logicielle

Cartographier toutes ses dépendances

Vous ne pouvez pas protéger ce que vous ne voyez pas. La première étape est de produire et maintenir un SBOM (Software Bill of Materials) exhaustif : la liste de tous les composants logiciels utilisés, avec leur version, leur origine et leur statut de maintenance.

Gérer activement les dépendances

• Vérifier les signatures et l’intégrité de chaque package avant intégration (checksums, signatures GPG).
• Surveiller les CVE (Common Vulnerabilities and Exposures) associées à vos composants en temps réel
• Limiter le périmètre des dépendances : moins vous avez de composants tiers, moins vous avez de surface d’attaque.
• Éviter les packages abandonnés ou peu maintenus : un composant sans mise à jour depuis 18 mois est une porte d’entrée potentielle.

Utiliser des serveurs miroirs et des recettes d’approvisionnement contrôlées

Plutôt que de consommer directement depuis les registres publics (NPM, PyPI, Maven…), privilégiez des dépôts internes ou des miroirs privés (Nexus, Artifactory, AWS CodeArtifact). Cela permet de :

• Valider et approuver chaque version de package avant qu’elle ne soit disponible dans vos pipelines.
• Éviter les attaques de type dependency confusion ou typosquatting.
• Garantir la reproductibilité des builds dans le temps.

Des recettes de build assurent que chaque environnement utilise exactement les mêmes versions, sans résolution dynamique qui pourrait introduire une version compromise.

Pour les équipes de développement : l’hygiène DevSecOps est non négociable

L’incident Mistral a également mis en lumière une réalité souvent sous-estimée : le poste du développeur est un vecteur d’attaque majeur. Les tokens récupérés sur la machine compromise ont suffi à propager un malware dans plusieurs packages internes.

Revoir l’ensemble du pipeline CI/CD

• Principe du moindre privilège partout : chaque étape du pipeline ne doit avoir accès qu’aux ressources strictement nécessaires à son exécution. Un job de build n’a pas besoin de droits de déploiement en production.
• Révocation systématique et rotation des tokens : les tokens d’accès (GitHub Actions, NPM, PyPI, cloud providers) doivent avoir une durée de vie limitée et être révoqués dès qu’ils ne sont plus nécessaires. Dans l’incident Mistral, la rapidité avec laquelle les tokens ont été révoqués a limité l’ampleur de la compromission.
• Séparation stricte des environnements : dev, staging et production ne doivent jamais partager les mêmes credentials.
• Signature des artefacts de build : signez vos images Docker, vos packages et vos releases. Un artefact non signé ne devrait pas pouvoir passer en production.

Appliquer une hygiène CICD de bout en bout

• Analyse statique du code (SAST) et analyse des dépendances (SCA) intégrées à chaque pull request.
• Scan des images de conteneurs avant tout déploiement.
• Revue de code systématique pour toute modification touchant aux dépendances ou à la configuration du pipeline.
• Environnements de build éphémères : un runner CI/CD qui ne persiste pas entre les jobs ne peut pas être compromis à long terme.
• Journalisation et alerting sur toute publication de package ou modification des accès.