La fuga di informazioni riservate non riguarda sempre codice difettoso o librerie vulnerabili. A volte, dipende da come gestiamo le informazioni riservate durante le esecuzioni di CI, e CVE-2025-30066 è un esempio lampante di come la situazione possa degenerare. La GitHub Action tj-actions/changed-files, ampiamente utilizzata per rilevare i file modificati in pull requests, è diventato un canale silenzioso per fughe di notizie segrete. Ecco cosa è successo e come puoi bloccare il tuo CI/CD segreti pipeline.
Cosa è successo in CVE‑2025‑30066?
A metà marzo 2025, tj-actions/changed-files è stato compromesso. L'aggressore ha riscritto i tag della versione esistente (fino alla v45.0.7) per indicare un malware commitCiò ha modificato il comportamento dell'azione senza che gli sviluppatori se ne accorgessero; non è stata rilasciata alcuna nuova versione, ma solo una manomissione invisibile dei tag.
Il payload era semplice ma pericoloso: estraeva uno script Python remoto codificato in Base64 che analizzava la memoria del runner alla ricerca di credenziali, inserendole nei log o esfiltrandole. Non si trattava di un difetto logico del codice nei file tj-actions/changed-files; si trattava di un abuso di come la perdita di segreti può verificarsi all'interno dei flussi di lavoro di CI utilizzando quell'azione riutilizzabile. CVE-2025-30066 non riguardava i buffer overflow; riguardava un errore di progettazione di CI che consentiva la perdita di segreti.
Impatto: qualsiasi repository che utilizzasse le versioni interessate di tj-actions/changed-files rischiava la perdita di segreti, soprattutto se i token o i file sensibili venivano gestiti in modo non sicuro nei modelli di file o negli output CI.
Perché ciò influisce sui flussi di lavoro basati su azioni riutilizzabili
Flussi di lavoro DevSecOps si affidano molto a tj-actions/changed-files per:
- Automatizza pull request controlli
- Identificare i file modificati in percorsi specifici
- Evitare lavori CI ridondanti
Ma questi flussi di lavoro spesso trascurano un aspetto: come i modelli glob potrebbero includere dati sensibili. Gli sviluppatori presumono che tj-actions/changed-files si comporti in modo sicuro per impostazione predefinita. Tuttavia, se si esegue glob configurazioni/** e i segreti sono conservati in configs/secrets.env, hai appena aggiunto un file segreto negli output o nei log di CI. Non è un bug nell'azione; è un CI/CD errore di progettazione che porta a perdite segrete. CVE‑2025‑30066 ne è un chiaro esempio.
Come è avvenuta la fuga di notizie segreta (analisi delle vulnerabilità)
Analizziamo il problema principale alla base di CVE‑2025‑30066:
- Modelli di globbing come **/*.env file segreti abbinati involontariamente
- tj‑actions/changed‑files ha trattato quei segreti come file modificati
- I segreti sono finiti negli output dei passaggi, nei log o nei lavori downstream
Ciò è accaduto perché i segreti erano archiviati in percorsi controllati dalla versione (pessima idea) e la configurazione CI non li escludeva esplicitamente dal globbing (anche questo un errore). Quindi non si tratta di un bug del codice, ma di una scarsa igiene nella progettazione della CI che causa la perdita di segreti con gli output di tj-actions/changed-files.
Percorso pratico di exploit: dal lavoro CI all'esposizione delle credenziali
Esempio di configurazione CI che ha causato la perdita di segreti tramite 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 cambiato:
- È stato segnalato da tj‑actions/changed‑files
- È stato incluso in steps.changed.outputs.all_changed_files
- I passaggi successivi lo hanno registrato o lo hanno passato agli script, facendo trapelare i segreti
Questa fuga di notizie si è verificata perché la logica di CI trattava i segreti come file normali. È qui che inizia la fuga di notizie, non a causa di un buffer overflow, ma a causa dell'uso improprio di tj-actions/changed-files in una progettazione di CI difettosa.
La propagazione avviene con output come:
yaml
‑ name: Use changed file list
run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}"
If segreti.env è presente in quell'elenco, il suo nome file e il suo possibile contenuto potrebbero comparire nei log di build. Anche la logica condizionale come:
yaml
if: contains(steps.changed.outputs.all_changed_files, 'secrets.env')
Può esporre artefatti sensibili. Questo è un CI/CD errore di progettazione che consente la fuga di informazioni segrete, non un difetto nel codice Action.
Come utilizzare in modo sicuro i flussi di lavoro riutilizzabili e prevenire le perdite
Non è necessario abbandonare tj-actions/changed-files. È consigliabile utilizzare azioni riutilizzabili con un approccio che dia priorità ai segreti:
Segreti: migliori pratiche per la gestione
- Non controllare mai la versione dei segreti
- Evita modelli glob che corrispondono a percorsi sensibili
- Utilizzare segreti basati sull'ambiente (GITHUB_ENV, vault, segreti GitHub)
CI/CD Configurazione Guardrails
- Aggiungi sempre le azioni agli SHA immutabili, non ai tag (non usare mai @ V45)
- Tratta l'output di tj-actions/changed-files come contaminato, disinfettalo o filtralo
- Imposta le uscite solo se sanificate
⚠️ Esempio non sicuro:
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
Quanto sopra è esattamente l'abuso alla base della fuga di notizie segreta e della vulnerabilità CVE‑2025‑30066.
Alternativa sicura:
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
Facendo questo, si evita il CI/CD errore di progettazione che porta alla fuga di informazioni segrete tramite tj-actions/changed-files.
Inoltre:
- Disabilitare o limitare la registrazione in cui potrebbero apparire segreti
- Utilizzare le funzionalità di mascheramento segrete di GitHub
- Limitare l'accesso ai log di build e agli artefatti
Quick Secrets: checklist per l'utilizzo sicuro di CI
| Best Practice |
|---|
| Non memorizzare i segreti nei file con controllo di versione |
| Utilizzare vault o GitHub Secrets per le credenziali |
| Aggiungi sempre tj-actions/changed-files agli SHA immutabili |
| Filtra o sanifica gli output da tj-actions/changed-files |
| Non includere mai percorsi segreti nei modelli glob |
| Mascherare o limitare i registri che potrebbero esporre dati sensibili |
| Controlla spesso le configurazioni CI ereditate |
Ruolo di Xygeni: applicazione dei segreti CI su larga scala
Xygeni Protegge CI/CD pipelines concentrandosi su come i segreti vengono gestiti, utilizzati e svelati nel mondo reale Flussi di lavoro DevOps. Non si tratta solo di scansionare il codice; si tratta di applicare le migliori pratiche di gestione dei segreti tramite l'implementazione in tempo reale. pipeline analisi.
Rilevamento dell'utilizzo di output non sicuro
- Scansiona le azioni GitHub per usi di echo, run e output dove ${{ steps.*.outputs.* }} potrebbe includere valori sensibili
- Identifica quando i segreti vengono citati o stampati direttamente, intenzionalmente o per errore
Monitoraggio dei segreti trapelati
- Rileva valori ad alta entropia (chiavi API, token) all'interno di log e output di step
- Attiva avvisi quando compaiono segreti nel pipeline registri, anche se mascherati a valle
Utilizzo di azioni configurate in modo errato
- Tiene traccia di tutte le azioni GitHub pipelineper rilevare l'uso di versioni compromesse (ad esempio, tj-actions/changed-files@v45)
- Controlla i modelli di corrispondenza dei file che includono potenziali segreti come **/*.env, *.key o .env.*
CI basata su policy Guardrails
- Applica il pinning SHA per le azioni di terze parti
- Blocca l'uso di file glob non sicuri che potrebbero nascondere segreti nei log
- previene pipelines dall'emissione di valori sensibili come parte degli output del flusso di lavoro
Considerando i flussi di lavoro come parte della superficie di minaccia, Xygeni garantisce che l'igiene segreta non sia solo una buona pratica, ma una difesa integrata.
Conclusione: la fuga di notizie segrete può iniziare con un semplice uso improprio di un'azione
CVE‑2025‑30066 non era un bug della libreria; era un CI/CD Errori di progettazione derivanti dall'uso improprio di tj-actions/changed-files. Cosa dovrebbero imparare i team DevSecOps:
- Tratta ogni riferimento glob/file in CI come un potenziale punto di perdita
- Controllare regolarmente i flussi di lavoro per l'inclusione accidentale di segreti
- Utilizzare archivi sicuri o segreti ambientali, non archiviare mai i segreti nel controllo di versione
- Sanificare o filtrare tutti gli output del flusso di lavoro
- Registrare le attività del flusso di lavoro sensibili per mantenere la verificabilità
La CI è codice. I flussi di lavoro sono codice. I log e gli output sono codice. Proteggi i tuoi segreti in ogni fase, o rischi una fuga di segreti che non richiede un hacker, ma solo un cattivo CI/CD scelta progettuale.
