Geheimnislecks sind nicht immer auf fehlerhaften Code oder anfällige Bibliotheken zurückzuführen. Manchmal kommt es darauf an, wie wir Geheimnisse während CI-Läufen verwalten, und CVE‑2025‑30066 ist ein Paradebeispiel dafür, wie das schiefgehen kann. Die GitHub-Aktion tj‑actions/changed‑files, die häufig verwendet wird, um geänderte Dateien in pull requests, wurde zu einem stillen Kanal für geheime Lecks. Hier ist, was passiert ist und wie Sie Ihre CI/CD pipeline.
Was ist in CVE-2025-30066 passiert?
Mitte März 2025 wurde tj‑actions/changed‑files kompromittiert. Der Angreifer hat vorhandene Versions-Tags (bis v45.0.7) umgeschrieben, um auf eine bösartige commit. Dadurch wurde das Verhalten der Aktion geändert, ohne dass die Entwickler es bemerkten. Es wurde keine neue Version veröffentlicht, sondern nur eine unsichtbare Manipulation der Tags.
Die Nutzlast war unkompliziert, aber gefährlich: Sie rief ein entferntes Base64-codiertes Python-Skript ab, das den Runner-Speicher nach Anmeldeinformationen durchsuchte und diese in Protokolle kopierte oder exfiltrierte. Dabei handelte es sich nicht um einen logischen Codefehler in den tj-actions/changed-files, sondern um einen Missbrauch der Möglichkeit, Geheimnisse in CI-Workflows mit dieser wiederverwendbaren Aktion zu verlieren. Bei CVE-2025-30066 ging es nicht um Pufferüberläufe, sondern um einen CI-Designfehler, der Geheimnisse freigab.
Auswirkungen: Bei jedem Repo, das die betroffenen Versionen von tj‑actions/changed‑files verwendet, besteht das Risiko eines Geheimnisverlusts, insbesondere wenn vertrauliche Token oder Dateien in Dateimustern oder CI-Ausgaben unsicher behandelt wurden.
Warum dies Auswirkungen auf Workflows hat, die auf wiederverwendbaren Aktionen basieren
DevSecOps-Workflows verlassen sich stark auf tj‑actions/changed‑files, um:
- Automatisiere Prozesse mit Technologie
pull request Schecks
- Identifizieren Sie geänderte Dateien in bestimmten Pfaden
- Vermeiden Sie redundante CI-Jobs
Diese Workflows übersehen jedoch oft eines: Glob-Muster können sensible Daten enthalten. Entwickler gehen davon aus, dass tj‑actions/changed‑files standardmäßig sicher funktioniert. Wenn Sie jedoch glob Konfigurationen/** und Geheimnisse werden gespeichert in configs/secrets.env, Sie haben gerade eine geheime Datei in CI-Ausgaben oder Protokolle eingefügt. Das ist kein Fehler in der Aktion; es ist ein CI/CD Designfehler, der zum Durchsickern von Geheimnissen führt. CVE‑2025‑30066 ist ein klares Beispiel dafür.
Wie es zu dem geheimen Leck kam (Aufschlüsselung der Sicherheitslücken)
Lassen Sie uns den Kernfehler hinter CVE‑2025‑30066 näher untersuchen:
- Globbing-Muster wie **/*.env unbeabsichtigt mit geheimen Dateien abgeglichen
- tj‑actions/changed‑files behandelte diese Geheimnisse als geänderte Dateien
- Geheimnisse landeten in Schrittausgaben, Protokollen oder nachgelagerten Jobs
Dies geschah, weil Geheimnisse in versionskontrollierten Pfaden gespeichert wurden (schlechte Idee) und die CI-Konfiguration sie nicht explizit vom Globbing ausschloss (ebenfalls schlecht). Es handelt sich also nicht um einen Codefehler, sondern um mangelnde CI-Designhygiene, die zu einem Geheimnisverlust mit TJ-Actions/Changed-Files-Ausgaben führt.
Praktischer Exploit-Pfad: Vom CI-Job zur Offenlegung der Anmeldeinformationen
Beispiel für ein CI-Setup, das zu einem Geheimnisleck durch TJ-Aktionen/geänderte Dateien führte:
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 geändert:
- Es wurde von tj‑actions/changed‑files markiert
- Es wurde aufgenommen in Schritte.geänderte.Ausgaben.alle_geänderten_Dateien
- Spätere Schritte protokollierten es oder gaben es an Skripte weiter, wodurch Geheimnisse preisgegeben wurden
Dieses Leck entstand, weil die CI-Logik Geheimnisse wie normale Dateien behandelte. Hier beginnt der Geheimnisverlust, nicht aufgrund eines Pufferüberlaufs, sondern aufgrund des Missbrauchs von tj-actions/changed-files in einem fehlerhaften CI-Design.
Die Ausbreitung erfolgt mit Ergebnissen wie:
yaml
‑ name: Use changed file list
run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}"
If Geheimnisse.env ist in dieser Liste, sein Dateiname und möglicherweise sein Inhalt können in Build-Protokollen auftauchen. Sogar bedingte Logik wie:
yaml
if: contains(steps.changed.outputs.all_changed_files, 'secrets.env')
Kann empfindliche Artefakte freilegen. Dies ist ein CI/CD Es handelt sich um einen Konstruktionsfehler, der das Durchsickern von Geheimnissen ermöglicht hat, und nicht um einen Fehler im Aktionscode.
So verwenden Sie wiederverwendbare Workflows sicher und verhindern Datenlecks
Sie müssen tj‑actions/changed‑files nicht aufgeben. Sie sollten wiederverwendbare Aktionen mit einer „Secrets First“-Mentalität verwenden:
Best Practices für den Umgang mit Geheimnissen
- Versionieren Sie niemals Geheimnisse
- Vermeiden Sie Glob-Muster, die mit sensiblen Pfaden übereinstimmen
- Verwenden Sie umgebungsbasierte Geheimnisse (GITHUB_ENV, Tresore, GitHub-Geheimnisse).
CI/CD Konfiguration Guardrails
- Fixieren Sie Aktionen immer mit unveränderlichen SHAs, nicht mit Tags (verwenden Sie niemals @ V45)
- Behandeln Sie die Ausgabe von tj‑actions/changed‑files als verunreinigt, bereinigen oder filtern Sie sie
- Ausgänge nur einstellen, wenn sie bereinigt sind
⚠️ Unsicheres Beispiel:
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
Genau das oben Genannte ist der Missbrauch hinter der Geheimleckage und CVE-2025-30066.
Sichere Alternative:
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
Dadurch vermeiden Sie, CI/CD Designfehler, der zum Durchsickern von Geheimnissen über TJ-Aktionen/geänderte Dateien führt.
Zusätzlich:
- Deaktivieren oder beschränken Sie die Protokollierung, wenn Geheimnisse angezeigt werden könnten
- Verwenden Sie die geheimen Maskierungsfunktionen von GitHub
- Beschränken Sie den Zugriff auf Build-Protokolle und Artefakte
Checkliste für die sichere Verwendung von Quick Secrets CI
| Beste Übung |
|---|
| Speichern Sie Geheimnisse nicht in versionskontrollierten Dateien |
| Verwenden Sie Tresore oder GitHub Secrets für Anmeldeinformationen |
| Pinne tj‑actions/changed‑files immer an unveränderliche SHAs |
| Filtern oder bereinigen Sie Ausgaben von tj‑actions/changed‑files |
| Schließen Sie niemals geheime Pfade in Glob-Muster ein |
| Maskieren oder beschränken Sie Protokolle, die vertrauliche Daten offenlegen könnten |
| Überprüfen Sie häufig übernommene CI-Konfigurationen |
Xygenis Rolle: Durchsetzung von CI-Geheimnissen im großen Maßstab
Xygeni sichert CI/CD pipelines durch die Konzentration auf wie Geheimnisse in der realen Welt gehandhabt, verwendet und offengelegt werden DevOps-Workflows. Es geht nicht nur um das Scannen von Code; es geht um die Durchsetzung von Best Practices für das Geheimnismanagement durch Live- pipeline Analyse.
Erkennung unsicherer Ausgabenutzung
- Scannt GitHub-Aktionen für die Verwendung von Echo, Ausführen und Ausgaben, wobei ${{ steps.*.outputs.* }} könnte sensible Werte enthalten
- Identifiziert, wenn auf Geheimnisse direkt, absichtlich oder versehentlich verwiesen oder diese gedruckt werden
Überwachung durchgesickerter Geheimnisse
- Erkennt Werte mit hoher Entropie (API-Schlüssel, Token) in Protokollen und Schrittausgaben
- Löst Warnungen aus, wenn Geheimnisse in der pipeline Protokolle, auch wenn sie nachgelagert maskiert sind
Falsch konfigurierte Aktionsverwendung
- Verfolgt alle GitHub-Aktionen über pipelines, um die Verwendung kompromittierter Versionen zu erkennen (z. B. tj-actions/geänderte-dateien@v45)
- Prüft Dateiübereinstimmungsmuster, die potenzielle Geheimnisse enthalten, wie **/*.env, *.key oder .env.*
Richtlinienbasierte CI Guardrails
- Erzwingt SHA-Pinning für Aktionen von Drittanbietern
- Blockiert die Verwendung unsicherer Dateiglobs, die Geheimnisse in Protokolle übertragen könnten
- Verhindert pipelines daran hindern, sensible Werte als Teil der Workflow-Ausgaben auszugeben
Indem Xygeni Arbeitsabläufe als Teil Ihrer Bedrohungsoberfläche behandelt, stellt es sicher, dass die Geheimhaltung nicht nur eine bewährte Methode, sondern eine integrierte Abwehrmaßnahme ist.
Fazit: Geheime Lecks können mit einem einfachen Handlungsmissbrauch beginnen
CVE‑2025‑30066 war kein Bibliotheksfehler; es war ein CI/CD Designfehler aufgrund unsachgemäßer Verwendung von TJ-Aktionen/geänderten Dateien. Was DevSecOps-Teams lernen sollten:
- Behandeln Sie jeden Glob-/Dateiverweis in CI als potenziellen Leckpunkt
- Überprüfen Sie Workflows regelmäßig auf versehentliche Einbeziehung von Geheimnissen
- Verwenden Sie sichere Tresore oder Umgebungsgeheimnisse, checken Sie Geheimnisse niemals in die Versionskontrolle ein
- Bereinigen oder filtern Sie alle Workflow-Ausgaben
- Protokollieren Sie sensible Workflow-Aktivitäten, um die Überprüfbarkeit aufrechtzuerhalten
CI ist Code. Workflows sind Code. Protokolle und Ausgaben sind Code. Schützen Sie Ihre Geheimnisse bei jedem Schritt, sonst riskieren Sie ein Geheimnisleck, für das kein Hacker nötig ist, sondern nur ein böser CI/CD Designauswahl.
