In questo articolo Indice dei contenuti 2 sezioni
Quando si parla di AI e sicurezza software, il punto non è più quanto velocemente si riesca a scrivere codice, ma quanto quel codice allarghi la superficie di attacco di un’organizzazione. L’intelligenza artificiale ha compresso i tempi dello sviluppo in modo evidente, e insieme ai tempi ha compresso anche i margini di controllo. Il risultato è un paradosso che chi lavora nella sicurezza conosce bene, cioè la produttività cresce, mentre l’esposizione cyber cresce con lei, spesso più in fretta di quanto le squadre di sicurezza riescano a mappare.
La tentazione, in questi casi, è quella di rispondere con lo strumento più familiare, ovvero il controllo del codice. Analisi statica, revisione, scansione delle dipendenze. Tutte pratiche utili, nessuno lo mette in discussione, ma sostanzialmente insufficienti se il perimetro del problema è cambiato. Un’applicazione generata o assistita da intelligenza artificiale non vive isolata, si appoggia a infrastrutture, richiama servizi esterni, consuma credenziali, parla con sistemi aziendali che a loro volta parlano con altri sistemi. Il rischio non abita solo dentro le righe di codice, abita nelle connessioni.
Il codice non è più il confine della sicurezza
Ridurre la sicurezza software a un problema di qualità del codice significa guardare il dito. Le vulnerabilità che contano davvero, quelle che diventano incidenti, nascono di frequente dalla combinazione di elementi che, presi singolarmente, sembrano innocui. Una configurazione permissiva, un’identità con privilegi eccessivi, un’API lasciata raggiungibile senza una vera necessità operativa. L’accelerazione portata dall’AI moltiplica queste occasioni, semplicemente perché moltiplica il numero di componenti che entrano in produzione nell’unità di tempo.
Le identità, in particolare, sono diventate il vero nodo. Non solo quelle umane, anche e soprattutto quelle applicative, i token, le chiavi, gli account di servizio che nessuno rivede da mesi. Ogni nuovo modulo generato in fretta tende a portarsi dietro il proprio corredo di credenziali, e senza una gestione ordinata quel corredo si trasforma in un archivio di porte socchiuse. Le infrastrutture cloud amplificano l’effetto, perché rendono banale creare risorse e molto meno banale dismetterle.
Contesto e governance come leve concrete
Serve contesto, ed è qui che si separano gli approcci maturi da quelli decorativi. Sapere che esiste una vulnerabilità è informazione grezza, capire se quella vulnerabilità è raggiungibile, se il sistema che la ospita tocca dati sensibili, se un attaccante avrebbe un percorso praticabile per sfruttarla, è invece informazione utilizzabile. Senza questo filtro le squadre di sicurezza affogano in liste di allerta indistinguibili tra loro, e finiscono per correggere ciò che è facile piuttosto che ciò che è rilevante.
La governance completa il quadro. Non intesa come documento da archiviare, piuttosto come insieme di regole operative che stabiliscono chi può introdurre cosa, con quali verifiche, con quale tracciabilità. Nel momento in cui strumenti di AI entrano nei flussi di sviluppo quotidiani, decidere in anticipo dove il loro contributo è accettabile e dove richiede una revisione umana diventa una scelta di sicurezza, non un vincolo burocratico. La responsabilità del risultato resta di chi sviluppa e di chi approva, mai del modello.
Valutare i rischi reali lungo tutta la catena, dalle infrastrutture ai sistemi aziendali, passando per identità e interfacce di comunicazione, è un lavoro meno spettacolare della caccia al bug ma decisamente più efficace. Significa accettare che la sicurezza non sia un cancello posizionato all’ingresso della produzione, ma una lettura continua di come le parti interagiscono tra loro. L’intelligenza artificiale non ha creato questa necessità, l’ha soltanto resa impossibile da rinviare, perché ha portato la velocità dello sviluppo a un livello che i controlli tradizionali, da soli, non riescono più a seguire.
