Gli assistenti di codifica basati sull’intelligenza artificiale (IA) generano codice sintatticamente corretto più del 95 % delle volte. Tuttavia, solo il 55 % di questi snippet è realmente sicuro, secondo gli studi più recenti. Questa discrepanza spinge le aziende a guardare oltre la corsa alle prestazioni dei modelli, focalizzandosi su “delivery harness”, ovvero sistemi di controllo che integrano responsabilità umana, governance basata sul rischio e verifiche automatiche in ogni fase del ciclo di sviluppo.

1 – La sicurezza del codice resta il punto debole

Prima di scalare l’uso dell’IA nei team di sviluppo, ogni Direttore dei Sistemi Informativi (DSI) dovrebbe tenere presente che solo il 55 % del codice prodotto dai grandi modelli di linguaggio (LLM) è sicuro. Dal 2025 Veracode conduce un benchmark costante con 80 task di programmazione, aggiornato a marzo 2026 e includente più di 150 modelli. I risultati mostrano che, nei 45 % dei casi rimanenti, il modello introduce vulnerabilità appartenenti all’OWASP Top 10.

Il paradosso è evidente: la correzione sintattica supera il 95 %, ma le metriche di sicurezza sono rimaste sostanzialmente statiche negli ultimi due anni. Modelli come GPT‑5.1, GPT‑5.2, Gemini 3, Claude 4.5 e Claude 4.6 (valutati nella primavera 2026) si collocano tutti tra il 55 % e il 60 % di codice sicuro. Solo le varianti di ragionamento di OpenAI superano il 70 % (70‑72 %), ma anche in quel caso uno su tre pezzi di codice risulta vulnerabile.

La lezione è chiara: i progressi dei modelli non eliminano la necessità di controlli di sicurezza robusti.

2 – Il contesto è più importante del modello

Il benchmark diventa ancora più istruttivo analizzando le tipologie di vulnerabilità. I modelli ottengono buoni risultati contro iniezioni SQL (82 %) e problemi di crittografia (86 %), dove le soluzioni sicure sono spesso evidenti. Invece, le prestazioni crollano per cross‑site scripting (XSS) (15 %) e log injection (13 %). Queste debolezze richiedono la comprensione del flusso dei dati controllati dall’utente, un contesto che i modelli non possiedono.

Le differenze emergono anche a livello di linguaggio di programmazione: Python raggiunge il 62 %, JavaScript il 57 %, mentre Java scende drasticamente al 29 %. La causa è legata a decenni di codice legacy presente nel corpus di addestramento dei modelli, che impara pratiche non sicure come se fossero standard. Anche se PHP non è stato incluso nel benchmark, è ragionevole supporre dinamiche analoghe.

I framework moderni offrono protezioni preziose: le query preparate di Doctrine in Symfony, l’escaping automatico di Twig e la sanitizzazione dei template di Angular riducono notevolmente i rischi. Tuttavia, queste difese svaniscono quando il modello produce SQL “bare”, filtri grezzi o utilizza metodi come bypassSecurityTrust.

Il problema è strutturale: i modelli sono addestrati su codice pubblicamente disponibile, grande parte del quale contiene vulnerabilità mai corrette. Le implementazioni insicure diventano così parte dell’apprendimento del modello, normalizzandole come pratiche accettabili.

Persino i fornitori riconoscono che la potenza grezza del modello non è sufficiente. Anthropic, ad esempio, rende pubblico solo Fable 5, una versione con classificatore di sicurezza, mentre la variante non filtrata, Mythos 5, è riservata a un ristretto gruppo di organizzazioni approvate.

Valutazioni indipendenti confermano tale scenario. Endor Labs colloca Fable 5 a metà classifica per correzione di vulnerabilità. Sonar ha individuato una vulnerabilità di livello elevato in un modulo Java generato in tredici minuti; la falla è stata intercettata solo da un controllo di qualità prima del rilascio.

Se i fornitori aggiungono guardrails, le aziende devono fare altrettanto.

3 – Non cercare il modello più sicuro, ma il contesto d’uso più sicuro

La domanda chiave per le organizzazioni non è più “Qual è il modello più sicuro?”. Il vero focus è il delivery harness agentico: un insieme coerente di regole di governance, meccanismi di supervisione umana e controlli automatizzati che avvolgono il codice generato dall’IA lungo l’intero ciclo di vita del software.

