Lo studio Truffle conta 543.699 credenziali databili ancora valide nei controlli di luglio 2026. Come leggere il campione e distinguere blocco del caricamento, avvisi e revoca.
Truffle Security ha pubblicato il 29 settembre 2026 uno studio su The Stack v3, una raccolta di codice pubblico che comprende circa 224 milioni di repository GitHub. Il risultato centrale sono 543.699 credenziali uniche e databili che riuscivano ancora ad autenticarsi nei controlli del 27 e 28 luglio 2026. È una fotografia del campione in quelle date, non il conteggio di un nuovo attacco. La validità segnala un’esposizione da gestire, ma da sola non prova un uso abusivo e non rivela quali risorse, permessi o ambienti siano raggiungibili. [1][4]
Per capire la durata del problema, i ricercatori hanno usato l’ultima modifica del file che contiene la credenziale, scegliendo il timestamp più antico fra le copie individuate. La mediana è 784 giorni; il caso più vecchio risale al 13 giugno 2009, oltre sedici anni prima del controllo. Questo indicatore non coincide necessariamente con il primo inserimento della chiave: una modifica successiva del file sposta in avanti la data osservata. Non permette quindi di ricostruire con precisione quando ogni credenziale è diventata pubblica. [1]
Il corpus comprende circa 58,4 miliardi di file e conserva il branch predefinito come appariva al momento della raccolta, chiusa il 7 agosto 2025. Non contiene l’intera cronologia Git né i branch secondari: i risultati non descrivono tutti i segreti mai transitati sulla piattaforma. Per il confronto sulla revoca sono stati selezionati valori con una struttura riconoscibile, evitando stringhe soltanto esadecimali, base64 o UUID che potrebbero essere normale contenuto dei file. Questa selezione rende il campione interpretabile, senza trasformarlo in un censimento completo. [1]
Anche i diversi totali richiedono attenzione. La scansione ha restituito 544.069 credenziali distinte ancora valide; di queste, 543.699 hanno una data utilizzabile e costituiscono il campione temporale discusso nell’articolo. Le loro occorrenze nei file e nei repository sono 1.103.438. La deduplicazione conta una stessa chiave una sola volta anche quando compare in più copie o fork: il numero delle esposizioni e quello delle credenziali sono quindi due misure diverse, che non vanno sommate. [1]
Sintesi dei fatti documentati nell’articolo. I riferimenti sono riportati sotto lo schema.
I dati mostrano una divergenza netta tra i provider che implementano sistemi di revoca automatica e quelli che non lo fanno. I token npm e GitHub presentano tassi di sopravvivenza quasi nulli: solo 1 token npm su 101.886 e 260 token GitHub su 73.048 risultano ancora attivi. Al contrario, le stringhe di connessione per database come Postgres e MySQL mostrano tassi di sopravvivenza altissimi, rispettivamente dell'88% e del 75%, poiché non esiste un meccanismo centralizzato di revoca automatica per queste URI. [1]
Alcuni dati richiedono cautela interpretativa. Ad esempio, per MongoDB tutte le 51.067 credenziali verificate erano attive, ma questo è un artefatto di misurazione: il detector segnala solo le URI a cui riesce effettivamente a connettersi. Per Google, sono state testate solo le chiavi Gemini (31.374 attive), escludendo Maps e Firebase che spesso non sono considerate segreti sensibili. Le chiavi private RSA sono state escluse dal calcolo del tasso di sopravvivenza poiché la loro verifica richiede la conoscenza dell'host di appartenenza. [1]
Dati Truffle, The Stack v3; verifica 27–28 luglio 2026. Conteggi per tipo e denominatori specifici, non una misura della sicurezza di tutte le piattaforme.
| Caratteristica | Rilevate nel corpus | Valide al controllo |
|---|---|---|
| npm [1] | 101.886 | 1 |
| GitHub [1] | 73.048 | 260 |
| Google Cloud service account [1] | 126.963 | 69.041 |
| Postgres [1] | 12.985 | 11.465 |
| MySQL [1] | 2.421 | 1.806 |
La push protection interviene prima che un segreto riconosciuto raggiunga il repository. Per valutarla, Truffle confronta la densità delle esposizioni, normalizzata per milione di file, nei dodici mesi prima e dopo il periodo di distribuzione del 2024. Le famiglie coperte dal blocco predefinito diminuiscono del 53%, quelle del gruppo di confronto del 7%. È un risultato osservazionale: il rollout graduale, le configurazioni delle organizzazioni e il passaggio a credenziali di breve durata possono contribuire alla differenza. Non è una prova controllata che isoli l’effetto del blocco da ogni altro cambiamento. [1]
Lo studio stima inoltre che il 51,8% delle credenziali attive del suo campione abbia una forma non bloccata dalla configurazione predefinita. La documentazione GitHub distingue avvisi, supporto alla push protection e controlli di validità: riconoscere un pattern non significa offrire automaticamente tutte e tre le capacità. Prima di intervenire bisogna controllare la riga relativa a quel tipo di segreto e le opzioni effettive del repository. Per i pattern generici, ad esempio, GitHub non supporta i controlli di validità; per le password rilevate tramite AI non supporta né push protection né verifica di validità. [1][3]
Cancellare il file, sostituirne il contenuto o riscrivere la cronologia non revoca la credenziale presso il servizio che l’ha emessa. Una copia può essere stata acquisita altrove e continuare a consentire l’autenticazione. Il passo che rimuove quell’accesso è la revoca, seguita da una sostituzione controllata per le applicazioni legittime. La verifica deve riguardare sistemi e credenziali propri o per cui si dispone dell’autorizzazione. Pulire il repository resta utile, ma non sostituisce la gestione dell’identità e la conferma che il vecchio segreto non autentichi più. [1][4]
GitHub controlla per impostazione predefinita la validità dei propri token negli avvisi. I controlli per i pattern dei partner hanno requisiti distinti di piano, GitHub Secret Protection e configurazione. Anche i metadati vanno separati: quelli dei token GitHub attivi sono in public preview e possono mostrare proprietario e ultimo utilizzo; i token pubblici vengono revocati automaticamente, quindi questi dati spesso non restano disponibili. Gli extended metadata dei partner sono un’altra preview, limitata a OpenAI API, Google OAuth, Slack e Replicate, con informazioni variabili per tipo di token. [2]
Consideriamo un caso illustrativo: un bot di CI/CD viene configurato erroneamente e un token di accesso viene committato in un repository pubblico. La risposta difensiva corretta non deve iniziare dalla pulizia del codice, ma dalla gestione dell'identità. Il proprietario del sistema deve prima revocare immediatamente il token presso il provider per chiudere l'accesso, indipendentemente dal fatto che l'alert di GitHub sia arrivato o meno. Solo dopo la revoca è possibile procedere alla rotazione della chiave e alla distribuzione di un nuovo segreto in un ambiente sicuro. [1][4]
Per prevenire tali eventi, è consigliabile adottare credenziali a breve termine (short-lived) o identità di workload, che scadono automaticamente riducendo la finestra di esposizione. Sebbene l'uso di file .env sia comune, l'importante non è l'uso del file in sé, ma l'assicurazione che non venga mai committato e che i segreti siano gestiti tramite sistemi di vaulting. Affidarsi esclusivamente ai blocchi al momento del push è rischioso, poiché non copre i pattern generici e non protegge i commit effettuati prima dell'attivazione della protezione. [1][4]
Anthropic apre le scansioni gratuite ai progetti open source idonei. I report arrivano senza verifica umana preventiva: ecco come aderire, preparare il codice e valutare le segnalazioni.
Analisi della risposta di Chrome ai dirottamenti dei ccTLD .gh, .sl e .as del 6 ottobre 2026, con focus su CRLSets, Certificate Transparency e l'uso di record CAA per prevenire l'emissione di certificati HTTPS non autorizzati.
Come creare una passkey Google, accedere dal telefono o dal computer e preparare il recupero. Requisiti, differenze fra i gestori e controlli da fare prima di perdere un dispositivo.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.