Il 7 aprile Bruce Schneier ha pubblicato un saggio sull’era del “software istantaneo”: applicazioni generate al volo da un’AI, usate per uno scopo, poi eliminate. La sua tesi, dichiaratamente ottimistica, è che la sicurezza potrebbe migliorare se i difensori useranno gli stessi strumenti degli attaccanti per trovare e patchare vulnerabilità più rapidamente.

È un argomento lineare. Il problema è che poggia su incognite enormi, e soprattutto su un presupposto fragile: che una parte rilevante del software generato dall’AI sia davvero effimera.

Nel mondo reale, molto codice AI non viene cancellato. Viene committato.

Il codice AI “usa e getta” non esiste in produzione

L’immagine centrale del saggio è questa: “Taken to an extreme, it might become easier for a user to have an AI write an application on demand—a spreadsheet, for example—and delete it when done.” Nessuna vulnerabilità persistente, nessuna superficie d’attacco duratura. Il software sparisce prima che qualcuno trovi il modo di sfruttarlo.

Come scenario estremo ha senso. Come descrizione della produzione, molto meno.

Un developer usa Copilot o Cursor per generare un modulo di autenticazione. Lo testa rapidamente: funziona. Lo committa. Da quel momento quel codice non è istantaneo: è permanente. Entra nel sistema, viene copiato in altri progetti, sopravvive ai team che l’hanno scritto, diventa dipendenza transitiva di cose che nessuno auditerà mai più.

Il software usa e getta esiste nei proof of concept e nelle demo. In produzione, molto meno codice viene buttato di quanto ci raccontiamo. Più spesso resta lì: non più compreso, non più presidiato, ma ancora eseguito.

Le cinque incognite dietro l’ottimismo di Schneier

Schneier elenca cinque “unknown” espliciti: quanto bene gli strumenti AI troveranno vulnerabilità nel codice closed-source commerciale; quanto migliorerà l’AI nello scrivere codice sicuro; quanto velocemente genererà patch affidabili; se troverà le vulnerabilità più oscure e sottili, quelle che richiedono comprensione contestuale profonda; e se risolveremo mai il prompt injection contro i sistemi AI difensivi.

Ognuna non è una nota a margine: è una condizione necessaria perché lo scenario ottimistico funzioni.

Se anche solo una di queste incognite non si risolve nel verso giusto, il bilancio tra difensori e attaccanti non cambia come Schneier prevede. L’ultima è la più scomoda: un sistema AI usato per difendere l’infrastruttura può essere attaccato manipolando i dati che analizza. Log di sistema costruiti per ingannarlo, input di rete progettati per alterarne il comportamento, ticket scritti per fargli classificare come innocuo ciò che non lo è.

Non è il classico bug isolato da correggere con una patch. È un problema che nasce dal modo in cui questi sistemi interpretano input, contesto e istruzioni. Forse verrà mitigato. Ma trattarlo come un dettaglio implementativo è già un errore.

La sicurezza del codice generato dall’AI è già un problema presente

Nel frattempo, chi produce la superficie d’attacco del prossimo ciclo?

Non solo i ricercatori di sicurezza con toolchain specializzate. Soprattutto gli sviluppatori ordinari che usano LLM oggi: endpoint REST generati con ChatGPT, query SQL completate da Copilot, logica di validazione degli input scritta con Cursor. Codice testato in superficie, committato perché funziona, deployato perché le deadline non aspettano.

I modelli non sono addestrati con la sicurezza come obiettivo primario. Il codice che generano può contenere SQL injection non evidente, gestione degli errori che espone stack trace, SSRF latenti, race condition su risorse condivise. Nessuno di questi pattern è sempre semplice da rilevare in una code review veloce, e in una code review assistita da AI il modello potrebbe non segnalarli se non istruito esplicitamente a farlo.

C’è anche un problema di incentivi, già visto nel billing strutturale dei token AI: gli strumenti AI premiano il volume d’uso e la velocità percepita, non la robustezza del codice prodotto. Gli assistenti di coding ottimizzano la rapidità di completamento. Più codice generato più in fretta è un segnale positivo per il prodotto, indipendentemente dalla correttezza di sicurezza.

