ANALISI
GitHub Actions, 23.000 repository: quando la pipeline espone le chiavi
Il 14 e 15 marzo 2025 il componente tj-actions/changed-files, usato da oltre 23.000 repository, è stato alterato per stampare nei log i segreti CI/CD; il primo bersaglio era un progetto di Coinbase. L'analisi: costi senza furto, pipeline come fornitore, responsabilità, cumulo e domande per i rinnovi.
Archivio: ricostruzione scritta a novembre 2026
Tema del mese di marzo 2025 · di cybercoverinsurance
Il 14 e 15 marzo 2025 tj-actions/changed-files, un componente di GitHub Actions usato da più di 23.000 repository, è stato modificato per stampare nei log di compilazione i segreti dei progetti che lo usavano: chiavi cloud, token di accesso, chiavi private. Pochi giorni prima era stato compromesso un altro componente, reviewdog/action-setup. Le analisi successive hanno indicato come primo bersaglio un progetto open source di Coinbase.
Per chi assume il rischio cyber il caso è utile anche se non ha prodotto grandi sinistri noti. Mostra come un solo componente della catena di compilazione possa esporre in poche ore le credenziali di migliaia di organizzazioni, e pone tre domande: cosa succede quando i segreti escono ma nessuno li usa, chi risponde se dalla pipeline esce codice manomesso, e come si misura un cumulo che passa dagli strumenti degli sviluppatori.
Cosa si sa
Il componente. tj-actions/changed-files è una GitHub Action che rileva quali file sono cambiati in un progetto. Secondo StepSecurity era usata da più di 23.000 repository. Il codice alterato eseguiva uno script che leggeva dalla memoria del processo di compilazione i segreti CI/CD (chiavi API, password, token) e li scriveva nei log. Nei progetti con log pubblici, i segreti erano leggibili da chiunque. Wiz ha trovato decine di repository pubblici con segreti esposti, tra cui chiavi AWS valide, token GitHub e npm e chiavi RSA private (The Register).
La causa. L'attacco è passato da un token di accesso personale legato all'account automatico @tj-actions-bot. GitHub ha dichiarato di non poter stabilire come sia stato compromesso. Il componente è tracciato come CVE-2025-30066, con punteggio 8,6 (The Register). La CISA lo ha inserito nel suo catalogo delle vulnerabilità sfruttate, con un avviso del 18 marzo (Cybersecurity Dive).
La catena. L'11 marzo era stato compromesso reviewdog/action-setup (CVE-2025-30154), per circa due ore e su circa 1.500 repository secondo Wiz. La compromissione di tj-actions è durata circa 22 ore e ha toccato circa 14.000 repository. Endor Labs ha contato circa 218 repository che hanno effettivamente esposto segreti, per lo più token GitHub che scadono a fine lavoro (Cybersecurity Dive).
Il bersaglio. Secondo Unit 42 di Palo Alto Networks, poi confermata da Wiz, l'attaccante puntava prima al flusso CI/CD pubblico di agentkit, un progetto open source di Coinbase. Il 14 marzo aveva ottenuto un token con permessi di scrittura sul repository, ma non è riuscito ad accedere ai segreti di Coinbase né a pubblicare pacchetti. Dopo la reazione di Coinbase è passato all'attacco esteso su tutte le versioni di tj-actions (Cybersecurity Dive).
Cosa non è noto. Non risultano pubblicamente furti di dati o frodi riconducibili ai segreti esposti. Non c'è prova che i segreti dei repository pubblici siano stati inviati a server esterni (The Register). Quante organizzazioni abbiano sostenuto costi di bonifica, e quanto, non è noto.
Il segreto esposto è già un incidente
Nessun furto noto, molti costi certi. Le indicazioni di GitHub, Wiz e Sysdig erano le stesse: considerare compromessi i progetti, ruotare tutti i segreti, controllare i flussi eseguiti tra il 14 e il 15 marzo (The Register, Cybersecurity Dive). Per un'azienda con decine di pipeline, è un lavoro di giorni tra analisi dei log, rotazione delle chiavi e verifica degli accessi cloud.
La polizza deve dire se risponde. Molte polizze cyber coprono i costi di risposta dopo un evento di sicurezza, ma la definizione varia: accesso non autorizzato, violazione sospetta, compromissione di credenziali. Un segreto stampato in un log pubblico, senza prova di uso, sta al confine. Per chi assume il rischio, conviene chiarire prima se i costi di analisi e rotazione sono coperti anche in assenza di accesso accertato.
Il valore del segreto dipende da cosa apre. Un token GitHub che scade a fine lavoro vale poco. Una chiave AWS valida apre l'ambiente cloud di produzione. La gravità dell'incidente, e del possibile sinistro, dipende dai permessi del segreto più che dal componente compromesso.
La pipeline è un fornitore
Il codice di terzi gira con le chiavi dell'assicurato. Una GitHub Action è codice di un terzo, scaricato a ogni esecuzione, che lavora con i segreti del progetto. È lo stesso schema del caso Polymarket nel 2026 e di Bybit nel 2025: codice esterno eseguito nel punto più delicato. Nella pipeline il punto delicato sono le chiavi di pubblicazione e di accesso al cloud.
Il riferimento per versione non protegge. L'attaccante ha spostato tutte le etichette di versione di tj-actions sul codice malevolo. Chi richiamava il componente per versione ha ricevuto il codice nuovo senza accorgersene. GitHub raccomanda di fissare ogni Action all'identificativo completo del commit (The Register). È un controllo semplice, verificabile, e poco diffuso.
Gli account automatici sono identità privilegiate. Il punto d'ingresso è stato il token di un account bot. Questi account hanno spesso permessi ampi, nessuna autenticazione a più fattori e token che non scadono. Dopo l'incidente tj-actions ha ridotto i permessi, aggiunto passkey e imposto commit firmati (The Register).
Responsabilità e cumulo
Il rischio maggiore è il codice che esce, non quello che entra. In questo caso l'attaccante ha cercato segreti. Con un token di scrittura avrebbe potuto inserire codice nei pacchetti pubblicati da un progetto. Per un'azienda di software, un pacchetto manomesso distribuito ai clienti è un sinistro di responsabilità verso terzi, con possibili effetti su molte vittime a valle.
Il cumulo passa dagli strumenti, non dai settori. Le stesse Actions sono usate da banche, aziende di software, assicuratori e pubbliche amministrazioni. Un portafoglio diversificato per settore può essere concentrato sugli stessi strumenti di sviluppo. Il dato non emerge dai questionari tradizionali.
L'evento è uno, le scadenze sono molte. La compromissione è durata ore, ma i segreti esposti possono essere usati settimane dopo se nessuno li ruota. Un evento con causa unica può produrre sinistri distribuiti nel tempo, con questioni di aggregazione simili a quelle di Cleo e MOVEit.
Cosa portare ai rinnovi
Impatto per gli assicuratoriMedio
Un componente di GitHub Actions usato da oltre 23.000 repository ha esposto i segreti CI/CD per circa 22 ore, senza grandi sinistri noti ma con costi di bonifica diffusi.
Sul fronte del portafoglio, la domanda utile è quanti assicurati usano GitHub Actions o strumenti simili con componenti di terzi non fissati. Per le aziende di software, l'esposizione di responsabilità verso i clienti per codice manomesso va valutata insieme a quella cyber propria.