Red team vs blue team
Les attaquants ciblent rarement votre entreprise. Ils ciblent le paquet, l'Action ou l'outil de build dont dépendent les entreprises du monde entier, puis essaient l'exploit sur toutes à la fois. Ils n'ont pas besoin de votre liste de dépendances. Vous, si.
Une attaque de la chaîne d'approvisionnement logicielle compromet un élément à partir duquel un produit est construit, comme un paquet open source, un composant CI/CD ou le système de build, au lieu d'attaquer directement le produit. Les logiciels modernes sont pour l'essentiel du code écrit par d'autres : la majeure partie vient de paquets open source, et la plupart de ceux-ci sont des dépendances transitives que personne dans l'équipe n'a choisies. Compromettez un composant largement utilisé, et vous atteignez toutes les organisations qui s'appuient sur lui.
Cela change la façon dont les attaquants choisissent leurs cibles. Ils n'étudient pas les dépendances d'une entreprise. Ils choisissent un paquet ou un outil très répandu, puis l'exploitent partout et regardent ce qui répond.
Une faille dans un paquet open source populaire est divulguée, et les attaquants l'exploitent dans tous les produits qui livrent la version vulnérable, généralement en tant que dépendance transitive que personne n'a choisie directement.
Un attaquant prend le contrôle d'un compte de mainteneur, ou un ver vole des tokens de publication, et publie une version empoisonnée d'un paquet de confiance. Elle s'exécute dès qu'un build l'installe, comme avec le ver npm Shai-Hulud.
Un contributeur gagne peu à peu la confiance d'un projet open source, puis glisse du code malveillant dans une release que reprennent les distributions et les produits en aval, comme avec la porte dérobée de xz utils.
Des paquets aux noms proches de ceux de paquets populaires profitent des fautes de frappe. La confusion de dépendances va plus loin : un paquet public portant le même nom qu'un paquet interne d'une entreprise est installé à sa place.
Une GitHub Action ou un autre outil de build est détourné, et chaque pipeline qui l'utilise exécute le code de l'attaquant avec ses secrets à portée de main, comme avec tj-actions et Codecov.
Le build lui-même est modifié, ou l'artefact est substitué entre le build et le déploiement : un arbre source sain produit alors tout de même une release compromise, comme avec SolarWinds.
SolarWinds est l'attaque de la chaîne d'approvisionnement la plus connue : du code malveillant inséré au build et livré aux clients comme une mise à jour normale. Les attaques les plus récentes visent plutôt les registres de paquets et les pipelines CI, où un seul paquet ou une seule Action compromis atteint tous les builds qui l'utilisent. Du plus récent au plus ancien :
Un ver auto-propagatif qui s'exécute à l'installation d'un paquet npm infecté, vole des tokens npm, GitHub et cloud, et publie des versions infectées des autres paquets de la victime. La plupart des infections se sont produites en CI.
Comment vérifier vos builds →La CISA a indiqué que toutes les versions de cette GitHub Action populaire avaient été compromises pendant trois jours, avec des secrets exposés dans les logs de workflow. Les workflows qui la référençaient par tag ont exécuté le code de l'attaquant.
Andres Freund a découvert une porte dérobée dans les versions 5.6.0 et 5.6.1 de xz après avoir remarqué que les connexions SSH consommaient trop de CPU. Elle avait été introduite dans le projet amont lui-même.
Une faille dans Apache Log4j 2 permettait à un attaquant contrôlant un message journalisé d'exécuter du code arbitraire, avec un score CVSS de 10.0. Pour la plupart des équipes, la difficulté a été de trouver quelles applications contenaient log4j-core, généralement en tant que dépendance d'une dépendance.
Des attaquants ont modifié le script Bash Uploader que les équipes exécutaient dans leurs pipelines CI, afin qu'il envoie l'environnement CI, y compris les identifiants, tokens et clés, à un serveur extérieur à l'infrastructure de Codecov. Cela a fonctionné sans être remarqué du 31 janvier jusqu'au signalement d'un client, le 1er avril.
Des attaquants disposaient depuis longtemps d'un accès dissimulé au processus de build de SolarWinds Orion et ont inséré du code malveillant dans les releases 2019.4 à 2020.2.1 HF1 d'Orion, que les clients ont installées comme des mises à jour normales. La CISA a publié une directive d'urgence en réponse.
Red team vs blue team
Chaque étape avec les mots de l'attaquant, et la défense qui y répond.
Étape 1 sur 3
Inutile de connaître la cible. Choisissez le paquet, et les cibles se désignent d'elles-mêmes.
Red team
Vous n'avez pas besoin de leur lockfile. Les paquets populaires se trouvent au fond de l'arbre transitif de presque tout, et la plupart des équipes ne savent pas dire lesquels elles livrent. Des indices publics réduisent le champ : versions dans les bundles JavaScript et les en-têtes HTTP, dépôts publics et images de conteneur. Et tout ce que leur build récupère en dehors du lockfile, comme le binaire téléchargé par un script postinstall ou les couches sous leur image de base, leur scanner ne l'a jamais vu : personne ne le corrige donc.
Blue team
CRACI voit le trafic qui entre dans chaque build et enregistre chaque paquet et fichier récupéré, y compris les dépendances cachées que les outils basés sur les lockfiles manquent, à tous les niveaux de l'arbre transitif. Votre SBOM vient du build qui a été livré : vous disposez donc de la liste dont un attaquant n'a jamais eu besoin, avant que quiconque se mette à chercher.
SBOM au build →Red team
Un nouvel avis de sécurité vous dit exactement quelles versions sont vulnérables. Construisez l'exploit, scannez tout ce qui répond et laissez le scan vous dire qui ils sont. Vous commencez le jour même, pendant que leur équipe demande encore « sommes-nous touchés ? » dans un fil Slack.
Blue team
CRACI réévalue en continu les SBOM surveillées par rapport aux nouvelles données de vulnérabilité. L'historique des builds montre quels builds contenaient la dépendance vulnérable, directe ou transitive : vous savez ainsi où elle a été livrée et pendant combien de temps.
Sommes-nous touchés ? →Étape 2 sur 3
Exploitez la faille avant qu'elle soit corrigée, ou oubliez la faille et empruntez leur pipeline.
Red team
L'IA transforme un avis de sécurité et un diff de correctif en attaque fonctionnelle avant que leur équipe sécurité ait trié le ticket. La divulgation est votre coup d'envoi. Leur planification de sprint a lieu la semaine prochaine.
Blue team
Les gates de politique peuvent bloquer tout build qui contient une CVE précise : la version vulnérable cesse donc d'être livrée dès que vous le décidez, quelle que soit sa profondeur dans l'arbre.
Remédiation des CVE →Red team
Les workflows font confiance à des tags comme @v4, et les tags peuvent être déplacés. Compromettez une GitHub Action populaire et chaque workflow qui l'utilise exécute votre code, avec ses secrets à portée de main.
Blue team
CRACI enregistre les GitHub Actions exécutées par un workflow dans la SBOM du build, épinglées au commit réellement exécuté. Lorsqu'une Action est compromise, vous voyez quels builds ont exécuté le mauvais code au lieu de le deviner à partir d'un tag.
Checklist de sécurité CI/CD →Étape 3 sur 3
Prenez les secrets et restez pour la suite.
Red team
Une release de paquet malveillante exécute son script d'installation dans leur build, là où se trouvent les tokens et les identifiants cloud. Les runners CI peuvent généralement atteindre tout Internet : les secrets partent donc vers votre serveur avant que quiconque sache que le paquet est mauvais.
Blue team
Une politique de trafic sortant en refus par défaut laisse un build atteindre ses sources de paquets et ses cibles de publication, et bloque tout le reste. Un malware qui envoie vos secrets vers l'hôte d'un attaquant est bloqué, même en tant que patient zéro d'une attaque que personne n'a encore vue, et vous recevez une alerte sur la violation de politique.
Politiques de trafic sortant →Red team
Les runners auto-hébergés à longue durée de vie sont un cadeau : déposez quelque chose dans le workspace ou le cache d'outils et attendez que le job suivant, et le prochain lot de secrets, vienne à vous.
Blue team
Chaque job CRACI s'exécute dans sa propre machine virtuelle isolée : rien de ce qu'un job laisse derrière lui n'attend le suivant. Vous n'avez pas non plus de flotte de runners à corriger et à durcir.
Runners managés ou auto-hébergés →Après la divulgation
L'attaquant n'a pas besoin de savoir que vous utilisez la dépendance. Il essaie l'exploit partout et regarde ce qui répond. Votre équipe a besoin de savoir où cette dépendance a été livrée. Toute la différence est de savoir si vous devez aller chercher, et il y a chaque année plus de courses à disputer : voir combien de CVE sont publiées chaque jour.
Red team
Blue team, sans enregistrement du build
Blue team, avec CRACI
Aucun contrôle n'arrête à lui seul toutes les attaques de la chaîne d'approvisionnement. Superposez ceux qui suivent, et chaque étape ci-dessus devient plus difficile. Pour le détail côté pipeline, consultez la checklist de sécurité des pipelines CI/CD.
Les attaquants surveillent chaque avis de sécurité et essaient l'exploit sur tout le monde le jour où une vulnérabilité est divulguée. Ils n'ont jamais eu besoin de votre liste de dépendances. Vous, si. CRACI donne à votre équipe cette liste, tirée du build lui-même, et ferme les portes sur lesquelles comptent les attaquants : le trafic sortant ouvert et les runners partagés.
Une attaque visant le code, les outils ou les services à partir desquels un produit est construit, comme un paquet open source, un composant CI/CD ou le système de build, plutôt que le produit lui-même. Une seule compromission atteint toutes les organisations qui utilisent le composant concerné.
Le ver Shai-Hulud (depuis 2025) s'est propagé via des paquets npm infectés et a volé des secrets CI. La compromission de tj-actions/changed-files (CVE-2025-30066) a détourné une GitHub Action populaire. La porte dérobée de xz utils (CVE-2024-3094) a été glissée dans une bibliothèque de compression en amont. Log4Shell (CVE-2021-44228) a exploité une faille dans une bibliothèque de journalisation Java très répandue. Le Bash Uploader de Codecov (2021) a été modifié pour envoyer des identifiants CI à un serveur extérieur, et SolarWinds Orion (2020) a livré du code malveillant inséré au build.
SolarWinds. En 2020, des attaquants disposant d'un accès dissimulé au processus de build de SolarWinds Orion ont inséré du code malveillant dans ses releases, et les clients l'ont installé comme une mise à jour normale. Cette attaque a montré qu'un arbre source sain ne suffit pas : le build lui-même doit être digne de confiance et vérifiable.
Généralement non, et ils n'en ont pas besoin. La plupart des attaques visent un paquet plutôt qu'une entreprise : dès qu'un avis de sécurité est publié, les attaquants essaient l'exploit sur tout ce qui pourrait exécuter une version vulnérable et regardent ce qui répond. Des indices publics, comme les versions dans les bundles JavaScript ou les dépôts open source, les aident à viser. L'asymétrie, c'est que vous, vous avez besoin de la liste : pour savoir si vous êtes touché, vous devez savoir ce que chaque build a livré, y compris ce qu'il a récupéré en dehors du lockfile.
Aucun contrôle ne les arrête toutes à lui seul. Conservez une SBOM de ce que livre chaque build et surveillez-la par rapport aux nouveaux avis de sécurité, épinglez les dépendances et les GitHub Actions, bloquez les versions vulnérables au build, restreignez ce à quoi les jobs CI peuvent se connecter, isolez les jobs et limitez leurs secrets, et vérifiez que les artefacts déployés sont bien ceux que vous avez construits.
Commitez un lockfile et installez à partir de lui en CI, et désactivez les scripts d'installation là où un build n'en a pas besoin (--ignore-scripts de npm). Conservez un enregistrement des versions de paquets réellement installées par chaque build, afin de pouvoir vérifier rapidement lorsqu'une nouvelle vague telle que Shai-Hulud est annoncée. Restreignez ce à quoi les jobs CI peuvent se connecter, pour qu'un script d'installation malveillant ne puisse pas faire sortir vos tokens, et renouvelez tout token qu'une version infectée aurait pu atteindre.
Dans les exercices de sécurité, la red team joue l'attaquant et la blue team défend. Cette page reprend ce partage : chaque étape d'une attaque de la chaîne d'approvisionnement avec les mots de l'attaquant, et la réponse de la défense.
Les paquets connus, oui. Une release malveillante qui a une CVE publiée, comme la porte dérobée de xz, est signalée comme n'importe quelle autre vulnérabilité, et une gate de politique peut bloquer les builds qui la contiennent. CRACI n'analyse pas le comportement des paquets et ne note pas leur réputation : un tout nouveau paquet malveillant n'est donc pas signalé tant qu'il n'existe pas d'avis de sécurité. C'est à cela que sert la politique de trafic sortant : avec le refus par défaut, le build ne peut atteindre que les hôtes dont il a besoin, et le paquet ne peut donc pas faire sortir vos secrets, même lors d'une attaque que personne n'a encore vue.