Hemlighetsläckage handlar inte alltid om dålig kod eller sårbara bibliotek. Ibland handlar det om hur vi hanterar hemligheter under CI-körningar, och CVE-2025-30066 är ett skolboksexempel på hur det kan gå åt skogen. GitHub-åtgärden tj-actions/changed-files, som ofta används för att upptäcka ändrade filer i pull requests, blev en tyst kanal för hemliga läckor. Här är vad som hände och hur du kan låsa din CI/CD hemligheter pipeline.
Vad hände i CVE-2025-30066?
I mitten av mars 2025 komprometterades tj-actions/changed-files. Angriparen skrev om befintliga versionstaggar (upp till v45.0.7) för att peka på en skadlig kod. commitDetta förändrade åtgärdens beteende utan att utvecklarna märkte det; ingen ny version släpptes, bara osynlig taggmanipulering.
Nyttelasten var enkel men farlig: den hämtade ett fjärrkodat Python-skript, Base64, som skannade löparens minne efter autentiseringsuppgifter, dumpade dem i loggar eller exfiltrerade dem. Detta var inte en logisk kodfel i tj-actions/changed-filerna; det var ett missbruk av hur hemlighetsläckage kan uppstå inom CI-arbetsflöden med hjälp av den återanvändbara åtgärden. CVE-2025-30066 handlade inte om buffertöverflöden; det handlade om ett CI-designfel som gjorde det möjligt för hemligheter att läcka.
Effekt: Alla repo som använder de berörda versionerna av tj-actions/changed-files riskerade hemlighetsläckage, särskilt om känsliga tokens eller filer hanterades osäkert i filmönster eller CI-utdata.
Varför detta påverkar arbetsflöden som är beroende av återanvändbara åtgärder
DevSecOps-arbetsflöden förlitar sig starkt på tj-actions/changed-files för att:
- Automatisera pull request checkar
- Identifiera ändrade filer i specifika sökvägar
- Undvik redundanta CI-jobb
Men dessa arbetsflöden förbiser ofta en sak: hur glob-mönster kan innehålla känslig data. Utvecklare antar att tj-actions/changed-files fungerar säkert som standard. Men om du glob konfigurationer/** och hemligheter lagras i configs/secrets.env, du har precis lagt till en hemlig fil i CI-utdata eller loggar. Det är inte ett fel i åtgärden; det är en CI/CD designfel som leder till hemligt läckage. CVE-2025-30066 är ett tydligt exempel på detta.
Hur det hemliga läckaget uppstod (sårbarhetsanalys)
Låt oss analysera kärnfelet bakom CVE-2025-30066:
- Globbande mönster som **/*.env matchade oavsiktligt hemliga filer
- tj-actions/changed-files behandlade dessa hemligheter som ändrade filer
- Hemligheter hamnade i stegutdata, loggar eller nedströmsjobb
Detta hände eftersom hemligheter lagrades i versionskontrollerade sökvägar (dålig idé), och CI-konfigurationen uteslöt dem inte explicit från globbing (också dåligt). Så det är inte ett kodfel, det är dålig CI-designhygien som orsakar hemlighetsläckage med tj-actions/changed-files-utdata.
Praktisk exploitväg: Från CI-jobb till behörighetsexponering
Exempel på CI-installation som orsakade hemlighetsläckage genom 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 ändrad:
- Det flaggades av tj-actions/changed-files
- Den inkluderades i steg.ändrade.utdata.alla_ändrade_filer
- Senare steg loggade det eller skickade det till skript, vilket läckte hemligheter
Denna läcka inträffade eftersom CI-logiken behandlade hemligheter som vanliga filer. Det är där hemlighetsläckaget börjar, inte på grund av ett buffertöverskott, utan missbruk av tj-actions/ändrade-filer i en felaktig CI-design.
Förökning sker med utdata som:
yaml ‑ name: Use changed file list run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}" If hemligheter.miljö finns i den listan, kan dess filnamn och eventuellt innehåll dyka upp i byggloggar. Även villkorlig logik som:
yaml if: contains(steps.changed.outputs.all_changed_files, 'secrets.env') Kan exponera känsliga artefakter. Detta är en CI/CD designfel som tillåter hemlig läckage, inte ett fel i åtgärdskoden.
Hur man använder återanvändbara arbetsflöden på ett säkert sätt och förhindrar läckage
Du behöver inte överge tj-actions/changed-files. Du bör använda återanvändbara Actions med ett hemlighetsfokuserat tänkesätt:
Bästa praxis för hantering av hemligheter
- Använd aldrig versionskontrollhemligheter
- Undvik globmönster som matchar känsliga sökvägar
- Använd miljöbaserade hemligheter (GITHUB_ENV, valv, GitHub-hemligheter)
CI/CD konfiguration Guardrails
- Fäst alltid åtgärder till oföränderliga SHA:er, inte taggar (använd aldrig @v45)
- Behandla utdata från tj-actions/changed-files som skadade, sanera eller filtrera dem
- Ställ endast in utgångar om de är sanerade
⚠️ Osäkert exempel:
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 Ovanstående är exakt det missbruk som ligger bakom hemlig läcka och CVE-2025-30066.
Säkert alternativ:
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 Genom att göra detta undviker du CI/CD designfel som leder till hemlighetsläckage via tj-actions/ändrade filer.
Dessutom:
- Inaktivera eller begränsa loggning där hemligheter kan visas
- Använd GitHubs hemliga maskeringsfunktioner
- Begränsa åtkomst till byggloggar och artefakter
Snabba hemligheter – checklista för säker CI-användning
| Bästa praxis |
|---|
| Lagra inte hemligheter i versionskontrollerade filer |
| Använd valv eller GitHub-hemligheter för autentiseringsuppgifter |
| Fäst alltid tj-åtgärder/ändrade filer till oföränderliga SHA:er |
| Filtrera eller sanera utdata från tj-åtgärder/ändrade filer |
| Inkludera aldrig hemliga sökvägar i globmönster |
| Maskera eller begränsa loggar som kan exponera känsliga uppgifter |
| Granska ofta ärvda CI-konfigurationer |
Xygenis roll: Tillämpning av CI-hemligheter i stor skala
Xygeni säkrar CI/CD pipelinegenom att fokusera på hur hemligheter hanteras, används och avslöjas i verkligheten DevOps-arbetsflöden. Det handlar inte bara om att skanna kod; det handlar om att upprätthålla bästa praxis för hantering av hemligheter genom live-flöden. pipeline analys.
Detektering av osäker utdataanvändning
- Skannar GitHub-åtgärder för användning av echo, run och utdata där ${{ steps.*.outputs.* }} kan innehålla känsliga värden
- Identifierar när hemligheter refereras till eller skrivs ut direkt, avsiktligt eller av misstag.
Övervakning av läckta hemligheter
- Upptäcker höga entropivärden (API-nycklar, tokens) i loggar och stegutgångar
- Utlöser varningar när hemligheter dyker upp i pipeline loggar, även om de är maskerade nedströms
Felkonfigurerad åtgärdsanvändning
- Spårar alla GitHub-åtgärder över pipelines för att upptäcka användning av komprometterade versioner (t.ex. tj-åtgärder/ändrade-filer@v45)
- Granskar filmatchningsmönster som inkluderar potentiella hemligheter som **/*.env, *.key eller .env.*
Policybaserad CI Guardrails
- Tvingar fram SHA-pinning för tredjepartsåtgärder
- Blockerar användning av osäkra filglober som kan svepa hemligheter in i loggar
- förhindrar pipelinefrån att avge känsliga värden som en del av arbetsflödesutdata
Genom att behandla arbetsflöden som en del av din hotyta säkerställer Xygeni att hemlig hygien inte bara är en god praxis, utan ett inbyggt försvar.
Slutsats: Hemlig läckage kan börja med en enkel åtgärd Missbruk
CVE-2025-30066 var inte en biblioteksbugg; det var en CI/CD designfel som härrör från felaktig användning av tj-actions/ändrade filer. Vad DevSecOps-team bör ta med sig:
- Behandla varje glob/fil-referens i CI som en potentiell läckpunkt
- Granska arbetsflöden regelbundet för att upptäcka oavsiktliga inkluderingar av hemligheter
- Använd säkra valv eller miljöhemligheter, checka aldrig in hemligheter i versionshantering
- Sanera eller filtrera alla arbetsflödesutdata
- Logga känslig arbetsflödesaktivitet för att bibehålla granskningsbarheten
CI är kod. Arbetsflöden är kod. Loggar och utdata är kod. Skydda dina hemligheter i varje steg, eller riskera ett scenario med hemlighetsläckage som inte kräver en hackare, bara en dålig CI/CD designval.
