Il codice costruito dall'IA è davvero sicuro? Le domande frequenti di chi costruisce

Ricevo una versione di questa domanda in quasi ogni chiamata di onboarding, di solito formulata con cautela, come se la persona che la pone si aspettasse quasi di essere convinta a non preoccuparsi. Non dovrebbe. La sicurezza è uno dei pochi ambiti in cui una dose sana di paranoia è correttamente calibrata, che il codice sia stato scritto da un umano o da un modello. Di seguito le domande che mi vengono fatte davvero, con le risposte più dirette che riesco a dare.

Il codice scritto dall'AI è meno sicuro di quello scritto da un umano?

In media, e senza controlli, sì — leggermente. Uno studio di Stanford di qualche anno fa (Perry et al., spesso citato come il primo vero studio sull'argomento) ha rilevato che gli sviluppatori che usavano un assistente AI per la programmazione producevano codice meno sicuro rispetto a un gruppo di controllo e — questa è la parte che dovrebbe preoccupare di più — valutavano il proprio codice come più sicuro di quanto fosse realmente. La fiducia aumentava mentre la qualità diminuiva. Anche le scansioni più recenti di Veracode sulla sicurezza del codice generato da AI danno un numero approssimativo: circa 4 su 10 campioni di codice generato dall'AI testati presentavano almeno una falla sfruttabile, di solito qualcosa di banale come un controllo di input mancante o un valore predefinito debole. Nulla di tutto ciò significa che il codice scritto dall'AI sia intrinsecamente condannato. Significa che il codice scritto dall'AI non revisionato comporta lo stesso rischio del codice umano non revisionato, e la parte "non revisionato" è dove risiede davvero il pericolo. Un modello che scrive velocemente e non viene mai controllato commetterà gli stessi errori di uno sviluppatore junior in un venerdì pomeriggio — solo più velocemente, e in numero maggiore.

Cosa succede alle mie chiavi API e ai miei segreti?

Questa è la cosa che mi toglie davvero il sonno, perché è l'errore invisibile finché non lo è più. La modalità di fallimento non è drammatica — nessuno subisce una violazione stile film hollywoodiano. È una chiave incollata in una chat, ripetuta in un file generato, committata, e sei mesi dopo qualcuno esegue uno scanner di segreti per curiosità e la trova in chiaro in un repo. Su questa piattaforma, i segreti non risiedono mai nel codice sorgente generato — vengono iniettati a runtime da un archivio criptato, isolato per tenant, e gli agenti di build ricevono l'istruzione di fare riferimento ad essi per nome, mai per valore. Ma se costruite altrove, o incollate credenziali direttamente in una finestra di chat con qualsiasi strumento, presumete che quel testo faccia ormai parte di un log adiacente al training da qualche parte, a meno che il fornitore non dichiari esplicitamente il contrario. Ruotate per principio tutto ciò che avete mai digitato in una casella di chat, lo stesso giorno in cui finite di testare.

Qualcuno può violare il mio sito tramite un prompt, come un attacco di prompt injection?

Qui si confondono due cose diverse, e la distinzione conta. La prompt injection contro il builder — qualcuno che inganna l'AI che sta costruendo la vostra app per farle fare qualcosa che non avete chiesto — è un rischio reale e studiato, ed è per questo che gli agenti di build operano con permessi degli strumenti limitati anziché accesso shell illimitato, e per questo tutto ciò che tocca il vostro filesystem o la pipeline di deploy passa attraverso un registro di azioni esplicito che potete verificare in seguito. La prompt injection contro la vostra app pubblicata è una preoccupazione separata che si applica solo se la vostra app integra un LLM a runtime — un chatbot di supporto, una funzione di ricerca AI, quel genere di cose. Se lo fa, trattate qualsiasi testo che un utente può digitare come input non attendibile per quel modello, allo stesso modo in cui lo trattereste come input non attendibile per una query SQL. La regola è vecchia, la parte nuova è solo quale sistema sta interpretando la stringa.

Il builder controlla il proprio codice alla ricerca di vulnerabilità prima di pubblicarlo?

I controlli automatizzati intercettano in modo affidabile le cose banali e ad alta frequenza: segreti hardcoded, autenticazione mancante su un endpoint che chiaramente ne ha bisogno, SQL costruito per concatenazione di stringhe anziché con parametri, dipendenze con una CVE nota. Ciò che non intercettano bene sono i difetti di logica di business — il tipo in cui ogni singola riga di codice va bene e la vulnerabilità sta nel divario tra due funzionalità che nessuno ha pensato di controllare insieme. Un codice sconto che si accumula all'infinito con un bonus referral. Un flusso di reset password che rivela se un'email esiste nel sistema. Questi richiedono qualcuno che capisca a cosa serve l'app, non solo cosa fa il codice, e nessuno scanner — AI o meno — li trova ancora in modo affidabile. La revisione automatizzata è un pavimento, non un soffitto.

E i pacchetti di terze parti che installa — è un rischio per la supply chain?

Sì, ed è onestamente un rischio più concreto nel mondo reale rispetto al codice scritto dall'AI stessa. La maggior parte delle app è composta per l'80-95% da dipendenze in termini di righe di codice; il codice scritto da un builder è un sottile strato sopra npm, PyPI, o qualunque ecosistema usi lo stack. Un pacchetto malevolo o compromesso può danneggiarvi a prescindere da chi o cosa abbia scritto il codice di collegamento attorno ad esso — vedere gli incidenti event-stream e colors.js per capire come si svolge nella realtà. Le mitigazioni sono noiose ed efficaci: fissare le versioni invece di seguire sempre l'ultima, preferire pacchetti con una vera storia di manutenzione rispetto a quelli pubblicati la settimana scorsa, ed eseguire un audit delle dipendenze (`npm audit`, `pip-audit`, o quello adatto al vostro stack) come abitudine costante, non come singolo passaggio prima del lancio.

Chi è responsabile in caso di violazione?

Siete voi — legalmente, quasi sempre, se è la vostra app e i dati sono dei vostri clienti. Questo sorprende chi presume che "l'ha scritto l'AI" sposti la responsabilità altrove. Non è così, allo stesso modo in cui assumere un appaltatore non sposta la responsabilità di una violazione del codice edilizio lontano dal proprietario dell'immobile. Le piattaforme si assumono la responsabilità dell'infrastruttura che controllano: come vengono conservati i segreti, come viene isolato i dati dei tenant, se lo strato di hosting stesso è aggiornato. Ma la logica applicativa che avete specificato, i dati che avete scelto di raccogliere e i termini che avete offerto ai vostri utenti sono vostri. Se gestite qualcosa di sensibile — dettagli di pagamento, informazioni sanitarie, qualsiasi cosa soggetta a GDPR o CCPA — leggete l'effettivo accordo sul trattamento dei dati della piattaforma che state usando, invece di presumere che "costruito con l'AI" implichi un ulteriore strato di copertura legale. Non è così.

Una fondatrice mi ha detto una volta, per lo più scherzando, che si fidava del codice dell'AI più del proprio perché "almeno non si stanca alle 2 di notte". Forse. Ma gli umani stanchi di solito sanno di esserlo. Un'AI non ha idea di aver appena commesso un errore, e vi dirà che il codice è pronto con esattamente lo stesso tono sicuro, che sia impeccabile o pieno di falle. La sicurezza espressa non è un segnale di sicurezza reale, da nessuna delle due fonti.

Dovrei pagare per un vero audit di sicurezza prima del lancio?

Se accettate pagamenti, conservate qualsiasi cosa che un ente regolatore chiamerebbe PII, o state costruendo per un cliente business che comunque chiederà un rapporto SOC 2 — sì, e non lasciate che il costo vi convinca a rinunciarci. Un audit mirato su una piccola app costa da poche centinaia a qualche migliaio di dollari a seconda dell'ambito, il che è economico rispetto a una lettera di notifica di violazione. Se state costruendo un progetto hobbistico, uno strumento interno o qualcosa senza dati utente reali in gioco, un audit a pagamento è eccessivo; usate invece il livello gratuito ed economico — scansione delle dipendenze, un controllo manuale di ogni confine di autenticazione (l'utente A può vedere le cose dell'utente B cambiando un URL?), e un secondo paio di occhi umani su qualsiasi cosa tocchi denaro o password.

Qual è l'errore di sicurezza più comune che le persone commettono, e quando avviene?

Non al lancio — tre mesi dopo, quando l'app funziona e nessuno la guarda più. È una rotta di amministrazione lasciata senza protezione perché è stata testata solo dalla persona che l'ha costruita, autenticata come se stessa. È un endpoint di debug che restituisce stack trace completi in produzione. È una password predefinita su un database che doveva essere "solo per i test" e non è mai stata ruotata. Nessuno di questi è esotico. Sono l'equivalente in sicurezza di lasciare una chiave di riserva sotto lo zerbino perché quella volta avevate fretta e poi ve ne siete dimenticati. La soluzione non è uno strumento migliore, è un'abitudine di cinque minuti: una volta al mese, guardate la vostra app come farebbe un attaccante per cinque minuti prima di guardarla come farebbe un builder orgoglioso.