Chiavi API esposte: cancellare il file non chiude l’incidente

La chiave può essere ancora valida

Una chiave API compare in un repository pubblico. Lo sviluppatore se ne accorge, elimina la riga dal file e pubblica una correzione. Il software continua a funzionare e il problema sembra risolto. Eppure quella credenziale potrebbe essere ancora valida, presente nella cronologia o già copiata da altri. La sicurezza richiede di seguire il segreto fino al sistema che lo accetta, verificando che non permetta più l’accesso.

Il 4 novembre 2026 Truffle Security ha annunciato il Secrets Revocation Program, un’iniziativa rivolta alle organizzazioni che emettono credenziali. Secondo l’azienda, il programma parte da circa 1,4 milioni di credenziali esposte e ancora funzionanti individuate attraverso le proprie ricerche. Si tratta di un dato dichiarato dal fornitore, non di un censimento indipendente di tutte le chiavi compromesse su Internet. [1]

BleepingComputer ha ripreso l’annuncio il 5 novembre. L’elemento di interesse aziendale è il passaggio dalla segnalazione dell’esposizione alla disattivazione delle credenziali attraverso gli emittenti. L’annuncio, da solo, non dimostra che una specifica impresa sia coinvolta né che ogni chiave individuata sia stata utilizzata da un attaccante. La nostra analisi riguarda quindi il processo di risposta che un’organizzazione dovrebbe saper attivare. [3]

Dalla rimozione alla revoca

La documentazione ufficiale GitHub indica come primo passo, quando il dato esposto è un segreto, la sua revoca o rotazione. Spiega inoltre che riscrivere la cronologia richiede coordinamento e può produrre conseguenze sulle copie del repository e sul lavoro dei collaboratori. La rimozione del contenuto e l’invalidazione della credenziale sono attività collegate, con risultati differenti da verificare. [2]

Per rendere operativa questa indicazione, proponiamo di partire dall’identità tecnica della chiave. A quale servizio appartiene? Quali autorizzazioni possiede? Chi la utilizza? Chi può revocarla? Una credenziale apparentemente secondaria potrebbe alimentare un’integrazione importante. Senza un proprietario identificato, la risposta rischia di oscillare tra due estremi: lasciare aperto l’accesso per timore di interrompere il servizio oppure disattivarlo senza conoscere le dipendenze.

Consideriamo uno scenario ipotetico: un’applicazione utilizza una chiave per inviare notifiche ai clienti. La stessa chiave è stata copiata in un ambiente di test e in uno script di manutenzione. Sostituirla soltanto nell’applicazione principale lascia due dipendenze da gestire. Il piano di intervento dovrebbe ricostruire questi utilizzi, distribuire la nuova credenziale attraverso un canale controllato e verificare la disattivazione della precedente.

Continuità e ricostruzione degli utilizzi

La sequenza concreta dipende dal rischio. In presenza di un’esposizione credibile e di privilegi elevati può essere necessario bloccare subito la credenziale, gestendo l’interruzione conseguente. In altri casi è possibile coordinare una sostituzione rapida prima della revoca. La scelta deve avere un responsabile, una motivazione e tempi definiti. La continuità operativa non dovrebbe trasformarsi in una proroga indefinita dell’accesso esposto.

Occorre poi ricostruire gli utilizzi disponibili nei registri del servizio: operazioni effettuate, orari, provenienze e variazioni dei consumi. La presenza pubblica di una chiave non dimostra automaticamente un abuso; l’assenza di anomalie nei log disponibili non dimostra che nessuno l’abbia copiata. Nel rapporto di chiusura conviene distinguere esposizione accertata, attività sospette e aspetti che non è stato possibile verificare.

Anche la gestione del ticket merita attenzione. Incollare il segreto completo nella descrizione dell’incidente può moltiplicarne la diffusione. Sono preferibili riferimenti mascherati, identificativi del servizio e collegamenti a evidenze custodite con accessi appropriati. Il gruppo di risposta deve poter lavorare senza trasformare chat, email e allegati in nuove copie della credenziale.

Prevenire le nuove esposizioni

La prevenzione richiede infine un percorso semplice per chi sviluppa e mantiene i sistemi: modalità approvate per distribuire i segreti, controlli prima della pubblicazione e responsabilità chiare sulle integrazioni. L’obiettivo proposto è misurabile: sapere quanto tempo passa dalla segnalazione alla revoca verificata e quante esposizioni si ripetono per la stessa causa. Un incidente può dirsi trattato quando l’accesso precedente è chiuso, i servizi sono controllati e le evidenze spiegano cosa è stato fatto.