Come aggiungere sicurezza al tuo workflow di codifica AI (senza rallentarlo)

Come si protegge un workflow di codifica AI?

Lo proteggi controllando cosa l'agente scrive e fa, nel loop, anziché ispezionare solo il diff a posteriori. La pull request era la casa dell'AppSec perché un essere umano rallentava per leggerla. Un agente AI non gira al ritmo umano, quindi un controllo che agisce solo alla PR sta rivedendo la storia, non prevenendola. La soluzione è aggiungere controlli a ciascun punto in cui il rischio entra: quando l'agente scrive, quando agisce, quando il codice viene scansionato e quando viene mergiato.

Pensalo come quattro punti di controllo lungo il percorso che una modifica compie, dal prompt alla produzione. I primi prevengono; gli ultimi colgono. Li vuoi tutti e quattro, ma la leva è concentrata all'inizio: una vulnerabilità mai scritta non ha bisogno di smistamento, né di correzione, né di revisione.

Momento del prompt: regole nell'agenteMomento dell'azione: guardia sulle chiamate pericoloseMomento della scansione: finding di nuovo all'agenteMomento della PR: gate SAST + autofix

Passo 1: Metti le tue regole nell'agente (momento del prompt)

Il controllo a più alta leva è quello che la maggior parte dei team non ha: le tue regole nelle mani dell'agente prima che scriva. Un modello non può seguire uno standard che non vede mai, quindi carica i tuoi requisiti di sicurezza (parametrizza le query, vincola ogni lookup al chiamante, non mettere mai un segreto inline) e le tue convenzioni di business (il denaro usa Decimal, le scritture passano per requireOwner, le query sono vincolate al tenant) nel contesto dell'agente per ogni modifica. Il pattern sicuro diventa il default a cui punta, non un ripensamento che uno scanner segnala dopo.

È questo che trasforma "l'agente scrive l'endpoint medio di internet" in "l'agente scrive il tuo endpoint". È anche il controllo più economico da gestire, perché non produce nulla da smistare. Il modello più profondo è in sicurezza degli agenti di codice AI; il punto pratico è che questa singola mossa rimuove intere classi di finding prima che esistano.

