Dal prompt alla pull request: threat modeling per codice scritto da agenti AI

Un coding agent può trasformare una issue in una pull request credibile: legge il repository, propone un piano, modifica file, aggiorna test e prepara un diff pronto per la review. Il rischio concreto è che il team valuti solo se la feature funziona, senza chiedersi se il prompt iniziale descriveva davvero dati, ruoli, possibili abusi, trust boundary e impatto in produzione.

Il threat modeling serve proprio in questo passaggio: non come esercizio burocratico, ma come metodo leggero per capire cosa sta cambiando, cosa può andare storto, quali controlli servono e se la verifica fatta è sufficiente prima di merge, deploy o go-live.

Per CTO, tech lead e security champion, la domanda non è “possiamo usare agenti AI per scrivere codice?”. La domanda utile è: come trasformiamo prompt, piano dell’agente e pull request in una decisione di rischio tracciabile?

Perché il threat modeling cambia con il codice scritto da agenti AI

Nel threat modeling applicativo tradizionale si parte da feature, asset, attori, data flow e trust boundary. Con il codice scritto da agenti AI bisogna aggiungere un livello: il percorso che porta dal prompt al diff.

Una richiesta come “aggiungi inviti al team” può generare modello dati, API, email, token temporanei, ruoli, pagine admin, test, variabili ambiente e una migration. Ogni pezzo introduce minacce diverse: inviti riutilizzabili, token troppo lunghi nei log, ruoli applicati solo nel frontend, endpoint non protetti, tenant isolation incompleta, email spoofing, dipendenze aggiunte senza review. Il prompt raramente contiene tutto questo, perché l’agente riempie i vuoti con convenzioni plausibili. Il threat modeling serve a rendere espliciti quei vuoti prima che diventino codice accettato.

Le quattro domande da applicare a ogni PR AI-generated

OWASP riassume il threat modeling in quattro domande: cosa stiamo costruendo, cosa può andare storto, cosa faremo per gestirlo e se abbiamo fatto abbastanza. Nel contesto AI coding, queste domande vanno applicate a prompt, piano, diff e runtime.

Domanda	Nel workflow con agenti AI significa
Cosa stiamo costruendo?	Quale task ha ricevuto l’agente, quali file ha modificato, quali dati e sistemi tocca
Cosa può andare storto?	Quali abusi diventano possibili su ruoli, dati, API, tool, pipeline e superfici esposte
Cosa facciamo?	Quali controlli entrano in codice, test, configurazione, review, pipeline o processo
Abbiamo fatto abbastanza?	Quali evidenze bloccano il merge, quali rischi sono accettati e chi li governa

Questa struttura evita due errori frequenti: trattare il threat modeling come una riunione astratta oppure ridurlo a una checklist generica di vulnerabilità.

Partire da asset, dati e attori reali

Il primo passo non è leggere il diff riga per riga, ma capire quali asset entrano nel perimetro della modifica: dati personali, documenti cliente, pagamenti, ruoli amministrativi, token, API interne, webhook, repository, pipeline, log, storage, database e servizi cloud.

Poi servono gli attori. Non basta distinguere “utente” e “admin”: in una feature reale possono esistere utente invitato, utente sospeso, owner, admin parziale, account di servizio, integrazione esterna, membro di un altro tenant, cliente disattivato, support operator, job schedulato e attaccante anonimo. Una matrice minima attore-azione-risorsa aiuta molto più di una review generica. Per ogni ruolo bisogna chiedersi: quali risorse può leggere, creare, modificare, cancellare o esportare? Il backend lo verifica davvero, o l’agente ha implementato il controllo solo nell’interfaccia?

Disegnare il data flow, anche in modo leggero

Il threat model non deve per forza produrre un diagramma perfetto, ma deve rendere visibili data flow, data store, processi, entità esterne e trust boundary. Se una PR attraversa frontend, API route, database, object storage, provider email, webhook e pipeline di deploy, il rischio non è nello stesso punto per tutti i componenti.

Con il codice generato da AI, il data flow deve includere anche elementi spesso dimenticati: prompt dell’agente, cronologia chat, output dei tool, log di build, variabili ambiente, secret manager, test fixture, seed, snapshot e artefatti di deploy. Un segreto copiato nel prompt o in un log non compare sempre nel diff finale, ma può comunque richiedere rotazione.

Il confine più importante è dove un input non fidato entra in un componente fidato. Un valore proveniente da form, ticket, documento, webhook, file caricato, output LLM o tool esterno deve essere validato prima di diventare query, comando, autorizzazione, email, decisione o azione downstream.