La conseguenza è organizzativa prima ancora che tecnica: il collo di bottiglia non è più scrivere codice, ma capire cosa quel codice autorizza, espone e rende possibile. L’AI ha spostato avanti la produzione. La revisione di sicurezza è rimasta quasi ferma.

Il take di TechMonk

Schneier ha ragione sul lungo periodo: l’AI potrà dare ai difensori strumenti migliori, scanner più capaci, patch più rapide, automazione più profonda. Il punto in cui il suo scenario diventa fragile è il framing temporale. Presenta l’era del software istantaneo come qualcosa che deve ancora arrivare, quando in realtà ci siamo già dentro.

Solo che il software non viene buttato.

Viene deployato e dimenticato.

L’asimmetria tra attaccanti e difensori non sparisce con l’AI

La scommessa che i difensori vinceranno richiede una copertura altissima, molto più vicina alla completezza di quanto serva agli attaccanti.

Considera la matematica. In una codebase grande, anche una piccola percentuale di vulnerabilità mancate può essere sufficiente a lasciare aperti percorsi critici. Un sistema AI offensivo che trova una sola superficie d’attacco utile in un’infrastruttura distribuita è, per un attaccante, un successo enorme.

L’asimmetria non dipende solo dalla velocità degli strumenti: dipende dalla matematica della copertura. Difendere significa coprire tutto. Attaccare significa trovare un percorso.

L’AI ha accelerato entrambi i lati. Ha reso più veloce la generazione di codice potenzialmente vulnerabile e ha reso più veloce la ricerca di vulnerabilità nel codice esistente. Ma non è automatico che il rapporto tra i due cambi a favore dei difensori.

I difensori del 2030 erediteranno la superficie d’attacco costruita oggi, con tutti i commit LLM senza revisione di sicurezza che stiamo accumulando nel frattempo.

Il rischio più concreto è il codice che nessuno ha davvero progettato

Schneier inquadra il problema soprattutto come attaccanti esterni contro difensori. Il rischio più concreto per il prossimo ciclo, però, è interno.

Il codice AI-generated non genera solo vulnerabilità classiche: SQL injection, SSRF, race condition. Il rischio peggiore è più silenzioso. Endpoint creati senza modello di autorizzazione. Separazione tra tenant lasciata implicita. Controlli di ownership applicati in un punto ma dimenticati in un altro. Logica di business che sembra plausibile, passa i test funzionali, e incorpora broken access control a livello di design.

Esempio banale: un LLM genera un endpoint /invoices/{id} che controlla solo se l’utente è autenticato, non se quella fattura appartiene davvero a quell’utente. Il test funzionale passa, perché con l’utente giusto la fattura si vede. Il bug non è sintattico. Non è una injection. È un errore di modello mentale.

Gli strumenti statici possono intercettare alcuni segnali, ma spesso non hanno il contesto di dominio per capire se quell’accesso sia legittimo. Il problema non è solo “il codice è vulnerabile”. È “il sistema consente qualcosa che il prodotto non avrebbe mai dovuto consentire”.

Le organizzazioni con requisiti di compliance stringenti — GDPR, SOC 2, settore finanziario, sanità — si troveranno a fare audit su codice che ha superato molti controlli tecnici e fallisce su un principio di design. Non è un attacco esterno. È un failure by construction.

La domanda che Schneier non fa è la più concreta: su quali dataset sono stati addestrati i modelli che scrivono il codice di oggi? Se la risposta è GitHub, e GitHub contiene vent’anni di pattern insicuri accumulati da chi non aveva la sicurezza in mente, l’AI replica quegli stessi pattern con velocità maggiore e attenzione minore.

Il difensore ottimista di Schneier probabilmente arriverà. Avrà scanner migliori, patch più rapide, agenti più coordinati.

Il problema è cosa troverà quando arriverà.

Perché il codice generato oggi non sta aspettando quel futuro. Sta entrando nei repository, nei deploy, nei sistemi interni, nelle API pubbliche. E ogni commit accettato senza una revisione di sicurezza non è software istantaneo.

È debito. Con privilegi di esecuzione.