Perché rimuovere il file non basta
L'errore di ragionamento è naturale: ho scritto la password nel file di configurazione, me ne sono accorto, l'ho tolta. Sembra risolto. Ma Git non dimentica: ogni versione precedente del file è conservata nella cronologia, e chiunque abbia accesso al repository può tornare indietro e leggerla. Ripulire la versione attuale è come strappare l'ultima pagina di un diario di cui esistono tutte le fotocopie. Finché quella chiave è valida, il fatto che sia «tolta» dal presente non cambia nulla.
Cosa finisce nel codice senza accorgersene
| Cosa | Perché è grave |
|---|---|
| Chiavi di servizi a pagamento (AI, invio email, mappe) | Chi le ottiene le usa a vostre spese |
| Credenziali del database | Accesso diretto ai dati, saltando l'applicazione |
| Token di accesso a servizi cloud | Possono aprire l'intera infrastruttura |
| Password di account amministrativi | Accesso ai sistemi collegati |
| Chiavi di firma o di cifratura | Compromettono la fiducia dell'intero sistema |
La chiave di un servizio AI a consumo merita una menzione: se il repository è pubblico, viene trovata e sfruttata in poche ore, e il primo segnale è la fattura.
Trovarli e prevenirli
- 01
Scandagliate la cronologia
Esistono strumenti gratuiti che analizzano tutta la storia di un repository cercando ciò che assomiglia a chiavi e password. Lanciateli sul vostro: dicono cosa è stato esposto e quando.
- 02
Ruotate ciò che trovate
Per ogni segreto trovato, cambiatelo alla fonte. È il passo che conta: senza, aver trovato il segreto non riduce il rischio.
- 03
Tenete i segreti fuori dal codice
La prevenzione: i segreti stanno in variabili d'ambiente o in un gestore di segreti, mai nel codice. Nel codice ci va, al massimo, un file di esempio con valori finti.
- 04
Mettete una rete automatica
Uno strumento che, a ogni modifica, blocca l'invio se contiene qualcosa che sembra un segreto. È ciò che impedisce all'errore di ripetersi quando l'attenzione cala.