Un nuovo studio di Truffle Security, ripreso da BleepingComputer, SecurityWeek e dalla Cloud Security Alliance, mette un numero su un problema che i team di sviluppo conoscono bene: i segreti committati per errore nei repository pubblici di GitHub non spariscono, e molti restano perfettamente funzionanti. I ricercatori hanno analizzato circa 224 milioni di repository e 58 miliardi di file, trovando 543.699 credenziali uniche che, testate a luglio 2026, autenticavano ancora con successo.

I numeri dello studio

Secondo SecurityWeek, l'analisi era partita da oltre 1,1 milioni di esposizioni di credenziali individuate nell'agosto 2025; la verifica di luglio 2026 ha poi stabilito quante fossero ancora attive. Le principali evidenze riportate dalle fonti:

  • La vita mediana di una credenziale pubblicamente accessibile è di 784 giorni; circa il 10% di quelle ancora valide ha più di 6,3 anni e la più vecchia risale al 2009.
  • Le categorie più numerose sono i service account di Google Cloud (69.041), le stringhe di connessione MongoDB (51.067) e le chiavi API Google (33.343, in gran parte legate a Gemini, secondo la CSA).
  • La densità di segreti validi nei file è salita da 3,72 per milione di file nel 2015 a 11,62 nel 2025.
  • La push protection, attiva di default da febbraio 2024, ha ridotto del 53% le esposizioni nelle categorie che copre. Eppure circa 199.843 credenziali (il 36,8%) sono state committate dopo la sua attivazione.
  • Circa il 52% delle credenziali ancora attive appartiene a formati che la push protection non blocca, come le stringhe di connessione ai database e le chiavi API Google.

Il dato più istruttivo riguarda la revoca. Dei 101.886 token npm trovati, ne risulta ancora valido uno solo; dei 126.963 service account Google Cloud, invece, ne funzionano ancora 69.041. La differenza non dipende da chi ha sbagliato, ma da quanto il fornitore del servizio revoca automaticamente i token segnalati. Come osserva Truffle Security, il programma di secret scanning di GitHub avvisa i provider ma non impone loro di invalidare la credenziale.

Cosa dicono (e cosa non dicono) i dati

Va tenuta distinta la parte misurata da quella ipotetica. La nota della Cloud Security Alliance aggiunge una lettura sul rischio nell'era degli agenti AI: automatizzare l'enumerazione delle API, l'interpretazione dei dati e il concatenamento dei permessi potrebbe abbassare il costo di sfruttamento di queste credenziali. La stessa CSA la definisce un possibile cambio dell'economia dell'attaccante, non una minaccia già misurata. Lo studio dimostra che le credenziali sono valide, non che siano state sfruttate su larga scala: è un'osservazione importante per non sovrastimare il dato.

Cosa significa per le aziende italiane

La lezione per le imprese italiane è meno su GitHub e più sul processo. Molte PMI e software house affidano lo sviluppo a fornitori esterni o a freelance che lavorano su repository propri, spesso pubblici o semi-pubblici. Una chiave di database finita in un repository di un collaboratore, anche chiuso da tempo, è un problema dell'azienda cliente: è il suo database, e sono i suoi i dati personali che contiene.

Qui entrano in gioco gli obblighi. Il GDPR impone misure di sicurezza adeguate (art. 32) e, se una credenziale esposta ha consentito o può aver consentito l'accesso a dati personali, il titolare deve valutare l'obbligo di notifica al Garante entro 72 ore dalla scoperta. Per i soggetti NIS2 la gestione dei segreti rientra nelle misure di sicurezza e nella protezione della catena di fornitura, aspetti su cui l'ACN richiama alla maturità dei processi nelle prossime scadenze. Il punto pratico è che rimuovere il file dal repository non basta: la credenziale resta nella cronologia dei commit, nei fork e nelle copie, e continua a funzionare finché non viene revocata.

Un aspetto spesso sottovalutato: le categorie che la push protection non intercetta (stringhe di connessione, chiavi API generiche) sono proprio quelle che un'azienda usa tutti i giorni. Affidarsi solo al controllo preventivo di GitHub dà una falsa sicurezza.

Cosa fare subito

  • Ruotare ogni credenziale che sia mai stata committata in un repository pubblico, anche se il commit è stato poi cancellato: la rimozione dal codice non la invalida.
  • Scansionare l'intera cronologia dei repository, inclusi quelli archiviati, dimenticati o appartenenti a ex collaboratori e fornitori, con strumenti di secret scanning.
  • Abilitare push protection e, dove possibile, configurare pattern personalizzati per i token interni che i controlli standard non riconoscono.
  • Usare credenziali a scadenza (token a breve durata, federazione di identità) al posto di chiavi statiche: se la chiave scade da sola, l'errore di oggi smette di essere un rischio tra due anni.
  • Ridurre i privilegi: un service account con permessi minimi limita il danno anche se viene scoperto.
  • Verificare i contratti con i fornitori di sviluppo: devono prevedere regole su dove sta il codice, chi lo può pubblicare e come si segnalano le esposizioni.
  • Controllare i log di accesso dei servizi coinvolti (cloud, database, API) per attività anomale legate a chiavi esposte.

Il dato dei 784 giorni, in fondo, è un'indicazione sui tempi di reazione: la correzione più efficace non è trovare il segreto più in fretta, ma costruire un processo in cui revocarlo sia un'operazione di routine.