Perché il codice generato dall’AI sta rompendo il tuo modello di gestione delle vulnerabilità

I generatori di codice AI hanno fatto qualcosa che anni di strumenti DevOps non sono mai riusciti a fare: hanno reso possibile la consegna di funzionalità in pochi giorni che in passato richiedevano settimane. Il problema è che la velocità si applica ugualmente alle vulnerabilità.

Nel corso degli anni, ho visto le organizzazioni ciclare attraverso lo stesso modello reattivo: scoprire una vulnerabilità, affannarsi per capirne l’entità, discutere su chi è responsabile della correzione e porvi rimedio settimane o mesi dopo. L’AI non ha cambiato questo modello. Lo ha accelerato a un ritmo a cui il vecchio modello non può più tenere il passo. La media di tempo di risoluzione (MTTR) per le vulnerabilità critiche è superiore a 60 giorni. L’AI non ti dà 60 giorni. Ti dà una nuova base di codice ogni sprint.

Il problema delle dipendenze è ora un problema di AI

Il 96% delle applicazioni aziendali include componenti open source. La maggior parte non è stata mai sottoposta a un’attenta valutazione, ma è stata semplicemente presa da registri pubblici perché funzionava e qualcuno ne aveva bisogno quel pomeriggio. I team di sicurezza stanno perdendo terreno su questo da anni e gli assistenti di codifica AI hanno trasformato una lenta emorragia in qualcosa di molto più difficile da controllare.

Quando uno sviluppatore scrive manualmente il codice, prende decisioni deliberate sulle dipendenze. Quando un modello AI genera codice, prende da ciò su cui è stato addestrato. Ciò significa spesso pacchetti immaginari, versioni obsolete o componenti con vulnerabilità note che il modello non aveva alcun motivo di evitare. Il codice arriva pulito. Il rischio è incorporato nell’albero delle dipendenze, a diversi livelli di profondità, invisibile a chi non lo sta cercando specificamente.

Ho partecipato a revisioni di sicurezza in cui i team erano scioccati nel trovare una vulnerabilità critica in una dipendenza transitiva di un pacchetto approvato mesi prima. Il pacchetto era a posto. Quello che ha portato con sé non lo era. Questa dinamica si sta verificando ora su scala macchina, attraverso centinaia di sviluppatori che utilizzano strumenti AI che non hanno alcun concetto della postura di sicurezza della tua organizzazione.

La scansione dopo il fatto non è una strategia

Il modello prevalente per la sicurezza del software open source è scan-and-patch: eseguire uno scanner, triare i risultati, assegnare biglietti e aspettare. Questo modello è sempre stato reattivo e in un ambiente di sviluppo accelerato dall’AI, è completamente superato.

Gli scanner trovano problemi dopo che sono già nel tuo codice. La finestra tra l’introduzione e la scoperta è dove vive la tua esposizione. Quando l’AI genera codice su larga scala, quella finestra si allarga e il volume dei risultati cresce più velocemente di quanto qualsiasi team possa manualmente porvi rimedio. Il risultato è un backlog di CVE che si espande indefinitamente, una priorità che diventa un lavoro di ipotesi e gli sviluppatori spendono 4-8 ore per vulnerabilità su un lavoro che produce zero valore aziendale.

Aggiungi le rotture di governance che seguono e il quadro peggiora. La proprietà della correzione è spesso poco chiara. La sicurezza segnala una CVE, l’ingegneria la chiama una questione di configurazione e le operazioni la chiamano un problema di codice. Ho visto questo modello 20 anni fa e non è scomparso. L’AI rende le conseguenze di quell’ambiguità significativamente più difficili da assorbire.

Il cambiamento che funziona veramente: controllare ciò che entra

Le organizzazioni che stanno superando questo hanno smesso di cercare di scansionare il loro percorso verso la sicurezza e hanno iniziato a controllare ciò che i loro sviluppatori e gli strumenti AI possono consumare per prima cosa. Il meccanismo è un catalogo curato, governato da politiche, di componenti open source, costruito dalle fonti, monitorato continuamente e fornito come registro interno privato che sostituisce il pull diretto da ecosistemi pubblici come PyPI, npm o Maven.

Questo approccio sposta la sicurezza a sinistra nel senso più letterale. Le vulnerabilità vengono bloccate nel punto di consumo, prima che entrino nella pipeline di build. Gli sviluppatori utilizzano gli stessi strumenti che hanno sempre utilizzato. Gli assistenti di codifica AI risolvono le dipendenze dalla stessa fonte governata. Il team di sicurezza stabilisce la politica una volta e quella politica si applica ovunque, compreso al codice generato da un modello alle 2 del mattino senza che nessun umano lo abbia revisionato.

Cosa significa questo nella pratica

Per i leader della sicurezza che stanno lavorando a questo, alcune cose sono più importanti di altre:

1. Definisci il tuo set di componenti approvati prima di scalare l’adozione dell’AI. Se i tuoi strumenti di codifica AI stanno risolvendo le dipendenze da registri pubblici, il tuo processo di approvazione esiste solo sulla carta. Stabilisci un registro interno governato, indirizza tutto attraverso di esso e richiedi che i componenti siano costruiti dalle fonti con provenienza verificabile.
2. Tratta la correzione come un processo gestito, non come una coda di biglietti. Le organizzazioni che stanno superando il debito CVE non stanno muovendosi più velocemente sulla correzione manuale. Hanno rimosso la correzione manuale dall’equazione. Quando è disponibile un patch approvato dalla comunità, viene ricostruito automaticamente nel catalogo. Gli sviluppatori ricevono l’aggiornamento la prossima volta che eseguono il pull. Nessuno assegna un biglietto. Nessuno aspetta 60 giorni.
3. Mappa la tua catena di strumenti AI alle tue obbligazioni di conformità prima di essere costretto a farlo. Ho visto team costruire su strumenti AI per mesi, solo per incontrare un muro quando un cliente ha richiesto l’allineamento con FedRAMP o l’evidenza SOC 2. Il tuo catalogo curato è anche la tua traccia di audit di conformità. Le registrazioni SBOM e di provenienza dovrebbero essere fornite con ogni componente, non assemblate retroattivamente sotto pressione di scadenza.
4. Assegna una chiara proprietà a livello di governance, non a livello di biglietto. I team che si muovono più velocemente sulla correzione non sono quelli con più sviluppatori. Sono quelli in cui il team di sicurezza possiede la politica, il team della piattaforma possiede la consegna e nessuno dei due aspetta che l’altro agisca.

La sicurezza che abilita piuttosto che blocca

C’è una credenza persistente che la sicurezza e la velocità di sviluppo siano in conflitto fondamentale. Non ho mai trovato che ciò sia vero quando la sicurezza è progettata nel processo piuttosto che aggiunta successivamente. Gli sviluppatori che lavorano da un set di componenti curato si muovono effettivamente più velocemente, perché non stanno più mettendo in dubbio le approvazioni, aspettando le revisioni di sicurezza o pulendo le vulnerabilità che potevano essere bloccate a monte.

Le organizzazioni che navigheranno lo sviluppo guidato dall’AI senza accumulare un debito di sicurezza insostenibile non sono quelle che eseguono più scanner. Sono quelle che hanno preso una decisione deliberata di governare ciò che entra nella loro catena di approvvigionamento di software prima che diventi un problema di risposta agli incidenti. Quella decisione appartiene alla leadership. Gli strumenti per eseguirla esistono oggi.