Scrivere abuse case, non solo user story

Le user story descrivono l’uso previsto; gli abuse case descrivono cosa può fare un utente, un tenant, un’integrazione o un contenuto malevolo quando il sistema è usato fuori sequenza. Alcuni esempi utili per una PR generata da AI:

Un utente cambia l’ID nell’URL e legge un record di un altro tenant.
Un invito scaduto viene riutilizzato per ottenere accesso.
Un webhook viene ripetuto o firmato con una chiave sbagliata.
Un ruolo read-only chiama direttamente l’API di modifica.
Un file caricato contiene payload che finisce in HTML, parser o storage.
Un prompt injection in un ticket induce l’agente a modificare una policy o usare un tool.
Una migration espone dati di test o campi sensibili in produzione.

STRIDE resta utile come stimolo — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — ma nel codice AI-generated va collegato a casi concreti, non usato come acronimo decorativo.

Valutare il piano dell’agente prima del diff

Molti team iniziano la review quando la pull request è pronta. Con agenti AI conviene anticipare: se l’agente propone un piano che tocca auth, ruoli, dati, cloud, CI/CD, segreti o dipendenze, il threat model deve partire prima che il diff diventi grande.

Il piano dell’agente va letto con domande precise: sta creando nuovi endpoint o esponendo route prima inesistenti? Sta cambiando middleware, policy, permission check o ruoli? Sta aggiungendo dipendenze, script, workflow o comandi di deploy? Sta modificando test in modo da confermare la propria implementazione? Sta assumendo che un controllo lato client basti? Sta usando dati reali, log o segreti per completare il task? Se la risposta è sì anche a una sola di queste domande, la PR va spezzata o marcata come ad alto rischio, perché una review efficace non può trattare allo stesso modo una correzione di copy e una modifica che attraversa autorizzazioni, database e pipeline.

Collegare minacce, controlli e test

Un threat model utile produce controlli verificabili. Se la minaccia è “utente di tenant A legge dati di tenant B”, il controllo non è “gestire autorizzazioni”: è una policy server-side, una query filtrata per tenant, test con due tenant distinti, log dell’accesso negato e review del middleware.

Se la minaccia è “token di invito riutilizzabile”, i controlli possono includere scadenza, single use, binding a email o tenant, hashing del token a riposo, rate limit e audit log. Se la minaccia è “prompt injection tramite ticket”, i controlli sono separazione tra dati e istruzioni, conferma umana per tool sensibili, allowlist di azioni e test con contenuti ostili.

Scanner e test automatici aiutano, ma non dimostrano da soli che business logic, tenant isolation, autorizzazioni e trust boundary siano corretti nel contesto reale.

Definire cosa blocca merge e go-live

Il threat modeling non deve concludersi con “abbiamo parlato dei rischi”: deve produrre decisioni. Bloccano merge o go-live le evidenze che espongono dati, permettono escalation di privilegi, aggirano autorizzazioni, rivelano segreti, rendono pubblici storage o database, indeboliscono pipeline, disabilitano controlli di sicurezza o introducono dipendenze critiche non valutate.

Altri punti possono diventare remediation pianificata, ma solo con owner, data e rischio residuo chiari. Migliorare logging, aggiungere alert, rafforzare la documentazione o rendere più granulare la matrice dei ruoli può essere pianificato; accettare un access control incerto prima del go-live no.

Checklist threat modeling per PR generate da AI

Identifica prompt/task originale, agente o tool usato e parti generate o modificate.
Elenca asset, dati reali, ruoli, tenant, sistemi esterni e segreti toccati.
Disegna un data flow minimale con trust boundary, processi, data store ed entità esterne.
Scrivi abuse case specifici della feature, non solo vulnerabilità generiche.
Verifica autorizzazioni object-level e tenant isolation con utenti diversi.
Controlla se la PR modifica middleware, policy, ruoli, callback, redirect, CORS o sessioni.
Separa review del codice, review della pipeline, review delle dipendenze e review dei test.
Cerca segreti in prompt, log, repository, build, workflow e configurazioni.
Pretendi test negativi derivati dalle minacce, non solo test sul percorso felice.
Documenta cosa blocca il merge, cosa blocca il go-live e cosa resta come rischio accettato.

Come integrare il metodo nel ciclo di sviluppo

Il threat modeling per AI coding deve essere leggero e ripetibile. Non serve una sessione lunga per ogni commit, ma servono soglie chiare: una PR che tocca copy o layout può seguire il flusso normale, mentre una PR che tocca auth, dati, API, pagamenti, cloud, CI/CD, segreti, ruoli o tool agentici deve attivare un controllo più rigoroso.

