Il codice pubblico su GitHub conteneva ancora 543.699 credenziali funzionanti

Truffle Security ha individuato 543.699 credenziali uniche nei repository pubblici di GitHub che, una volta testate alla fine di luglio 2026, risultavano ancora accettate dai servizi che le avevano rilasciate.

Il risultato mette in luce una lacuna tra il rilevamento di un segreto pubblicato e la sua disattivazione. Chiavi API, credenziali di account di servizio, token e stringhe di connessione ai database possono continuare a garantire l’accesso finché il titolare o il fornitore del servizio non le ruota o revoca.

L’analisi si è basata su un set di dati raccolto per addestrare modelli linguistici di grandi dimensioni. Secondo il resoconto della ricerca di BleepingComputer, la scansione alla base dello studio ha coperto 224 milioni di repository e oltre 58 miliardi di file, prima di concludersi il 7 agosto 2025.

SecurityWeek riferisce che la scansione ha individuato complessivamente 1.103.438 credenziali esposte. In seguito, Truffle ha stabilito che 543.699 erano ancora attive. La ricerca ha misurato l’esposizione pubblica e la persistente validità delle credenziali, non se gli aggressori le avessero scoperte o sfruttate.

Alcune credenziali sono rimaste pubbliche per anni

La mediana delle credenziali uniche è rimasta accessibile al pubblico per 784 giorni. Circa il 10% di quelle ancora funzionanti aveva più di 6,3 anni, mentre un quarto delle credenziali individuate risaliva a oltre quattro anni prima.

Alcune erano molto più vecchie. Truffle ha trovato 2.636 credenziali attive in file modificati per l’ultima volta prima del 2015. La più datata era una chiave AWS inserita nel 2009 e mai più modificata, secondo SecurityWeek.

Questi dati rendono il codice storico una componente centrale del problema. Truffle ha individuato credenziali in oltre 1,1 milioni di file e repository, comprese copie presenti nei fork. Rimuovere un segreto dalla versione corrente di un progetto, quindi, non basta a eliminarlo da tutti i luoghi in cui potrebbe essere comparso.

Inoltre, la cancellazione non revoca la credenziale. Se il servizio che l’ha rilasciata continua ad accettare il valore originale, una copia recuperata da un vecchio file o repository pubblico può restare utilizzabile.

Nel periodo analizzato è aumentata la densità di credenziali funzionanti. Nel 2015 Truffle ha registrato 3,72 credenziali attive ogni milione di file, un dato salito fino al picco di 11,62 ogni milione di file nel 2025.

I risultati su GitHub hanno superato anche quelli della precedente analisi di Truffle su Hugging Face, che aveva individuato 221.303 credenziali funzionanti: meno della metà rispetto a quanto riportato nel set di dati di GitHub.

I tassi di validità variavano nettamente tra i tipi di credenziali

La probabilità che un segreto esposto fosse ancora funzionante variava notevolmente a seconda della categoria e del servizio che lo aveva rilasciato.

Delle 126.963 credenziali esposte degli account di servizio Google Cloud, 69.041 erano ancora valide. SecurityWeek ha indicato questa come la categoria più numerosa tra quelle di credenziali attive riportate. Tra le altre categorie segnalate figuravano:

• 51.067 stringhe di connessione MongoDB attive
• 33.343 chiavi API Google ancora valide
• Un solo token npm funzionante su 101.886 token npm inseriti

Il dato relativo a npm contrasta nettamente con quelli delle altre categorie. Quasi tutti i token npm inseriti nel set di dati avevano smesso di funzionare, mentre decine di migliaia di credenziali Google Cloud, stringhe di connessione MongoDB e chiavi API Google continuavano a essere accettate.

Le pratiche di revoca dei fornitori incidono sulla durata del rischio legato a un’esposizione. GitHub può rilevare o segnalare determinati segreti, ma non può invalidare autonomamente le credenziali rilasciate da un altro servizio.

I resoconti non specificano i diritti di accesso associati a ciascuna credenziale funzionante. Il dato di 543.699, quindi, non va interpretato come il numero di account, sistemi o ambienti cloud compromessi. Ogni segreto consente l’accesso solo alle risorse e ai privilegi a cui è associato, che possono variare considerevolmente.

La persistente validità delle credenziali crea comunque un’opportunità di accesso non autorizzato. Se il servizio corrispondente continua a riconoscere una credenziale pubblicamente accessibile, non è necessario aggirare le sue protezioni tecniche.

Push Protection ha ridotto l’esposizione solo entro i limiti della sua copertura

Push Protection di GitHub analizza il codice in arrivo alla ricerca di schemi riconducibili a segreti, come chiavi API e token di accesso. Quando individua un segreto supportato, può bloccare il push prima che la credenziale venga resa pubblica.

