543.699 credenziali attive ancora esposte su GitHub: il buco…

Il 27-28 luglio 2026 Truffle Security ha verificato in tempo reale 543.699 credenziali uniche ancora attive, trovate in 224.553.295 repository pubblici GitHub. La

{"main_topic":"cybersecurity","topics":["cybersec","vulnerabilita","cloud","api","developer"]}

Il 27-28 luglio 2026 Truffle Security ha verificato in tempo reale 543.699 credenziali uniche ancora attive, trovate in 224.553.295 repository pubblici GitHub. La mediana di esposizione è di 784 giorni. Circa 200.000 di queste credenziali sono state caricate dopo l'attivazione della push protection di default da parte di GitHub, il 29 febbraio 2024. Il dato non segnala un fallimento della rilevazione, ma un fallimento sistematico della revoca da parte dei provider di servizi cloud.

Punti chiave

543.699 credenziali uniche attive al luglio 2026 in 224 milioni di repository pubblici GitHub, con mediana di esposizione di 784 giorni
Il 51,8% delle credenziali attive appartiene a tipologie non coperte dalla push protection default di GitHub, tra cui MongoDB connection strings e Google API keys
199.843 credenziali (36,8%) sono state caricate dopo il febbraio 2024, quando GitHub ha attivato il blocco preventivo per default
La credenziale attiva più vecchia è una chiave AWS committata nel novembre 2009, confermata attiva dopo 16 anni

La ricerca: metodologia e risultati del campione

Truffle Security ha analizzato il dataset The Stack v3, assemblato per l'addestramento di modelli linguistici di grandi dimensioni, con crawl chiuso il 7 agosto 2025. Il campione comprende 224.553.295 repository pubblici e 58.467.468.698 file. Le credenziali candidate sono state testate direttamente contro i provider emittenti il 27-28 luglio 2026: 543.699 hanno risposto positivamente all'autenticazione, confermando lo stato attivo.

Il dato di 1.103.438 esposizioni totali include duplicati in fork e file diversi, ma le credenziali uniche attive sono 543.699. La mediana temporale di esposizione è calcolata dal timestamp dell'ultima modifica del file al giorno della verifica: 784 giorni, oltre due anni. Il 25% delle credenziali è più vecchio di 4 anni; 2.636 provengono da file modificati prima del 2015.

La densità di credenziali attive nel dataset è cresciuta nel tempo: da 3,72 per milione di file nel 2014 a 11,62 per milione nel 2025, secondo i calcoli di Truffle Security su file dello stesso periodo. La categoria più numerosa è rappresentata da Google Cloud service account credentials, con 69.041 credenziali attive.

Push protection: funziona dove si applica, ma copre meno della metà del problema

GitHub ha attivato la push protection di default il 29 febbraio 2024, bloccando il commit di pattern specifici di credenziali. Il meccanismo riconosce oltre 200 tipi di secret da più di 180 provider. Secondo i dati di BleepingComputer e Truffle Security, il tasso di esposizione nelle categorie protette si è ridotto del 53% dopo l'attivazione default.

Tuttavia, il 51,8% delle credenziali attive riscontrate nel luglio 2026 appartiene a tipologie escluse dal blocco. Tra queste: 51.067 MongoDB connection strings, 33.343 Google API keys e chiavi private. Le Google API keys sono marcate esplicitamente come "not push protected" nella documentazione di GitHub per design del provider.

Truffle Security ha formulato la distinzione in modo inequivocabile: "The block does work where it applies, roughly halving the rate at which the credentials it recognises reach public code, but 51.8 percent of what is still live is a shape it does not recognise". La push protection, secondo la stessa fonte, "is a good control and stops secrets at the door. It has nothing to say about the 543,699 already inside, and it was never meant to".

Il meccanismo di forwarding e il vuoto di revoca

GitHub opera il secret scanning partner program, che inoltra le credenziali esposte ai provider interessati. Il meccanismo è passivo: la piattaforma notifica, ma non impone la revoca. Il provider può non agire, agire parzialmente o non avere implementato pipeline automatiche di disattivazione.

AWS rappresenta un'eccezione parziale nel panorama. Secondo il contesto tecnico fornito da Unit 42 di Palo Alto Networks, AWS risponde alle credenziali esposte con la policy AWSCompromisedKeyQuarantine, che limita i permessi associati alla chiave identificata come compromessa. La misura non costituisce revoca automatica: la chiave rimane tecnicamente attiva, sebbene con capacità operative ridotte.

Il caso della chiave AWS del 2009 — identificata in un file di configurazione Rails per S3, confermata attiva al test di luglio 2026 — illustra la durata del gap. Nessun meccanismo di quarantena o notifica ha disattivato la credenziale in 16 anni, se non è intervenuta una revoca manuale successiva al test di Truffle Security.

"A leaked key that has been revoked is trivia. A leaked key that still authenticates is access." — Truffle Security

Perche è importante

Il dossier non specifica quante delle 543.699 credenziali siano state effettivamente sfruttate da attori malevoli: Truffle Security non ha analizzato accessi anomali né tracciato abusi. Il report non indica la distribuzione tra organizzazioni e utenti individuali, né fornisce dettagli geografici o settoriali. Non risulta documentato se i provider abbiano avviato revoche massive dopo la pubblicazione dei dati.

Il brief non elenca misure correttive specifiche da parte dei singoli provider interessati. Non emerge il motivo per cui categorie come le Google API keys non siano incluse nella push protection, se non per la scelta di design del provider. Il dossier non quantifica l'impatto economico diretto delle esposizioni.

Il dato rilevante per la governance è la persistenza: 199.843 credenziali caricate dopo l'attivazione della push protection default dimostrano che i controlli preventivi non eliminano la superficie di attacco storica. La crescita della densità di esposizioni nel tempo, da 3,72 a 11,62 per milione di file, indica che l'adozione di strumenti di scanning non ha invertito la tendenza strutturale.

Domande frequenti

La push protection di GitHub ha fallito?: No, secondo i dati del report ha ridotto del 53% il tasso di esposizione nelle categorie che copre. Il problema è che il 51,8% delle credenziali attive appartiene a categorie escluse per design, e che le credenziali preesistenti non sono state revocate.
Perché le credenziali del 2009 sono ancora attive?: Il dossier documenta che la chiave AWS è stata confermata attiva al test del luglio 2026, senza indicare se AWS o il proprietario abbiano agito successivamente. Non emergono automatismi di revoca obbligatoria nel periodo precedente.
I provider sono obbligati a revocare?: Secondo il report di Truffle Security e il contesto di Unit 42, il meccanismo di forwarding di GitHub è di notifica, non di enforcement. La revoca non è obbligatoria e dipende dalle policy interne di ciascun provider.

Il caso riapre una questione di architettura della responsabilità: GitHub rileva e blocca, i provider ricevono notifiche, ma nessun anello della catena garantisce che una credenziale esposta pubblicamente venga disattivata entro tempi certi. La mediana di 784 giorni non è un ritardo tecnico, ma una misura del vuoto normativo nel secret management distribuito.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter