Secrets management: il segreto migliore è quello che non esiste

Secrets management è una di quelle discipline che quasi nessuno dichiara di trascurare e quasi tutti trascurano. La prova arriva dai numeri: secondo il report State of Secrets Sprawl 2026 di GitGuardian, nel solo 2025 sono finiti nei commit pubblici di GitHub 28,65 milioni di nuovi segreti scritti direttamente nel codice, il 34 per cento in più dell’anno precedente e il salto annuale più alto mai registrato. Il dato misura ciò che è visibile sui repository pubblici, quindi è per definizione la punta dell’iceberg, ma la direzione è inequivocabile: credenziali, chiavi API, token e password continuano a moltiplicarsi più in fretta di quanto le organizzazioni riescano a governarle.

Il riflesso comune, davanti a questo problema, è cercare una cassaforte migliore. È l’istinto sbagliato. La gestione dei segreti non si risolve custodendo meglio una quantità crescente di credenziali, ma riducendone il numero e la durata, fino al punto in cui la chiave più sicura diventa quella che non esiste. È un capovolgimento di prospettiva che cambia tutto: l’obiettivo non è proteggere il segreto, è farne a meno il più possibile.

La proliferazione è il problema, non la custodia

Il primo malinteso da smontare è che il rischio stia nella conservazione. Il rischio sta nella proliferazione incontrollata, ciò che in inglese si chiama secret sprawl. I segreti si annidano ovunque: nel codice sorgente, nei file di configurazione, nelle variabili d’ambiente, nei messaggi di chat, nei ticket, nelle immagini dei container. Lo stesso report GitGuardian rileva che, nei perimetri analizzati, i repository interni risultano circa sei volte più esposti di quelli pubblici, perché lì la guardia si abbassa nella convinzione, falsa, che il perimetro basti a proteggere.

Il problema si aggrava per una ragione tanto banale quanto trascurata: i segreti non scadono quasi mai. GitGuardian riporta che, nel campione analizzato, il 64 per cento delle credenziali risultate valide nel 2022 era ancora attivo nel 2026, non revocato a distanza di anni, e attribuisce la cosa alla debolezza dei processi, all’assenza di una procedura ripetibile per revocare o ruotare un segreto dopo una fuga. Una credenziale messa nel posto sbagliato e mai disattivata resta una porta aperta a tempo indeterminato. La scrittura di credenziali direttamente nel codice, catalogata da MITRE come debolezza CWE-798, è nota da decenni e segnalata come grave da ogni analizzatore statico, eppure resta tra le scoperte più frequenti in qualunque verifica di sicurezza. Non è un problema di conoscenza, è un problema di disciplina.

Togliere i segreti dal codice

Il primo movimento, prima ancora di qualunque strumento sofisticato, è separare nettamente i segreti dal codice. La regola dell’OWASP è categorica: un segreto non va mai messo nel sorgente, nemmeno in un repository privato, perché il codice viene condiviso, clonato, biforcato e copiato in modi che aggirano i controlli di accesso. Vale lo stesso per i log e per le immagini dei container, dove le credenziali finiscono per inerzia e restano leggibili. Nemmeno le variabili d’ambiente sono una scorciatoia sempre sicura: in ambienti containerizzati possono essere esposte tramite configurazioni, dump o log, e andrebbero perciò popolate dall’orchestratore o dal gestore dei segreti, non scritte nell’immagine.

Tradurre questa regola in pratica significa due cose concrete. La prima è la prevenzione all’origine: analisi del codice e secret scanning integrati nella pipeline, controlli prima del commit e in fase di push che impediscano fisicamente a una credenziale di entrare nel repository. È il terreno naturale di una cultura di secure coding che sposta il controllo a sinistra, dove correggere costa meno. La seconda è la centralizzazione: tutti i segreti in un gestore dedicato, non sparsi per decine di sistemi. Un secret manager, che si tratti di HashiCorp Vault o dei servizi gestiti dai provider cloud, concentra in un solo punto le tre cose che altrimenti mancano: registro degli accessi, controllo dei permessi e rotazione.

Secrets management come disciplina: vault, rotazione, segreti dinamici

Centralizzare è la condizione, non il traguardo. La vera maturità del secrets management sta in come quei segreti vivono nel tempo. Un segreto statico, per quanto ben custodito, è una bomba a orologeria: prima o poi trapela, e il danno è proporzionale a quanto a lungo resta valido. Per questo la disciplina si misura sulla rotazione e sulla durata.

