Negli ultimi mesi l’adozione dell’intelligenza artificiale nello sviluppo software ha smesso di essere un esperimento ed è diventata pratica operativa quotidiana.
Team IT, sviluppatori, system engineer e persino funzioni non tecniche stanno iniziando a costruire tool interni, dashboard, automazioni e vere e proprie applicazioni partendo da prompt e codice generato da AI. Il vantaggio è evidente: tempi di sviluppo ridotti, costi più bassi, maggiore autonomia dei team.
Ma come spesso accade, ogni accelerazione introduce anche un nuovo tipo di rischio.
Il lato meno visibile dell’AI nello sviluppo
Quando si parla di AI applicata al coding, l’attenzione si concentra quasi sempre sulla produttività. Molto meno si parla della qualità del codice generato, e soprattutto della sua sicurezza.
Eppure i dati iniziano a essere piuttosto chiari.
Secondo il report 2026 di Sherlock Forensics, il 92% delle codebase generate con AI contiene almeno una vulnerabilità critica
Fonte: https://www.sherlockforensics.com/pages/ai-code-security-report-2026.html
Un’analisi di Veracode del 2025 evidenzia che circa il 45% del codice generato presenta problematiche di sicurezza rilevanti
Fonte: https://technave.com/gadget/This-study-reveals-that-almost-half-of-AI-generated-code-has-security-issues-43585.html
E forse il dato più interessante è un altro: solo una piccola percentuale di aziende integra controlli di sicurezza strutturati su questo tipo di codice.
Questo crea un disallineamento pericoloso:
la velocità di sviluppo cresce esponenzialmente, mentre i controlli rimangono lineari — o assenti.
Perché il codice generato da AI è spesso vulnerabile
Il problema non è tanto che l’AI “sbaglia”, ma che lavora con un obiettivo diverso rispetto a quello della sicurezza.
I modelli generativi sono ottimizzati per produrre codice funzionante e coerente con il contesto richiesto. Non sono, per loro natura, progettati per garantire che quel codice sia robusto rispetto a minacce reali.
Inoltre:
- apprendono da grandi quantità di codice pubblico, che include anche pattern insicuri
- tendono a replicare soluzioni comuni, incluse vulnerabilità note (CWE)
- non hanno consapevolezza del contesto architetturale complessivo in cui il codice verrà inserito
Il risultato è un codice che “funziona”, ma che spesso non è stato pensato per resistere a un attacco.
Il falso senso di sicurezza delle applicazioni interne
Un altro aspetto critico riguarda la destinazione d’uso di queste applicazioni.
Molti dei tool creati con AI sono interni:
- portali operativi
- strumenti di automazione
- API tra servizi
- interfacce di gestione infrastrutturale
Ed è proprio qui che emerge uno dei bias più pericolosi:
“È interno, quindi è sicuro.”
In realtà, dal punto di vista di un attaccante, le applicazioni interne sono estremamente interessanti.
Una volta ottenuto un primo accesso (phishing, credenziali compromesse, exploit esterno), il vero obiettivo diventa il movimento laterale.
E le applicazioni interne spesso offrono:
- controlli di sicurezza meno rigorosi
- autenticazioni deboli o implicite
- accesso diretto a dati e sistemi critici
In altre parole, diventano il punto ideale per escalation e pivoting.
Come queste vulnerabilità vengono sfruttate
Un’applicazione sviluppata rapidamente con AI, senza un processo di validazione, può introdurre diversi scenari di rischio.
Può esporre endpoint non protetti, diventando un entry point iniziale.
Può integrare logiche di autorizzazione incomplete, permettendo accessi indebiti.
Può interagire con database o servizi interni senza adeguata segregazione dei privilegi.
Nel momento in cui un attaccante individua una di queste debolezze, l’applicazione smette di essere un semplice tool interno e diventa un moltiplicatore dell’impatto dell’attacco.
Va inoltre considerato un elemento emergente: l’uso dell’AI anche in ambito offensivo.
Esistono già modelli in grado di analizzare codice e identificare vulnerabilità in modo automatico, riducendo drasticamente il tempo necessario per individuare punti deboli.
Questo cambia completamente la scala del problema.
Come usare l’AI in modo corretto (e sicuro)
Bloccare l’uso dell’AI non è realistico, né auspicabile.
La direzione corretta è governarne l’utilizzo.
Il primo passo è cambiare il modo in cui si interagisce con questi strumenti. Non basta chiedere di generare codice: è necessario imporre vincoli espliciti.
Richiedere l’adesione a standard come OWASP Top 10, pretendere validazione degli input, gestione corretta delle autenticazioni e protezione contro le vulnerabilità più comuni deve diventare parte integrante del prompt stesso.
Ma non è sufficiente.
Serve introdurre un approccio di security by design, in cui la sicurezza non è un controllo finale ma un requisito architetturale. Questo significa progettare con logiche di least privilege, segmentazione e zero trust anche per applicazioni interne.
A livello operativo, è fondamentale integrare controlli automatici all’interno delle pipeline di sviluppo: analisi statica, analisi dinamica, controllo delle dipendenze e rilevamento di segreti esposti.
E soprattutto, serve un elemento che l’AI non può sostituire: la revisione umana.
Una code review fatta con competenze di sicurezza è spesso ciò che permette di individuare vulnerabilità logiche che nessun tool automatico riesce a intercettare.
Infine, prima di mettere in produzione, un penetration test resta uno degli strumenti più efficaci per simulare un attacco reale e validare la resilienza dell’applicazione.
Il ruolo di un audit di sicurezza
Arrivati a questo punto, emerge un concetto chiave:
il codice generato da AI non può essere considerato affidabile per default.
Richiede lo stesso livello — se non superiore — di verifica rispetto al codice tradizionale.
Un audit di sicurezza strutturato permette di:
- identificare vulnerabilità reali e sfruttabili
- analizzare le logiche applicative e i flussi di accesso
- verificare l’esposizione delle API
- valutare l’integrazione con altri sistemi
Non si tratta solo di trovare bug, ma di comprendere come un attaccante potrebbe realmente muoversi all’interno dell’ambiente.
Dove entra in gioco Dognet Technologies
In questo scenario, il valore non sta solo negli strumenti, ma nell’approccio.
Dognet Technologies lavora con una prospettiva offensiva: analizzare le applicazioni non per come dovrebbero funzionare, ma per come possono essere compromesse.
Questo si traduce in:
- audit di sicurezza su applicazioni sviluppate con AI
- revisione del codice focalizzata su vulnerabilità concrete
- penetration test su applicazioni interne ed esterne
- analisi delle superfici d’attacco generate dall’integrazione tra sistemi
L’obiettivo non è la compliance formale, ma la riduzione reale del rischio.
Conclusione
L’intelligenza artificiale sta ridefinendo lo sviluppo software.
Questo è un dato di fatto.
Ma ogni nuova capacità introduce una nuova responsabilità.
Le aziende che riusciranno a trarne vantaggio non saranno quelle che sviluppano più velocemente, ma quelle che sapranno mantenere il controllo mentre accelerano.
Perché se è vero che oggi chiunque può creare un’applicazione in poche ore, è altrettanto vero che un attaccante può analizzarla in pochi minuti.
E a quel punto, la differenza la fa una sola cosa:
quanto è stata presa sul serio la sicurezza.
