Het lekken van geheimen gaat niet altijd over slechte code of kwetsbare bibliotheken. Soms komt het neer op hoe we geheimen beheren tijdens CI-runs, en CVE‑2025‑30066 is een schoolvoorbeeld van hoe dat mis kan gaan. De GitHub Action tj‑actions/changed‑files, veelgebruikt om gewijzigde bestanden te detecteren in pull requests, werd een stil kanaal voor geheime lekken. Dit is wat er gebeurde en hoe je je geheim kunt houden. CI/CD geheimen pipeline.
Wat is er gebeurd in CVE‑2025‑30066?
Medio maart 2025 werd tj‑actions/changed‑files gecompromitteerd. De aanvaller heeft bestaande versietags (tot v45.0.7) herschreven om te verwijzen naar een kwaadaardige commitHierdoor werd het gedrag van de actie gewijzigd zonder dat de ontwikkelaars het merkten. Er werd geen nieuwe versie uitgebracht, alleen onzichtbare tagmanipulatie.
De payload was eenvoudig maar gevaarlijk: het haalde een extern Base64-gecodeerd Python-script op dat het geheugen van de runner scande op inloggegevens, deze vervolgens in logs dumpte of exfiltreerde. Dit was geen logische codefout in de tj-actions/changed-files; het was misbruik van de manier waarop geheimen kunnen lekken binnen CI-workflows met behulp van die herbruikbare actie. CVE-2025-30066 ging niet over bufferoverlopen; het ging over een CI-ontwerpfout waardoor geheimen konden lekken.
Impact: Elke repository die de getroffen versies van tj‑actions/changed‑files gebruikt, loopt het risico op geheimlekken, vooral als gevoelige tokens of bestanden onveilig worden verwerkt in bestandspatronen of CI-uitvoer.
Waarom dit van invloed is op workflows die afhankelijk zijn van herbruikbare acties
DevSecOps-workflows zijn sterk afhankelijk van tj‑actions/changed‑files om:
- Automatiseren pull request cheques
- Gewijzigde bestanden in specifieke paden identificeren
- Vermijd redundante CI-taken
Maar deze workflows zien vaak één ding over het hoofd: hoe glob-patronen gevoelige gegevens kunnen bevatten. Ontwikkelaars gaan ervan uit dat tj-actions/changed-files standaard veilig werken. Als u echter glob configuraties/** en geheimen worden opgeslagen in configs/secrets.envJe hebt zojuist een geheim bestand toegevoegd aan CI-uitvoer of logs. Dat is geen bug in de actie; het is een CI/CD ontwerpfout die leidt tot geheime lekkage. CVE‑2025‑30066 is hier een duidelijk voorbeeld van.
Hoe het geheime lek plaatsvond (kwetsbaarheidsanalyse)
Laten we de kern van het falen van CVE‑2025‑30066 eens onderzoeken:
- Globbingpatronen zoals **/*.env geheime bestanden onbedoeld gekoppeld
- tj‑actions/changed‑files behandelde die geheimen als gewijzigde bestanden
- Geheimen kwamen terecht in stapuitvoer, logboeken of downstream-taken
Dit gebeurde omdat geheimen werden opgeslagen in versiebeheerde paden (slecht idee), en de CI-configuratie ze niet expliciet uitsloot van globbing (ook slecht). Het is dus geen codefout, maar een gebrekkige CI-ontwerphygiëne die geheimen lekt bij de uitvoer van tj-actions/changed-files.
Praktisch exploitpad: van CI-taak naar blootstelling van inloggegevens
Voorbeeld van een CI-configuratie die leidde tot geheim lekken 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 veranderd:
- Het werd gemarkeerd door tj‑actions/changed‑files
- Het werd opgenomen in stappen.gewijzigd.uitvoer.alle_gewijzigde_bestanden
- Latere stappen registreerden het of gaven het door aan scripts, waardoor geheimen lekten
Dit lek ontstond doordat CI-logica geheimen als gewone bestanden behandelde. Daar begint het geheimlek, niet door een bufferoverloop, maar door misbruik van tj-acties/gewijzigde bestanden in een gebrekkig CI-ontwerp.
Propagatie vindt plaats met uitkomsten zoals:
yaml
‑ name: Use changed file list
run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}"
If geheimen.env Staat in die lijst, dan kunnen de bestandsnaam en mogelijk de inhoud ervan in buildlogs verschijnen. Zelfs voorwaardelijke logica zoals:
yaml
if: contains(steps.changed.outputs.all_changed_files, 'secrets.env')
Kan gevoelige artefacten blootleggen. Dit is een CI/CD een ontwerpfout die het lekken van geheimen mogelijk maakt, geen fout in de actiecode.
Hoe u herbruikbare workflows veilig kunt gebruiken en lekken kunt voorkomen
Je hoeft tj-acties/gewijzigde bestanden niet te laten vallen. Gebruik herbruikbare acties met een 'geheimen eerst'-mentaliteit:
Geheimen - Best practices voor het omgaan met geheimen
- Beheer nooit geheimen van versies
- Vermijd bolvormige patronen die overeenkomen met gevoelige paden
- Gebruik op de omgeving gebaseerde geheimen (GITHUB_ENV, kluizen, GitHub-geheimen)
CI/CD Configuratie Guardrails
- Pin acties altijd vast aan onveranderlijke SHA's, niet aan tags (gebruik nooit @ V45)
- Behandel de uitvoer van tj-acties/gewijzigde bestanden als besmet, reinig of filter deze
- Stel alleen uitvoer in als deze is gesaneerd
⚠️ Onveilig voorbeeld:
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
Het bovenstaande is precies het misbruik achter geheime lekken en CVE‑2025‑30066.
Veilig alternatief:
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
Door dit te doen vermijdt u de CI/CD ontwerpfout die leidt tot geheime lekken via tj‑actions/changed‑files.
Bovendien:
- Logging uitschakelen of beperken waar geheimen kunnen verschijnen
- Gebruik de geheimmaskeringsfuncties van GitHub
- Beperk de toegang tot buildlogs en artefacten
Snelle geheimen - Checklist voor veilig CI-gebruik
| Best Practice |
|---|
| Sla geen geheimen op in versiegecontroleerde bestanden |
| Gebruik kluizen of GitHub Secrets voor inloggegevens |
| Pin tj-acties/gewijzigde bestanden altijd vast aan onveranderlijke SHA's |
| Filter of reinig de uitvoer van tj-acties/gewijzigde bestanden |
| Voeg nooit geheime paden toe aan bolvormige patronen |
| Masker of beperk logboeken die gevoelige gegevens kunnen blootstellen |
| Controleer vaak overgenomen CI-configuraties |
De rol van Xygeni: handhaving van CI-geheimen op grote schaal
Xygeni beveiligt CI/CD pipelinedoor te focussen op hoe geheimen in de echte wereld worden behandeld, gebruikt en onthuld DevOps-workflows. Het gaat niet alleen om het scannen van code; het gaat om het handhaven van best practices voor geheim beheer via live pipeline analyse.
Detectie van onveilig uitvoergebruik
- Scant GitHub-acties voor gebruik van echo, run en geeft uitvoer waarbij ${{ steps.*.outputs.* }} kan gevoelige waarden bevatten
- Geeft aan wanneer er rechtstreeks, opzettelijk of per ongeluk naar geheimen wordt verwezen of deze worden afgedrukt
Monitoring van gelekte geheimen
- Detecteert waarden met hoge entropie (API-sleutels, tokens) in logs en stapsgewijze uitvoer
- Activeert waarschuwingen wanneer er geheimen in de pipeline logs, zelfs als ze stroomafwaarts gemaskeerd zijn
Verkeerd geconfigureerd actiegebruik
- Houdt alle GitHub-acties bij pipelineom het gebruik van gecompromitteerde versies te detecteren (bijv. tj-acties/gewijzigde-bestanden@v45)
- Controleert bestandsmatchingpatronen die potentiële geheimen bevatten zoals **/*.env, *.key of .env.*
Beleidsgebaseerde CI Guardrails
- Dwingt SHA-pinning af voor acties van derden
- Blokkeert het gebruik van onveilige bestandsglobs die geheimen in logs kunnen verbergen
- Voorkomt pipelines van het uitzenden van gevoelige waarden als onderdeel van workflow-uitvoer
Door workflows te behandelen als onderdeel van uw bedreigingsoppervlak, zorgt Xygeni ervoor dat geheime hygiëne niet alleen een best practice is, maar een ingebouwde verdediging.
Conclusie: Geheime lekkage kan beginnen met een eenvoudige actie en misbruik
CVE‑2025‑30066 was geen bibliotheekbug; het was een CI/CD Ontwerpfouten als gevolg van onjuist gebruik van tj-acties/gewijzigde bestanden. Wat DevSecOps-teams hiervan moeten leren:
- Behandel elke glob-/bestandsreferentie in CI als een potentieel lekpunt
- Controleer workflows regelmatig op onbedoelde vermelding van geheimen
- Gebruik veilige kluizen of omgevingsgeheimen, controleer nooit geheimen in versiebeheer
- Alle workflow-uitvoer desinfecteren of filteren
- Registreer gevoelige workflowactiviteiten om de controleerbaarheid te behouden
CI is code. Workflows zijn code. Logs en outputs zijn code. Bewaak uw geheimen bij elke stap, anders riskeert u een scenario waarin uw geheimen worden gelekt zonder dat er een hacker nodig is, maar een kwaadaardige. CI/CD ontwerpkeuze.