La direzione indicata dalle best practice OWASP è ridurre al minimo la vita utile del segreto: farlo esistere solo per il tempo necessario, renderlo revocabile e, dove possibile, generarlo dinamicamente. Tradotto, significa privilegiare i segreti dinamici, creati su richiesta al momento dell’uso e revocati automaticamente subito dopo, invece delle credenziali permanenti che qualcuno crea una volta e dimentica per sempre. Dove i segreti dinamici non sono praticabili, la seconda scelta migliore è un ciclo di rotazione breve e automatico, perché la rotazione manuale è quella che non si fa mai. Il punto non è cambiare le chiavi per rituale, ma ridurre la finestra in cui una chiave compromessa è ancora utile a un attaccante.

Quando un segreto trapela

La rotazione regolare è prevenzione; la risposta a una fuga è un’altra disciplina, e va preparata prima che serva. OWASP le dedica una parte specifica, e il principio è la rapidità: una credenziale esposta va revocata e ruotata subito, non a fine sprint. Servono però anche le informazioni per misurare il danno: chi aveva accesso a quel segreto, quando è stato usato l’ultima volta e da dove, se era già stato ruotato. È esattamente ciò che un gestore centralizzato dei segreti permette di ricostruire e che le credenziali sparse rendono impossibile. E la ricerca va estesa alla cronologia del repository, non solo all’ultima versione, perché un segreto revocato di recente può restare vivo e sfruttabile in un commit passato.

Il sidecar e i segreti che si rinfrescano da soli

In un ambiente a container, un modello ricorrente rende concreta questa logica. Un container collaterale, il sidecar, si occupa di autenticarsi al gestore dei segreti, recuperare la credenziale e scriverla in un volume condiviso in memoria, da cui l’applicazione la legge. Il sidecar la aggiorna periodicamente, così l’applicazione dispone sempre di una credenziale valida e di breve durata, senza che lo sviluppatore debba gestirla nel codice. È un esempio di come la vita ridotta al minimo non sia un’astrazione, ma un’architettura: il segreto esiste solo per il tempo necessario, e l’applicazione non lo possiede, lo riceve.

L’obiettivo finale: il segreto che non esiste

Il passo più avanzato è eliminare del tutto il segreto di lunga durata. È possibile, e in molti scenari è già la pratica raccomandata. Nei flussi di integrazione e distribuzione continua, il caso storicamente più sanguinoso, la chiave di servizio salvata nella pipeline è stata per anni una delle credenziali più rubate. La risposta è l’autenticazione federata basata su OIDC: invece di conservare una chiave permanente, la pipeline presenta un’identità verificabile e riceve credenziali temporanee che il provider cloud emette al volo e che scadono nel giro di un’ora. Non c’è alcun file da scaricare, nessun segreto da ruotare, nessuna credenziale che si possa dimenticare in un repository, perché non esiste una credenziale persistente da rubare. L’accesso si può inoltre restringere a un singolo repository o a un singolo ramo, riducendo ulteriormente la superficie.

È la dimostrazione pratica del principio: il modo più sicuro di gestire un segreto è non averne uno. Ogni credenziale di lunga durata che si riesce a sostituire con un’identità federata e un token effimero è un problema di secrets management che semplicemente smette di esistere.

Perché conta adesso

Due dinamiche recenti rendono il tema più urgente di quanto i numeri da soli suggeriscano. La prima è che i segreti sono il bottino preferito degli attacchi alla catena di fornitura del software. Il worm nei pacchetti npm che ha colpito un namespace di Red Hat, come altre campagne simili, aveva un obiettivo dichiarato: raccogliere credenziali, token e identità cloud dagli ambienti degli sviluppatori. In un ecosistema dove un solo segreto rubato apre l’accesso a interi sistemi, la quantità di credenziali in circolazione non è un dettaglio igienico, è la dimensione della superficie d’attacco.

La seconda dinamica è l’intelligenza artificiale generativa applicata allo sviluppo. GitGuardian rileva che le fughe legate ai servizi AI sono cresciute dell’81 per cento in un anno, e che nei commit co-firmati da Claude Code il tasso di esposizione dei segreti è circa il doppio rispetto alla media dei commit pubblici di GitHub. Gli assistenti di programmazione, attingendo anche ai repository interni, rischiano di portare alla luce credenziali che si credevano protette dall’oscurità. È un acceleratore del problema che si somma alla proliferazione delle identità non umane, ciascuna con i propri segreti da gestire.

Il secrets management, in conclusione, non è la ricerca di una cassaforte più robusta per un numero sempre maggiore di chiavi. È il lavoro opposto: ridurre quelle chiavi, accorciarne la vita, e sostituirle dove possibile con identità che non lasciano nulla da rubare. Le organizzazioni che escono meglio da questo decennio non saranno quelle che custodiscono più segreti, ma quelle che hanno imparato ad averne di meno. Perché, alla fine, il segreto più sicuro resta quello che non esiste.