Les fuites de secrets ne sont pas toujours liées à un code défectueux ou à des bibliothèques vulnérables. Parfois, cela dépend de la façon dont nous gérons les secrets lors des exécutions d'intégration continue, et la CVE-2025-30066 illustre parfaitement comment cela peut mal tourner. L'action GitHub tj-actions/changed-files, largement utilisée pour détecter les fichiers modifiés dans pull requests, est devenu un canal silencieux de fuite de secrets. Voici ce qui s'est passé et comment vous pouvez sécuriser votre CI/CD secrets pipeline.
Que s’est-il passé dans CVE‑2025‑30066 ?
À la mi-mars 2025, tj-actions/changed-files a été compromis. L'attaquant a réécrit les balises de version existantes (jusqu'à la version 45.0.7) pour pointer vers une version malveillante. commitCela a modifié le comportement de l'action sans que les développeurs ne le remarquent ; aucune nouvelle version n'a été publiée, juste une falsification invisible des balises.
La charge utile était simple, mais dangereuse : elle récupérait un script Python distant codé en Base64 qui analysait la mémoire de l'exécuteur à la recherche d'identifiants, les stockant dans les journaux ou les exfiltrant. Il ne s'agissait pas d'une faille de code logique dans les fichiers tj-actions/changed-files ; il s'agissait d'une utilisation abusive de la fuite de secrets dans les workflows d'intégration continue utilisant cette action réutilisable. La CVE-2025-30066 ne concernait pas de dépassements de tampon ; elle concernait une erreur de conception de l'intégration continue qui permettait la fuite de secrets.
Impact : tout référentiel utilisant les versions affectées de tj-actions/changed-files risquait une fuite de secret, en particulier si des jetons ou des fichiers sensibles étaient traités de manière non sécurisée dans les modèles de fichiers ou les sorties CI.
Pourquoi cela affecte les flux de travail reposant sur des actions réutilisables
Flux de travail DevSecOps s'appuie fortement sur tj-actions/changed-files pour :
- Automatisez pull request chèques
- Identifier les fichiers modifiés dans des chemins spécifiques
- Évitez les tâches CI redondantes
Mais ces workflows négligent souvent un point : la manière dont les modèles glob peuvent inclure des données sensibles. Les développeurs supposent que tj-actions/changed-files se comporte de manière sécurisée par défaut. Cependant, si vous utilisez glob configurations/** et les secrets sont stockés dans configs/secrets.envVous venez d'ajouter un fichier secret aux sorties ou journaux CI. Ce n'est pas un bug de l'action ; c'est un CI/CD Défaut de conception pouvant entraîner une fuite de données confidentielles. La faille CVE‑2025‑30066 en est un parfait exemple.
Comment la fuite secrète s'est produite (analyse des vulnérabilités)
Analysons la défaillance principale derrière CVE‑2025‑30066 :
- Des modèles de globe comme **/*.env correspondance involontaire de fichiers secrets
- tj-actions/changed-files a traité ces secrets comme des fichiers modifiés
- Les secrets se sont retrouvés dans des sorties d'étape, des journaux ou des tâches en aval
Cela s'est produit car les secrets étaient stockés dans des chemins contrôlés par version (mauvaise idée) et la configuration de l'intégration continue ne les excluait pas explicitement du globbing (également mauvais). Il ne s'agit donc pas d'un bug de code, mais d'une mauvaise hygiène de conception de l'intégration continue, provoquant une fuite de secrets avec les sorties tj-actions/changed-files.
Chemin d'exploitation pratique : du poste d'agent de connexion à l'exposition des informations d'identification
Exemple de configuration CI qui a provoqué une fuite de secret via tj-actions/changed-files :
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Check changed files
id: changed
uses: tj‑actions/changed‑files@v45
with:
files: configs/**
If configs/secrets.env modifié:
- Il a été signalé par tj-actions/changed-files
- Il a été inclus dans étapes.sorties.modifiées.tous_les_fichiers_modifiés
- Les étapes ultérieures l'ont enregistré ou transmis aux scripts, divulguant ainsi des secrets
Cette fuite s'est produite car la logique d'intégration continue traitait les secrets comme des fichiers ordinaires. C'est là que la fuite de secrets commence, non pas à cause d'un dépassement de tampon, mais d'une mauvaise utilisation de tj-actions/changed-files dans une conception d'intégration continue défectueuse.
La propagation se produit avec des sorties telles que :
yaml
‑ name: Use changed file list
run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}"
If secrets.env Si un élément figure dans cette liste, son nom de fichier et son contenu peuvent apparaître dans les journaux de compilation. Même une logique conditionnelle comme :
yaml
if: contains(steps.changed.outputs.all_changed_files, 'secrets.env')
Peut exposer des artefacts sensibles. Ceci est un CI/CD échec de conception permettant une fuite de secret, pas un défaut dans le code d'action.
Comment utiliser en toute sécurité les flux de travail réutilisables et éviter les fuites
Il n'est pas nécessaire d'abandonner les actions tj/fichiers modifiés. Privilégiez les actions réutilisables et privilégiez les secrets :
Meilleures pratiques de gestion des secrets
- Ne contrôlez jamais les versions des secrets
- Évitez les modèles glob qui correspondent à des chemins sensibles
- Utiliser des secrets basés sur l'environnement (GITHUB_ENV, coffres, secrets GitHub)
CI/CD Configuration Guardrails
- Épinglez toujours les actions sur des SHA immuables, pas sur des balises (n'utilisez jamais @v45)
- Traiter la sortie des actions tj/fichiers modifiés comme contaminée, la nettoyer ou la filtrer
- Définir les sorties uniquement si elles sont assainies
⚠️ Exemple dangereux:
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Detect all changes
id: changed
uses: tj‑actions/changed‑files@v45
with:
files: '**/*' # ⚠️ This glob includes secrets.env, which may leak credentials
Ce qui précède est exactement l’abus derrière la fuite de secret et CVE‑2025‑30066.
Alternative sûre :
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Detect non‑sensitive file changes
id: changed
uses: tj‑actions/changed‑files@<SHA> # pinned to SHA
with:
files: 'src/**'
files‑ignore: '**/secrets.env' # ⚠️ Excludes secret file
En faisant cela, vous évitez CI/CD échec de conception qui conduit à une fuite de secret via tj-actions/changed-files.
En outre:
- Désactiver ou restreindre la journalisation là où des secrets peuvent apparaître
- Utilisez les fonctionnalités de masquage secrètes de GitHub
- Limiter l'accès aux journaux de construction et aux artefacts
Liste de contrôle d'utilisation rapide de Secrets-Safe CI
| Best Practice |
|---|
| Ne stockez pas de secrets dans des fichiers sous contrôle de version |
| Utilisez des coffres-forts ou des secrets GitHub pour les informations d'identification |
| Épinglez toujours les tj-actions/changed-files sur des SHA immuables |
| Filtrer ou assainir les sorties de tj-actions/changed-files |
| N'incluez jamais de chemins secrets dans les modèles glob |
| Masquer ou restreindre les journaux susceptibles d'exposer des données sensibles |
| Auditer souvent les configurations CI héritées |
Rôle de Xygeni : Application des secrets CI à grande échelle
Xygéni sécurise CI/CD pipelines en se concentrant sur comment les secrets sont traités, utilisés et exposés dans le monde réel Workflows DevOps. Il ne s'agit pas seulement d'analyser le code ; il s'agit d'appliquer les meilleures pratiques de gestion des secrets en direct. pipeline analyse.
Détection d'utilisation de sortie non sécurisée
- Analyse les actions GitHub pour les utilisations de echo, run et sorties où ${{ steps.*.outputs.* }} peut inclure des valeurs sensibles
- Identifie quand les secrets sont référencés ou imprimés directement, intentionnellement ou par erreur
Surveillance des secrets divulgués
- Détecte les valeurs à haute entropie (clés API, jetons) dans les journaux et les sorties d'étape
- Déclenche des alertes lorsque des secrets apparaissent dans le pipeline journaux, même masqués en aval
Utilisation d'action mal configurée
- Suit toutes les actions GitHub pipelines pour détecter l'utilisation de versions compromises (par exemple, (tj-actions/fichiers-modifiés@v45)
- Audite les modèles de correspondance de fichiers qui incluent des secrets potentiels tels que **/*.env, *.key ou .env.*
CI basé sur des politiques Guardrails
- Applique l'épinglage SHA pour les actions tierces
- Bloque l'utilisation de fichiers globaux non sécurisés qui pourraient introduire des secrets dans les journaux
- Prévient pipelines d'émettre des valeurs sensibles dans le cadre des sorties de flux de travail
En traitant les flux de travail comme faisant partie de votre surface de menace, Xygeni garantit que l'hygiène secrète n'est pas seulement une bonne pratique, c'est une défense intégrée.
Conclusion : une fuite de secret peut commencer par une simple mauvaise utilisation d'une action
CVE‑2025‑30066 n'était pas un bug de bibliothèque ; c'était un CI/CD Échec de conception dû à une mauvaise utilisation des tj-actions/changed-files. Ce que les équipes DevSecOps devraient retenir :
- Traitez chaque référence glob/fichier dans CI comme un point de fuite potentiel
- Auditer régulièrement les flux de travail pour détecter toute inclusion accidentelle de secrets
- Utilisez des coffres-forts sécurisés ou des secrets d'environnement, ne vérifiez jamais les secrets dans le contrôle de version
- Désinfecter ou filtrer toutes les sorties du flux de travail
- Enregistrez les activités de flux de travail sensibles pour maintenir l'auditabilité
L'intégration continue est du code. Les workflows sont du code. Les journaux et les sorties sont du code. Protégez vos secrets à chaque étape, ou vous risquez une fuite de secrets qui ne nécessite pas de piratage, mais simplement une mauvaise intention. CI/CD choix de conception.
