Esiste una domanda che quasi nessun team di engineering si è posto seriamente prima di adottare un code assistant basato su AI: questo strumento sta introducendo vulnerabilità nel mio codebase? Non per dolo, non per bug classificabili — ma perché il modello sta facendo esattamente ciò per cui è stato addestrato: completare pattern. E i pattern, a volte, includono API key, token OAuth, credenziali database e certificati privati.
La risposta breve alla domanda "does AI code generation leak API keys and secrets?" è sì — e in modo sistematico, misurabile, e in accelerazione. I dati che seguono non provengono da threat model teorici. Provengono da analisi di repository reali, commit reali, e incidenti documentati.
Key Points
- I commit generati con assistenza AI leakano credenziali al tasso del 3,2% — 2,4 volte il baseline degli sviluppatori umani, secondo Veracode Spring 2026.
- Ad agosto 2025, il picco: 31 segreti esposti ogni 1.000 commit AI-assisted. Il trend non si è invertito.
- Marzo 2026: 35 CVE direttamente attribuibili a codice AI-generated, contro 15 di febbraio e 6 di gennaio. La curva è esponenziale.
- Il problema principale non è il codice malevolo — è come gli LLM gestiscono le credenziali nel contesto: le includono perché "completano il pattern".
The Numbers Don't Lie: AI Code Assistants Are Leaking Secrets
Nel Spring 2026 GenAI Code Security Update pubblicato da Veracode, i ricercatori hanno analizzato decine di migliaia di repository che hanno adottato code assistant AI negli ultimi diciotto mesi. Il risultato è netto: i commit prodotti con assistenza AI mostrano un tasso di secret leakage del 3,2%. Il baseline per i commit puramente umani si attesta all'1,3%. La differenza — 2,4 volte — non è trascurabile. È una firma statistica robusta.
La tipologia di segreti esposti riflette l'architettura moderna delle applicazioni: API key per servizi cloud (AWS, GCP, Azure), token di accesso per piattaforme SaaS, credenziali database in stringa di connessione, chiavi private SSH e certificati TLS hardcoded in variabili di configurazione. In molti casi, la vulnerabilità non emerge in un file di configurazione separato — emerge direttamente nell'application code, dove è strutturalmente più difficile da rilevare con scanner automatici calibrati su pattern convenzionali.
Il picco documentato risale ad agosto 2025: 31 segreti esposti ogni 1.000 commit AI-assisted. Per un team di dieci sviluppatori che producono in media tre commit al giorno a testa, questo si traduce in potenzialmente 27 secret leak al mese, ognuno dei quali può rimanere attivo in codebase privati — o pubblici — per settimane prima di essere individuato.
Why LLMs Leak: The Pattern Completion Problem
Capire il meccanismo è fondamentale per non ridurre il problema a un difetto implementativo correggibile con una patch. I Large Language Model utilizzati nei code assistant non "sanno" che una stringa è una credenziale nel senso in cui lo sa un ingegnere di sicurezza. Il modello sa che quella stringa appare tipicamente in un certo contesto, con una certa sintassi, in una certa posizione nel codice. Quando viene chiesto di completare una funzione di autenticazione, di configurare un client SDK, di generare un esempio di integrazione con un'API esterna — il modello completa il pattern. E il pattern include la credenziale.
Il problema si amplifica in uno scenario specifico che Veracode identifica come particolarmente critico: il refactoring assistito da AI. Quando uno sviluppatore chiede a un code assistant di ristrutturare codice esistente che già contiene credenziali hardcoded — una pratica comune nelle codebase legacy — il modello non le elimina. Le propaga. Le porta nel nuovo contesto, le include nei nuovi file, le normalizza ulteriormente nell'architettura del progetto. Il debito di sicurezza non viene ridotto. Viene distribuito.
THE DATA
3,2% di secret leakage rate nei commit AI-assisted. 2,4x il baseline umano. 31 segreti esposti ogni 1.000 commit al picco di agosto 2025. 35 CVE attribuibili a codice AI-generated in marzo 2026, contro 6 di gennaio: una curva che non accenna a rallentare.
The CVE Acceleration: March 2026 as an Inflection Point
Marzo 2026 segna un'accelerazione nella curva dei CVE direttamente attribuibili a codice AI-generated. Sei vulnerabilità documentate a gennaio. Quindici a febbraio. Trentacinque a marzo. Non si tratta di una coincidenza stagionale né di un artefatto metodologico: è la conseguenza di tre fattori che si sommano.
Primo, l'adozione degli AI code assistant è cresciuta esponenzialmente negli ultimi dodici mesi, con la maggior parte delle enterprise che li ha introdotti senza aggiornare le proprie pratiche di security review. Secondo, il codice scritto sei-dodici mesi fa con assistenza AI sta ora raggiungendo fasi di deployment più ampie — dove le vulnerabilità diventano visibili. Terzo, la comunità di security research ha solo recentemente sviluppato metodologie robuste per attribuire una vulnerabilità specifica alla fase di generazione AI, separandola dall'errore umano nel review process.
Infosecurity Magazine documenta che la tipologia di vulnerabilità più comune nei CVE attribuiti a codice AI non riguarda solo il secret leakage: include SQL injection generate da prompt mal formulati, race condition introdotte da pattern di concorrenza non idiomatici, e validazione di input assente nei boilerplate generati per funzioni di autenticazione. Il secret leakage è il problema più facilmente misurabile — non necessariamente il più pericoloso.
How to Use AI Code Generation Safely: Practical Recommendations
Il problema è reale e in crescita. Non è però un argomento per non usare i code assistant — è un argomento per usarli con una disciplina di sicurezza che la maggior parte dei team non ha ancora messo in atto.
La prima misura è strutturale: mai passare credenziali reali nel contesto di un code assistant. Le credenziali vanno sostituite con placeholder espliciti prima di qualsiasi interazione con il modello.
La seconda è tooling: integrare secret scanning nel pipeline CI/CD come gate obbligatorio, non come controllo opzionale post-merge. Il punto critico è la posizione nel pipeline: il controllo deve avvenire prima del merge, non dopo il deployment.
La terza è review policy: qualsiasi codice che gestisce autenticazione, accesso a risorse esterne, o configurazione di ambienti richiede un security review separato dal code review funzionale.
La quarta è formazione: i developer che usano AI code assistant devono essere esplicitamente informati che il modello non ha un concetto nativo di "questa stringa è una credenziale e non va inclusa nel codice". La maggior parte dei developer assume che il modello abbia un layer di safety che filtra automaticamente i segreti. Non è così.
What I Think
Il problema del secret leakage nei code assistant AI è, strutturalmente, un problema di aspettativa mal calibrata. Le aziende hanno adottato questi strumenti con la narrativa della produttività senza interrogarsi seriamente su quale tipo di rischio fosse specifico del processo di generazione AI, distinto dal rischio del codice in generale.
La curva dei CVE di marzo 2026 non è un avvertimento del futuro. È il conto del passato che arriva a scadenza. La velocità dell'adozione ha preceduto la velocità della comprensione del rischio. Succede sempre, con ogni tecnologia trasformativa. La differenza con l'AI code generation è che il codice errato non resta nel cassetto: va in produzione, espone credenziali, viene clonato in altri progetti, genera nuovi pattern che altri modelli impareranno a replicare. L'errore si moltiplica geometricamente.
"Il modello completa i pattern. Non capisce i segreti. Quella distinzione è l'intera differenza tra uno strumento che accelera lo sviluppo e uno che sistematicamente mina la sicurezza di ogni codebase che tocca."
Stefano Moretti