La prima regola è fondamentale: l’IA può generare il 100 % del codice, ma il 100 % deve essere compreso e validato da un umano. Nessun artefatto viene integrato senza che sia stato compreso appieno.

    • Gli sviluppatori rimangono responsabili di ogni incremento rilasciato.
    • Un esperto tecnico senior conduce una revisione tecnica sistematica.
    • L’accettazione contrattuale dei deliverable non è delegata a un agente IA.
    • Qualsiasi incertezza viene segnalata, non risolta tramite scambio non verificato con un LLM.

Questa metodica non sostituisce gli ingegneri esperti, ma ne amplifica l’efficacia. Identificare una concatenazione SQL non protetta o la mancanza di escaping è proprio il tipo di compito che, come dimostrano i benchmark, richiede ancora l’intervento umano.

4 – La governance permette di accelerare

Le “zone rosse” – sicurezza, diritti di accesso, dati sensibili, modelli di dati critici e componenti architetturali chiave – richiedono restrizioni: il codice generato è vietato o sottoposto a validazione rigorosa prima dell’implementazione. Al contrario, le aree a basso rischio possono sfruttare la velocità dell’approccio agentico.

Questa asimmetria deliberata consente di mantenere un’alta velocità di sviluppo senza compromettere la sicurezza. I controlli di qualità non sono più un’attività post‑mortem, ma si integrano lungo l’intero percorso di consegna.

    • Le specifiche e i criteri di accettazione sono verificati prima della generazione.
    • Le informazioni sensibili sono filtrate prima di essere incluse nei prompt.
    • La copertura dei test deve raggiungere almeno l’80 %.
    • Ogni artefatto è tracciabile, compreso il modello che lo ha prodotto.

5 – Trasformare la governance in ingegneria

La governance non può rimanere una mera procedura amministrativa; deve diventare parte integrante dell’ingegneria del software. Ciò implica:

    • Automatizzare i controlli di sicurezza all’interno della pipeline CI/CD.
    • Integrare scanner statici (es. Veracode, SonarQube) che analizzano in tempo reale il codice generato.
    • Definire policy di “prompt hygiene” che escludono dati sensibili e limitano la portata dei prompt.
    • Implementare audit log dettagliati che registrano modello, prompt, risposta e revisione umana.
    • Stabilire metriche operative (percentuale di codice critico revisionato, tempo medio di risoluzione delle vulnerabilità, tasso di falsi positivi).

Queste pratiche convergono in un ciclo di feedback continuo: ogni vulnerabilità scoperta alimenta il training interno di filtri personalizzati, migliorando gradualmente la qualità delle generazioni future.

6 – Il ruolo delle piattaforme fornitrici

Anche i fornitori di LLM stanno evolvendo. Molti introducono:

    • Classificatori integrati per filtrare output non sicuri.
    • API di “safety‑first” che restituiscono avvisi di vulnerabilità contestuali.
    • Programmi di “responsible AI” che consentono alle imprese di condividere segnali di rischio senza esporre codice proprietario.

Queste funzionalità, tuttavia, non sono una panacea. Le aziende devono valutare la robustezza dei filtri, la trasparenza delle metriche fornite e la possibilità di personalizzare i parametri di sicurezza secondo le proprie policy.

7 – Come avviare un delivery harness efficace

Il percorso consigliato per le imprese è:

    • Audit iniziale: mappare le aree di rischio, identificare “zone rosse” e valutare la maturità dei processi di sicurezza.
    • Definizione delle policy: stabilire regole su quando e come usare l’IA, i limiti di prompt, i livelli di revisione richiesti.
    • Implementazione di toolchain: integrare scanner statici, test automatizzati e sistemi di tracciamento all’interno della pipeline CI/CD.
    • Formazione del personale: addestrare sviluppatori e reviewer su vulnerabilità comuni, best practice di prompt engineering e interpretazione dei risultati dei modelli.
    • Monitoraggio continuo: raccogliere metriche di sicurezza, tassi di vulnerabilità, tempi di revisione e utilizzare i dati per ottimizzare le policy.
    • Iterazione: aggiornare costantemente il delivery harness in base a nuove vulnerabilità emergenti e a miglioramenti dei modelli.

Questo approccio consente di trasformare un potenziale rischio in un vantaggio competitivo, poiché le organizzazioni che implementano governance solida possono rilasciare funzionalità più rapidamente senza sacrificare la sicurezza.

8 – Conclusioni

Il panorama attuale dimostra che i modelli più avanzati non garantiscono codice più sicuro. La differenza competitiva risiede nella capacità di strutturare un ecosistema di governance robusto, dove l’IA è un “co‑pilota” affiancato da revisori umani, controlli automatici e policy chiare. Solo così le imprese potranno sfruttare pienamente la produttività dell’IA generativa, minimizzando al contempo l’esposizione a vulnerabilità e riducendo i costi associati a errori di sicurezza.