Nel processo pratico, il task dovrebbe includere vincoli di sicurezza; il piano dell’agente dovrebbe essere approvato quando tocca aree sensibili; la PR dovrebbe essere piccola; i test dovrebbero coprire abuse case; la review dovrebbe avere owner tecnici; la decisione finale dovrebbe lasciare traccia. Quando l’uso di agenti AI diventa continuativo, questo diventa tema di Software Assurance Lifecycle: regole di sviluppo, branch protection, gate di sicurezza, ownership, evidenze, remediation e controlli ricorrenti.

Quando coinvolgere una verifica indipendente

Una verifica interna può bastare per modifiche isolate, senza dati reali, senza ruoli, senza API esposte e con reviewer esperti. Serve invece una verifica indipendente quando il codice generato o modificato da AI entra in un prodotto usato da clienti, dipendenti o partner, oppure quando la PR tocca autorizzazioni, dati, pipeline, cloud, pagamenti, segreti o logica critica.

Scenario	Rischio principale	Controllo consigliato
PR AI-generated su auth, ruoli, API, query, segreti o dipendenze	Vulnerabilità o regressioni nel codice	Code Review
Adozione continuativa di coding agent nel ciclo engineering	Controlli non ripetibili su task, PR e release	Software Assurance Lifecycle
Decisione su go-live, rischio residuo, impatti business o compliance	Rischio non prioritizzato o accettato senza owner	Risk Assessment
Architettura, flussi dati, trust boundary e integrazioni complesse	Assunzioni di design deboli	Secure Architecture Review
App o API già esposte a utenti e clienti	Comportamento abusabile dall’esterno	Web Application Penetration Testing

La scelta non deve essere un pacchetto standard. Se il rischio è nel diff, serve Code Review. Se il rischio è nel processo di adozione degli agenti, serve Software Assurance Lifecycle. Se il team deve decidere rischio residuo, priorità e impatto, serve Risk Assessment. Se la modifica attraversa architettura, flussi dati e integrazioni, serve una review del disegno.

Evidenze da preparare

Per rendere efficace la verifica servono repository, pull request, descrizione del task, prompt o issue di partenza, elenco degli agenti o tool usati, parti generate o modificate, ruoli applicativi, schema dati, API esposte, integrazioni, workflow CI/CD, variabili ambiente, dipendenze principali e ambienti disponibili.

Sono utili anche evidenze di processo: chi ha approvato il piano dell’agente, chi ha revisionato il diff, quali test sono stati aggiunti, quali minacce sono state considerate, quali rischi sono stati accettati e quali remediation sono state pianificate. Queste informazioni evitano una review cieca, perché il codice non racconta sempre perché una decisione è stata presa, quali assunzioni ha fatto l’agente o quale rischio il team pensava di accettare.

Domande frequenti

Il threat modeling serve anche per una singola PR generata da AI?
Sì, se la PR tocca dati, ruoli, API, segreti, pagamenti, pipeline, cloud o logica di business. Per modifiche piccole basta un threat model leggero, ma le domande su asset, attori, flussi e abuso restano utili.
Threat modeling e Code Review sono la stessa cosa?
No. Il threat modeling definisce cosa può andare storto e quali controlli servono. La Code Review verifica se il codice, il diff e i test implementano quei controlli senza regressioni.
STRIDE basta per il codice AI-generated?
STRIDE è utile per non dimenticare famiglie di minacce, ma va adattato a prompt, agenti, repository, pipeline, tool call, segreti e dati runtime. La parte importante è trasformare ogni minaccia in un controllo verificabile.
I test automatici generati dall’AI bastano?
No. I test generati dall’AI tendono a coprire il percorso previsto. Servono anche test negativi, casi multi-utente, abuso dei ruoli, tenant isolation, input manipolati e verifiche su pipeline e configurazioni.
Quando serve un Risk Assessment?
Quando il team deve decidere se accettare un rischio, priorizzare remediation o collegare il progetto a impatti aziendali, dati personali, compliance, fornitori o continuità operativa.

Vuoi un Software Assurance Lifecycle realmente sicuro, continuo e conforme?

Affidati a ISGroup per:

Code review manuale e test reali in ogni fase dello sviluppo
Integrazione con DevSecOps, SBOM e remediation assistita
Compliance completa a NIS2, GDPR, DORA con supporto tecnico dedicato

Parla con un esperto

Threat modeling per codice AI: dal prompt alla pull request