Au cours du deuxième trimestre 2026, Aikido Intel a analysé environ 7,5 millions de versions de paquets. Grâce à nos systèmes automatisés et à nos chercheurs, nous avons identifié 19 500 paquets malveillants. Les pirates exploitent les dépendances open source pour s’introduire dans les logiciels, et les attaques de type « attaques de la chaîne d’approvisionnement » ont connu une forte recrudescence à partir de la mi-2025. Des paquets populaires tels qu’axios et des outils de sécurité comme Trivy et Checkmarx ont été compromis.
Ce guide présente les meilleures pratiques en matière de sécurité de la chaîne d'approvisionnement qui auraient permis d'empêcher les attaques survenues au cours des 18 derniers mois. Si vous souhaitez approfondir le sujet, consultez la liste de contrôle pratique pour vous protéger contre les attaques de type « attaques de la chaîne d’approvisionnement ». Cette liste de contrôle complète couvre 30 mesures de sécurité portant notamment sur les conteneurs et le renforcement de la sécurité des infrastructures informatiques (CI), classées par ordre de priorité afin que vous sachiez par où commencer.
{{cta}}
Bloquez le logiciel malveillant avant qu'il ne s'installe
Appliquer un délai minimum de 48 heures pour l'âge du colis
Une période de délai de sécurité bloque toute version récemment publiée. La plupart des versions compromises sont signalées et retirées dans les heures qui suivent leur publication, ce qui signifie qu’un délai de 48 heures permet de les intercepter. Ce délai crée un intervalle entre la publication et l’adoption. Il convient de l’appliquer au niveau du registre privé ou du gestionnaire de paquets. npm dispose de âge minimum de sortie depuis la version 11.10.0, et Yarn et Bun intègrent tous deux leurs propres systèmes de contrôle d'âge.
Bloquer les hooks post-installation avec « ignore-scripts »
Il n'est pas nécessaire d'utiliser un paquet pour exécuter du code sur votre machine ; il suffit de l'installer. Lorsque vous exécutez la commande « npm install », npm exécute, avec vos droits d'accès, tout script post-installation rédigé par l'auteur du paquet. Pour désactiver les scripts d'installation, utilisez la commande : --ignore-scripts et ajoutez à la liste blanche les quelques paquets qui ont réellement besoin de compiler quelque chose. Appliquez le même paramètre dans l'environnement CI et sur les machines des développeurs, afin de détecter les identifiants stockés sur l'ordinateur portable.
Les paramètres par défaut de l'écosystème évoluent dans la bonne direction
pnpm a désactivé par défaut les scripts d'installation des dépendances dans la version 10 en janvier 2025, puis a activé par défaut un délai d'attente de 24 heures dans v11 en avril 2026. npm v12 livré le 8 juillet 2026 avec les scripts d'installation des dépendances désactivés par défaut, bien que vos propres scripts continuent de s'exécuter, et il n'y a pas de délai d'attente par défaut, vous pouvez donc toujours définir âge minimum de sortie vous-même. La mise à jour de votre gestionnaire de paquets est le moyen le plus économique de prendre en charge une partie de ces deux contrôles. Les équipes utilisant des versions plus anciennes ou d’autres écosystèmes doivent appliquer les paramètres explicites indiqués ci-dessus. Ce qu’un délai de réflexion aurait pu empêcher
Le axios l'attaquant a publié un leurre inoffensif, plain-crypto-js@4.2.0, le 30 mars, puis a remplacé le fichier par le fichier malveillant plain-crypto-js@4.2.1 à 23 h 59 UTC. Le système de détection automatique l'a signalé six minutes plus tard. axios@1.14.1 a été mis en ligne le 31 mars à 00 h 21 UTC, et axios@0.30.4 Cela s'est produit à 1 h. npm a supprimé les deux versions d'axios environ trois heures après la mise en ligne de la première. Un délai de 48 heures aurait permis aux équipes d'éviter les deux, avec environ 45 heures d'avance.
CanisterWorm a republié des versions de correctifs incrémentielles de tous les paquets gérés par ses victimes, totalisant plus de 60 paquets en 24 heures. La plupart ont été signalés quelques minutes après leur publication ; un filtre de 48 heures les aurait donc empêchés d'atteindre votre résolveur. Au moins l'un d'entre eux est resté indétecté pendant environ 53 heures, ce qui explique pourquoi ce filtre est plus efficace lorsqu'il est associé à un système de détection des logiciels malveillants au moment de l'installation.
Fixez tout ce qui risque d'être emporté par le vent
Validez un fichier de verrouillage et appliquez-le dans votre pipeline
Un fichier de verrouillage (lockfile) enregistre la version exacte et le hachage d’intégrité de chaque dépendance, y compris les dépendances transitives. L’appliquer signifie que votre pipeline exécute la commande « npm ci » plutôt que « npm install », car « npm ci » effectue l’installation en se basant strictement sur le fichier de verrouillage et échoue immédiatement si le fichier package.json s’en est écarté. Tous les autres écosystèmes disposent d’un mode similaire sous un nom différent, comme --fichier-de-verrouillage-gelé dans pnpm, --immuable dans « Yarn », --verrouillé dans la rubrique « Cargo », et --require-hashes dans pip. Il faudrait en faire une vérification obligatoire avant « merge » afin que cette règle s'applique à toute l'équipe.
Associez votre pipeline aux SHA des commits
Toutes les plateformes de CI vous permettent d’importer des dépendances, et dans la plupart des cas, vous les référencez à l’aide d’une balise ou d’un nom de branche. Il s’agit dans les deux cas de pointeurs que la personne qui contrôle le dépôt source peut déplacer à tout moment. Le verrouillage sur le SHA d’un commit élimine tout risque de dérive, car un SHA fait référence à un arbre de code spécifique et ne peut pas être redirigé. GitHub Actions, GitLab, Buildkite et Jenkins acceptent tous un SHA à la place d’une balise. CircleCI fonctionne différemment, car les versions d’orb publiées sont immuables une fois mises en ligne ; une version exacte convient donc parfaitement.
L'inconvénient est que vous ne recevrez plus automatiquement les correctifs en amont ; vous devrez donc associer ce correctif à un bot qui ouvre des PR pour faire évoluer le SHA. Renovate prend en charge Actions et GitLab, entre autres, et peut effectuer pour vous la conversion initiale des balises en SHA. Dependabot maintient à jour les épingles d’actions existantes, mais ne fonctionne qu’avec GitHub Actions.
Épingler des images de base dans les résumés
Une balise d'image de conteneur est également un pointeur modifiable. « node:22-alpine » pointe vers une image différente ce mois-ci par rapport au mois dernier, et rien dans votre Dockerfile n'indique sur quelle image vous avez basé votre compilation.
Fixez la ligne « FROM » à un résumé afin que la compilation soit reproductible et que les modifications en amont nécessitent votre validation. Mettez ensuite en place une compilation automatique, car un résumé fixé signifie également que vous ne recevrez plus de correctifs en amont tant que vous ne l'aurez pas délibérément déplacé.
Qu'est-ce qui aurait pu empêcher cela ?
En mars 2025, les attaquants ont compromis le tj-actions/changed-files Action a redirigé toutes les balises de version vers un commit malveillant qui divulguait des secrets de CI dans les journaux de workflow. Environ 23 000 dépôts y faisaient référence, et dans les dépôts publics, ces journaux étaient accessibles à tous.
Chaque workflow faisant référence à un tag a récupéré le code malveillant lors de son exécution suivante. Les dépôts dont le tag était associé à un SHA de commit n'ont pas été affectés.
Sécuriser l'accès et l'identité
Jetons de portée
Un jeton doté de droits de publication à l'échelle de l'organisation présente un risque, car toute personne qui en prend possession peut publier n'importe quel élément dont vous êtes propriétaire. Utilisez des jetons à accès granulaire, limités à des dépôts et des paquets spécifiques, et attribuez un jeton distinct à chaque pipeline plutôt que d'en partager un seul entre les exécuteurs et les machines. Renouvelez-les selon un calendrier défini et immédiatement en cas de soupçon, et révoquez-les dès qu'une personne quitte un projet.
Un ancien développeur de CrowdSec avait conservé un accès à GitHub afin de terminer certains travaux, et son ordinateur portable a été compromis lors de l'attaque TanStack. Un pirate a utilisé le jeton de cette machine pour cloner 170 dépôts privés de CrowdSec en environ neuf minutes. L'entreprise ne s'en est aperçue que quatre mois plus tard, lorsque le code est apparu sur un forum.
Migrer les comptes des responsables vers FIDO2 ou les clés d'accès
Un mot de passe à usage unique basé sur le temps (TOTP) vaut mieux que rien, mais il peut faire l’objet d’une attaque par hameçonnage. Un pirate capture le code sur une fausse page de connexion convaincante et le réutilise sur le site authentique dans le délai de trente secondes, ce qui suffit pour prendre le contrôle d’un compte sans avoir recours à aucun logiciel malveillant. FIDO2 et les clés d'accès sont cryptographiquement liées au domaine légitime. Si vous gérez un paquet largement utilisé, veillez à ce que l'adresse e-mail associée au compte soit à jour et surveillez-la attentivement, car npm bloque les comptes à fort impact pendant 72 heures après un changement d'adresse e-mail ou une récupération de l'authentification à deux facteurs (2FA), et envoie l'alerte à l'ancienne adresse.
Considérez la machine de développement comme un environnement de production
Installez un système de détection des menaces sur chaque poste de travail des développeurs
Un ordinateur portable de développeur contient du code source, des identifiants d’ cloud , des jetons de publication et une session authentifiée vers la majeure partie de votre infrastructure ; c’est pourquoi les terminaux des développeurs constituent désormais l’une des principales cibles de l’ attaques de la chaîne d’approvisionnement. Les outils EDR traditionnels détectent les menaces une fois qu’elles sont déjà en cours d’exécution, ce qui laisse une fenêtre d’opportunité pendant laquelle des identifiants peuvent être volés ou des paquets malveillants installés avant qu’une alerte ne se déclenche.
Recherchez des outils de gestion des terminaux qui analysent les installations npm et pip au moment même où elles ont lieu, et qui permettent d'appliquer des règles lors de l'installation, telles que des délais minimaux pour l'âge des paquets ou des listes d'autorisations pour les extensions d'IDE et les modules complémentaires de navigateur.
Appliquer de manière centralisée la liste blanche des extensions
Les extensions IDE et les modules complémentaires de navigateur s'exécutent avec des privilèges réels et se mettent à jour sans demander l'autorisation. Tenez à jour une liste approuvée et diffusez-la à partir d'une politique centrale. Notre guide sur la sécurité des modules complémentaires de navigateur aborde plus en détail les aspects spécifiques aux navigateurs.
Ce que cela aurait empêché
En avril 2026, Aikido a découvert une fausse extension WakaTime sur OpenVSX contenant un binaire natif qui se chargeait avant toute logique d’extension légitime, récupérait une deuxième charge utile depuis une page GitHub Releases, puis l’installait de force dans tous les éditeurs compatibles de la machine en utilisant le programme d’installation en ligne de commande propre à chaque éditeur. Une seule installation a suffi pour infecter VS Code, Cursor, Windsurf et VSCodium. Une liste blanche centralisée aurait permis d’empêcher cela, car une fausse extension WakaTime publiée par un compte inconnu ne figurerait pas sur la liste des extensions approuvées.
La limite d'une liste blanche réside dans le fait qu'elle n'est efficace que tant qu'une extension approuvée reste intacte. GlassWorm a également compromis des extensions légitimes que de nombreuses équipes auraient approuvées, et celles-ci se mettent à jour sans qu'aucun fichier de comparaison ne soit disponible pour être examiné ; c'est pourquoi la couche de contrôle au moment de l'installation est tout aussi importante que la liste elle-même.
Protégez vos agents
Définir les autorisations au moment de la configuration et mettre en place un environnement de test pour l'exécution
Un agent capable d'exécuter des commandes shell arbitraires et d'accéder à votre base de données de production n'est qu'à un clic d'un outil compromis d'une violation totale. N'accordez que les autorisations strictement nécessaires à la tâche concernée, et vérifiez-les comme vous le feriez pour un compte de service. Exécutez ensuite l'agent dans un environnement isolé doté de contrôles de sortie réseau, afin qu'un agent compromis ne puisse toujours pas accéder à quoi que ce soit en dehors des limites que vous avez définies.
La délimitation du champ d'action au moment de la configuration et le sandboxing en exécution apportent chacune une solution à une partie du problème. La première limite ce que l'agent est autorisé à demander. La seconde limite ce qui se passe lorsqu'un événement pousse l'agent à en demander davantage.
Considérer les serveurs MCP comme des dépendances
Les serveurs MCP présentent les mêmes risques liés à la chaîne d'approvisionnement que toute autre dépendance ; vous ne devez donc installer des serveurs MCP qu'à partir de sources vérifiées, telles que le registre officiel MCP sur GitHub. Pour les serveurs MCP distribués via npm, fixez-les à l'aide d'un hachage d'intégrité dans votre fichier de verrouillage. Pour ceux basés sur Git, fixez-les à un SHA de commit complet plutôt qu'à une branche ou à une balise. Vérifiez que le dépôt est maintenu et que l’éditeur est connu avant de procéder à l’installation. Si vous vous approvisionnez à partir d’un registre, traitez un serveur MCP non vérifié de la même manière que vous le feriez pour un paquet npm non vérifié.
En septembre 2025, un paquet nommé « postmark-mcp » est apparu sur npm, se faisant passer pour le serveur MCP officiel qu’ActiveCampaign gère pour le service de messagerie Postmark. Son rôle était de permettre à un assistant IA d’envoyer des e-mails via votre compte Postmark, et pendant quinze versions, c’est exactement ce qu’il a fait, sans rien d’autre. La version 1.0.16 a ajouté une ligne de code. Chaque e-mail envoyé par le serveur était mis en copie cachée à une adresse contrôlée par le pirate, via le compte même de la victime. Ainsi, les réinitialisations de mot de passe, les factures et tout autre élément qu’un agent était chargé d’envoyer étaient également transmis à un inconnu.
Traiter toute entrée non fiable parvenant à un agent comme une exécution de code
AikidoLes recherches menées par PromptPwnd ont constitué la première démonstration concrète confirmée d’une injection de prompt compromettant des pipelines CI/CD¹, affectant au moins cinq entreprises du classement Fortune 500. Un titre de ticket malveillant intégré à un workflow de l’interface CLI de Gemini a conduit l’agent à écrire des secrets du référentiel dans un fil de discussion public du ticket en utilisant ses propres droits d’accès légitimes.
Vérifiez tout workflow qui transmet le titre d'un ticket ou la description d'une pull request à une invite d'agent. Considérez les sorties de l'agent qui aboutissent à une commande shell ou à l'écriture dans un fichier comme non fiables jusqu'à ce qu'elles soient validées.
Détecter les paquets malveillants au moment de leur installation, puis à nouveau dans le référentiel
Les agents de codage inventent des noms de paquets qui semblent plausibles mais qui n'existent pas, et les pirates ont commencé à enregistrer ces noms à l'avance et à attendre. L'agent l'installe sans se poser de questions, car le nom correspond à ce qu'il s'attendait à trouver.
Pour empêcher le « slopsquatting », il faut mettre en place une détection des logiciels malveillants à deux niveaux. Le premier se situe sur la machine, au moment de l’installation : il permet de détecter l’agent en train de récupérer des données pendant une session et correspond au même contrôle que celui décrit précédemment dans la section consacrée à l’installation. Le second se situe dans le dépôt, où une pull request introduisant une nouvelle dépendance est vérifiée avant que quiconque ne la fusionne. Cette deuxième couche est nécessaire car un nom de paquet erroné peut s’introduire dans la base de code depuis la machine d’un développeur sur laquelle le contrôle au moment de l’installation n’a jamais été configuré.
Prévoyez un plan pour la première heure suivant une attaque de logiciel malveillant
Enregistrer les journaux d'audit
Transmettez le journal d'audit de votre organisation à un système SIEM. Les événements les plus importants sont les modifications apportées au registre et l'utilisation des jetons, car c'est là qu'une compromission se manifeste avant toute autre chose. Pour savoir précisément sur quoi déclencher des alertes, consultez notre liste de contrôle de sécurité GitHub Actions, qui répertorie les événements à surveiller.
L'attaquant d'Axios a effectué la publication manuellement à l'aide d'un jeton npm à longue durée de vie récupéré sur la machine compromise du responsable du projet ; il n'y avait donc aucune connexion suspecte à repérer. C'est l'historique du registre qui a permis aux équipes d'intervention d'établir la chronologie des événements : l'adresse e-mail du compte a été remplacée par une adresse contrôlée par l'attaquant, puis deux versions ont été publiées à 39 minutes d'intervalle, toutes deux horodatées.
Générer des SBOM signées afin d'apporter une réponse à la question de l'exposition
Lorsqu’un nouveau CVE est publié ou qu’un paquet compromis est découvert, les équipes qui ne disposent pas d’un fichier « software bill of materials » (SBOM) à jour passent des heures à tracer manuellement les dépendances pour déterminer si elles sont concernées. Générez-en un pour chaque artefact de build, y compris les dépendances transitives, car la plupart des compromissions se situent à plusieurs niveaux de profondeur. La charge utile d’Axios est parvenue via un paquet que personne n’avait explicitement installé. Signez l’ SBOM e au moment de la compilation afin qu’il soit cryptographiquement lié à la compilation qui l’a produit, et stockez-le avec l’artefact dans votre registre pour que les deux restent synchronisés.
Entraînez-vous à appliquer les schémas de rotation avant d'en avoir besoin
Documentez quels identifiants font l'objet d'une rotation pour chaque pipeline et qui est habilité à effectuer cette rotation pour chaque type. Indiquez ensuite comment vous vérifiez qu'une rotation a bien été menée à bien, puis effectuez un test. Déterminez à l'avance votre solution de secours. GitHub Enterprise prend en charge la révocation en masse des identifiants pour un utilisateur compromis ou pour l'ensemble des utilisateurs de l'entreprise en une seule fois. Cette méthode est radicale, mais elle est préférable à une rotation service par service lorsque vous ne savez pas encore quelle est l'étendue de la compromission.
Comment la solution de sécurité « Aikido » contribue à vous protéger contre attaques de la chaîne d’approvisionnement
Aikido La sécurité couvre les couches « install-time » et « repository » décrites dans cet article. Son système de détection fonctionne sur un serveur Intel « Aikido », qui analyse tous les nouveaux paquets en six minutes en moyenne et signale souvent les paquets malveillants dans l'heure ou les deux minutes suivant leur publication.
La protection des appareils couvre les éléments installés sur les machines des développeurs et bloque les paquets et extensions malveillants au sein de l'entreprise. Safe Chain est la version gratuite et open source destinée aux particuliers, qui bloque les paquets malveillants au moment de leur installation.
La même détection «Aikido » d’Intel s’applique à vos dépôts ; ainsi, une dépendance malveillante qui parvient jusqu’à une pull request est signalée avant que quiconque ne la fusionne, y compris un nom de paquet fantôme provenant d’une machine dépourvue de protection au moment de l’installation. SAST couvre la couche de configuration, en signalant les entrées non fiables qui parviennent à l’invite d’un agent, ce qui correspond au modèle PromptPwnd.