Passo 2: Metti una guardia sulle azioni pericolose (momento dell'azione)

Gli agenti AI non si limitano a scrivere, agiscono: eseguono comandi shell, leggono file, chiamano strumenti via MCP. Quindi il secondo punto di controllo sta sulle azioni, non sul codice. Una guardia intercetta la chiamata pericolosa, un sudo rm -rf, una lettura grezza di una variabile d'ambiente a forma di segreto, uno psql improvvisato contro un host che sembra di produzione, prima che parta, e blocca o avvisa secondo regola con ogni intercettazione registrata.

Questo conta soprattutto quando l'agente può essere pilotato. La prompt injection (istruzioni nascoste in un file, una pagina web o una risposta di uno strumento MCP) trasforma un agente utile in uno che agisce secondo l'intento di un attaccante, e l'unica cosa tra un'istruzione iniettata e un comando distruttivo è un controllo che osserva l'azione stessa. Tieni spente le modalità auto-run in qualsiasi ambiente con dati reali, e lascia che la guardia sia la rete di sicurezza.

Passo 3: Esegui scansioni in continuo e riporta i finding all'agente (momento della scansione)

Continua a scansionare, ma cambia cosa fai con i risultati. Esegui SAST consapevole della reachability, più scansione di SCA, segreti, licenze, IaC, container e CI/CD, in continuo a ogni push, così che i nuovi finding emergano mentre l'agente spedisce. Poi chiudi il loop: rimetti quei finding confermati e classificati nel contesto dell'agente così che corregga quelli reali nella stessa sessione in cui sta già codificando. La scansione trova; l'agente corregge; tu approvi. Trattiamo questo loop in AI vulnerability remediation.

Il motivo per filtrare prima per reachability è il volume. Un agente che genera migliaia di righe al giorno genera finding allo stesso ritmo, e uno scanner che solleva 1.200 problemi di cui 12 sono sfruttabili abitua tutti a ignorare tutti e 1.200. Lavorare dall'insieme raggiungibile è ciò che mantiene l'arretrato gestibile, il tema di perché la maggior parte dei finding SAST è rumore.

Passo 4: Metti un gate sulla pull request e svuota l'arretrato (momento della PR)

Mantieni i controlli che hai già, sono la rete di protezione. Un gate SAST che fa fallire la build sui finding raggiungibili ad alta severità, più la revisione umana con scrutinio extra su autenticazione, query e autorizzazione, coglie ciò che i passi precedenti hanno mancato. Aggiungi l'autofix così che l'agente svuoti l'arretrato esistente anziché lasciarlo crescere: puntalo su un livello di severità e lascia che apra correzioni che approvi.

L'errore è fare della PR l'unico controllo, perché al ritmo dell'AI nessuno legge da cima a fondo migliaia di righe generate. Il gate della PR è necessario e insufficiente; funziona perché i primi tre passi hanno già assottigliato ciò che lo raggiunge.

Come appare il tutto, da cima a fondo

In pratica il tutto è un'unica sessione di sviluppo, non il rollout di un programma. Lo sviluppatore fa il prompt come al solito; le regole sono già nell'agente, quindi il codice esce più sicuro. La guardia sta sulle chiamate pericolose. La scansione gira in background e fa emergere ciò che è aperto. Lo sviluppatore chiede all'agente di correggere i critici raggiungibili e approva i diff, e il gate della PR conferma che nulla è sfuggito. La spiegazione dettagliata e cronometrata è come proteggere un'intera app in cinque minuti.

VibeDefend è il livello che installa i primi tre punti di controllo con un solo comando. Collega Claude Code, Cursor, Windsurf, OpenAI Codex e VS Code Copilot a quattro livelli di governance dentro il loop dell'agente, in circa cinque secondi, senza container, senza YAML e senza modifiche alla pipeline.

I quattro livelli mappano esattamente sui punti di controllo: Business Rules estratte dal tuo repo e Security Rules da OWASP, SOC 2, GDPR e ISO 27001 sono il controllo al momento del prompt; l'Action Guard è il controllo al momento dell'azione; e Live Findings collega l'agente agli scanner di CybeDefend così che i finding del momento della scansione tornino all'agente perché li corregga. Nulla del tuo codice attraversa la rete; solo metadati di governance strutturati, su regioni EU o US tenute fisicamente separate. Il tuo gate SAST in CI e la revisione restano dove sono, come rete di sicurezza.

Domande frequenti

Come si protegge un workflow di codifica AI?

Aggiungendo controlli ai quattro punti in cui il rischio entra, non solo alla pull request: momento del prompt (regole caricate nell'agente così che scriva per primo il pattern sicuro), momento dell'azione (una guardia che blocca comandi distruttivi e letture di segreti), momento della scansione (scansione consapevole della reachability riportata all'agente perché corregga) e momento della PR (un gate SAST più revisione umana e autofix). I primi due prevengono le vulnerabilità; gli ultimi due colgono ciò che sfugge. Concentrare i controlli all'inizio è ciò che mantiene tutto veloce.

Aggiungere sicurezza rallenta gli sviluppatori?

No, quando i controlli girano dentro il loop in cui gli sviluppatori sono già. Le regole nell'agente cambiano ciò che scrive senza passi extra; l'action guard interrompe solo le chiamate genuinamente pericolose; i finding tornano nella stessa sessione; e l'autofix rimuove lavoro anziché aggiungerlo. Ciò che rallenta i team è l'opposto, un arretrato di finding post-merge che nessuno ha tempo di smistare. Spostare il controllo prima riduce quel carico.

Qual è il controllo più importante da aggiungere per primo?

Le regole nell'agente al momento del prompt. È il controllo a più alta leva e più economico perché la vulnerabilità che previene non deve mai essere trovata, smistata, corretta o rivista. Un modello non può seguire uno standard che non vede mai, quindi caricare le tue regole di sicurezza e di business nel suo contesto per ogni modifica rimuove intere classi di finding prima che esistano. Tutto il resto è una rete di sicurezza dietro di esso.

Mi servono ancora SAST e scansione in CI se l'agente è governato?

Sì. Il SAST in CI e la scansione delle dipendenze restano come rete di sicurezza per tutto ciò che i controlli precedenti mancano e per il codice che gli esseri umani scrivono ancora a mano. Il cambiamento è che non sono più l'unico controllo, perché alla velocità dell'AI nessuno rivede da cima a fondo migliaia di righe generate. Governare al momento della generazione assottiglia ciò che raggiunge il gate, così il gate torna efficace anziché sommerso.

In cosa è diverso dall'usare semplicemente le funzioni di sicurezza integrate del mio agente AI?

Le funzioni integrate (sandbox, modalità di approvazione, esclusioni di contenuto) proteggono dove l'agente gira e cosa può toccare; dicono poco sulla sicurezza del codice che scrive o sulle tue specifiche regole di business. Questo playbook aggiunge il livello mancante: le tue regole nell'agente, una guardia sulle sue azioni e i finding dei tuoi scanner nelle sue mani. Usa entrambi, i controlli nativi dell'agente per il contenimento, e un livello agent-time per il codice stesso.

Con quali agenti funziona?

Lo stesso approccio si applica a Claude Code, Cursor, Windsurf, OpenAI Codex e VS Code Copilot, perché condividono una forma agentica: leggono, scrivono, eseguono e chiamano strumenti. Una sola installazione li collega tutti allo stesso loop governato, così il workflow è identico indipendentemente da quale agente un dato sviluppatore preferisca. Le specifiche per ciascun agente sono nelle nostre guide a Claude Code e Windsurf.