BleepingComputer riferisce che la funzionalità è stata introdotta per gli utenti di Advanced Security nell’aprile 2022 e resa disponibile per i repository pubblici nel maggio 2023. Il sito afferma inoltre che GitHub ha attivato Push Protection per tutti gli utenti nel febbraio 2024. Un’altra descrizione della distribuzione, nello stesso resoconto, non coincide con precisione con queste date.

Truffle ha suddiviso le credenziali attive in tre gruppi:

• 245.959 erano state pubblicate prima dell’introduzione degli avvisi gratuiti di scansione dei segreti.
• 97.897 erano comparse quando la scansione era gratuita, ma Push Protection non era ancora attiva per impostazione predefinita.
• 199.843 erano state esposte dopo che il blocco era diventato l’impostazione predefinita.

L’ultimo gruppo rappresentava circa il 36,8% del totale delle credenziali attive. Quasi 200.000 credenziali pubblicate durante il periodo in cui il blocco era attivo per impostazione predefinita risultavano ancora accettate al momento dei test di Truffle.

Questo non significa che la misura di protezione fosse inefficace. Per le categorie di credenziali coperte da Push Protection, il tasso di esposizione è diminuito del 53% dopo l’attivazione predefinita della funzionalità. La riduzione riguarda soltanto le categorie protette, non l’esposizione complessiva delle credenziali.

La copertura è un limite importante. BleepingComputer riferisce che il 51,8% delle credenziali ancora valide apparteneva a categorie non bloccate da Push Protection per impostazione predefinita, tra cui le stringhe di connessione ai database e le chiavi API Google.

Push Protection interviene anche sui nuovi tentativi di pubblicare segreti supportati, ma non revoca le credenziali esposte prima che la protezione entrasse in azione.

Gli avvisi sui segreti richiedono comunque un intervento dei titolari e dei fornitori

GitHub gestisce un programma di scansione dei segreti che invia i token esposti ai servizi che li hanno rilasciati. Tuttavia, non impone a questi fornitori di revocare le credenziali segnalate.

Secondo Truffle, parte dell’esposizione persistente è dovuta a fornitori che potrebbero non disporre di procedure per invalidare i token trapelati. Come spiega l’analisi dei risultati pubblicata da SecurityWeek, anche gli avvisi relativi a esposizioni storiche dipendono dal fatto che i titolari dei repository li attivino, esaminino i risultati e ruotino le credenziali interessate.

La correzione può quindi interrompersi in diversi punti:

1. GitHub o un altro scanner deve riconoscere la credenziale.
2. L’avviso deve raggiungere il titolare del repository o il fornitore che ha rilasciato la credenziale.
3. Qualcuno deve valutare la segnalazione.
4. La credenziale esposta deve essere revocata o ruotata.

Il solo rilevamento non rende inutilizzabile la credenziale. Anche rimuovere la stringa dal codice visibile senza invalidarla presenta lo stesso limite.

È inoltre importante interpretare con cautela i risultati. Truffle ha verificato che le credenziali fossero esposte e ancora funzionanti, ma la ricerca non ha stabilito quale percentuale fosse stata sottratta o utilizzata dagli aggressori.

La priorità immediata è ruotare le credenziali e analizzare lo storico

Le raccomandazioni di Truffle partono dalla rotazione immediata delle credenziali esposte. Le organizzazioni dovrebbero trattare la pubblicazione di un segreto come un incidente relativo al ciclo di vita delle credenziali, non solo come un problema di pulizia del codice.

I team interessati dovrebbero:

1. Ruotare immediatamente le credenziali esposte. Il valore pubblicato deve smettere di funzionare presso il servizio che lo ha rilasciato.
2. Rimuovere i segreti dai repository. In questo modo si riduce la loro visibilità, ma non si sostituisce la revoca.
3. Analizzare lo storico dei repository. Controllare solo la versione corrente può non bastare a individuare le credenziali presenti in file o commit precedenti.
4. Configurare la scadenza automatica. I segreti a validità limitata riducono il periodo durante il quale un’esposizione non rilevata resta sfruttabile.
5. Usare Push Protection e gli avvisi di scansione dei segreti. Queste misure possono bloccare o individuare i tipi di segreto supportati, ma devono alimentare un processo di rotazione efficace.

Nelle verifiche dei repository occorre considerare i fork e le copie ripetute emerse durante l’indagine. I team dovrebbero inoltre esaminare i log dei fornitori pertinenti per individuare attività legate alle credenziali esposte, poiché la ricerca aggregata non consente di stabilire se i segreti di una specifica organizzazione siano stati usati impropriamente.

I due resoconti pubblicati non riportano i valori delle credenziali né gli URL dei repository interessati. Le organizzazioni devono quindi controllare il proprio codice pubblico, lo storico dei repository e gli inventari delle credenziali, senza aspettare un elenco universale di segreti esposti.

Il problema centrale non è soltanto che gli sviluppatori abbiano inserito valori sensibili nel codice. È che centinaia di migliaia di quei valori siano rimasti attivi, in alcuni casi per anni dopo essere diventati pubblicamente accessibili.