AI-Driven SDLCSono già qui. L'IA non sta più arrivando. È già qui. Scrive codice nei nostri IDE. Sceglie le librerie. Apre pull requests. Esegue passaggi nel nostro pipelineLa questione non è più se gli sviluppatori utilizzeranno l'IA. La questione è come le organizzazioni manterranno visibilità, controllo e fiducia mentre la utilizzano.
Lo sviluppo software moderno è già entrato nell'era dell'intelligenza artificiale.
Nelle organizzazioni di ingegneria, gli sviluppatori utilizzano già copiloti, assistenti alla programmazione, IDE basati sull'intelligenza artificiale, agenti interni, strumenti connessi a MCP e flussi di lavoro sempre più autonomi come parte integrante delle operazioni di sviluppo quotidiane. Ciò che è iniziato come sperimentazione si è rapidamente integrato nel ciclo di vita stesso dello sviluppo del software. Questo è stato il tema centrale dell'ultimo SafeDev Talk ospitato da Xygeni: “AI-Driven SDLCSono già qui. E adesso?".
La sessione ha riunito Sam StepanyanMembro del consiglio di amministrazione globale di OWASP e responsabile della sezione londinese di OWASP; Ashwini Siddhi, membro del consiglio di amministrazione globale di OWASP e leader nella sicurezza informatica focalizzato sugli ambienti basati sull'intelligenza artificiale; e Gesù Cuadrado, CEO di Xygeni, moderato da Luis Rodriguez, Ricercatore presso Xygeni.
E da tutta la discussione è emerso un messaggio chiaro: il dibattito sulla sicurezza delle applicazioni è cambiato radicalmente. I team di sicurezza non si stanno più preparando all'adozione dell'IA nello sviluppo del software. Ci hanno già a che fare.
Punti chiave per l'IA SDLCs
- L'IA è già integrata nei sistemi moderni SDLCattraverso copiloti, assistenti alla programmazione, agenti autonomi e strumenti di sviluppo basati sull'intelligenza artificiale.
- I modelli tradizionali di sicurezza delle applicazioni non sono stati progettati per codice generato dall'IA, dipendenze fittizie, flussi di lavoro autonomi o sviluppo alla velocità delle macchine.
- L'IA ombra sta diventando una sfida importante in termini di visibilità e governance per CISTeam di sistemi operativi e sicurezza delle applicazioni.
- Lo sviluppo assistito dall'IA introduce nuove superfici di attacco, tra cui l'iniezione di prompt, le dipendenze dannose, l'abuso di MCP e i flussi di lavoro agentici.
- Le organizzazioni necessitano di modelli di governance basati sull'intelligenza artificiale, incentrati su visibilità, attribuzione, principio del minimo privilegio e verifica continua.
- Il settore si sta rapidamente orientando verso l'agenzia SDLCdove i sistemi di intelligenza artificiale eseguono attivamente operazioni di sviluppo.
Guarda la sessione completa di SafeDev Talk: AI-Driven SDLCsono già qui
Di seguito sono riportati alcuni dei principali spunti discussi durante la sessione, tra cui come l'IA sta rimodellando il modello di minaccia della sicurezza delle applicazioni e perché CISI sistemi operativi stanno perdendo visibilità negli ambienti di sviluppo, e quali controlli pratici le organizzazioni dovrebbero privilegiare per primi?
Perché AI-Driven SDLC La sicurezza è una questione importante in questo momento.
L'adozione dell'intelligenza artificiale nello sviluppo software sta accelerando più rapidamente di quanto la maggior parte dei programmi di governance riesca ad adattarsi. Man mano che le organizzazioni passano dai copiloti ad agenti sempre più autonomi, SDLC sta diventando sempre più guidato dalle macchine, dinamico e difficile da monitorare utilizzando gli approcci tradizionali di sicurezza delle applicazioni.
Per molti CISPer i responsabili dei sistemi operativi e della sicurezza delle applicazioni, la sfida non è più se l'IA entrerà negli ambienti di sviluppo, ma come mantenere la visibilità, l'attribuzione e il controllo operativo una volta che vi è già entrata.
Questo cambiamento sta già costringendo le organizzazioni a ripensare software supply chain securitymodelli di governance, visibilità degli sviluppatori e ruolo della fiducia negli ambienti di sviluppo software moderni.
L'adozione dell'IA sta procedendo più rapidamente della governance della sicurezza.
Uno dei temi più forti emersi durante la conversazione è stata la velocità. Come ha spiegato Luis Rodriguez all'inizio, l'IA non è più limitata alla sperimentazione o a strumenti di produttività isolati. Partecipa già direttamente ai flussi di lavoro di sviluppo: scrivendo codice, selezionando librerie, interagendo con pipelinee operando sempre più spesso all'interno dell'infrastruttura software stessa.
Ciò che ha sorpreso maggiormente i relatori non è stata l'esistenza dell'adozione dell'IA, bensì la sua diffusione già evidente, spesso senza visibilità o governance formali. Sam Stepanyan ha descritto una crescente discrepanza tra le politiche di sicurezza ufficiali e ciò che accade realmente all'interno dei team di ingegneri, soprattutto nei settori regolamentati. Alcune organizzazioni affermano ancora di "non utilizzare l'IA", mentre gli sviluppatori stanno già integrando copiloti, assistenti e strumenti di IA nei loro flussi di lavoro quotidiani.
Allo stesso tempo, ha sottolineato una realtà che molte organizzazioni faticano ancora ad accettare: anche le aziende che cercano di evitare l'adozione dell'IA si trovano comunque ad affrontare avversari che la utilizzano già in modo aggressivo. Questa tensione sta creando ciò che molti esperti di sicurezza descrivono ora come IA ombra all'interno degli ambienti di sviluppo software, ovvero sistemi di IA che operano al di fuori dei modelli di governance stabiliti.
Ashwini Siddhi ha aggiunto un'altra importante prospettiva. Ciò che la preoccupa non è semplicemente la velocità di adozione in sé, ma la mancanza di igiene operativa che circonda il codice generato dall'IA. Durante la discussione, ha sottolineato come le organizzazioni spesso non abbiano un'attribuzione affidabile su dove l'IA abbia contribuito, perché abbia generato un codice specifico o come quei decisGli ioni dovrebbero essere successivamente rivisti e convalidati. L'implicazione è significativa: i team di sviluppo stanno introducendo contributori non umani nel SDLCma la maggior parte dei modelli di governance e di revisione presuppongono ancora esclusivamente la paternità umana.
L'IA non si limita ad accelerare lo sviluppo. Cambia il modo in cui il rischio entra nel SDLC
Con l'integrazione dell'IA nei flussi di lavoro di sviluppo software, la superficie di attacco si espande ben oltre i tradizionali presupposti della sicurezza delle applicazioni. Il panel è tornato più volte su un concetto centrale: la maggior parte dei programmi di sicurezza è stata progettata attorno a rischi noti operanti alla velocità umana. L'IA cambia entrambe le condizioni simultaneamente.
I team di sicurezza non si limitano più a esaminare solo il codice scritto da esseri umani. Si trovano sempre più spesso a gestire dipendenze generate dall'IA, rischi di iniezione di prompt, flussi di lavoro autonomi, strumenti connessi a MCP, plugin di IA e velocità di elaborazione. CI/CD esecuzione.
Ashwini Siddhi ha spiegato che uno dei primi concetti a vacillare è proprio quello tradizionale di confine di fiducia. I sistemi di intelligenza artificiale vengono addestrati su enormi quantità di codice pubblico, gran parte del quale insicuro, obsoleto o impossibile da verificare completamente. Di conseguenza, le organizzazioni perdono la capacità di definire chiaramente cosa rientra o meno nei confini di fiducia.
Ha inoltre sottolineato che l'IA cambia radicalmente la natura della modellazione delle minacce, poiché questi sistemi non sono statici. Le tradizionali verifiche di sicurezza puntuali non sono più adeguate in ambienti in cui i sistemi di IA si evolvono, si adattano e ottimizzano dinamicamente il proprio comportamento in modo continuo.
Jesus Cuadrado ha affrontato il problema dal punto di vista della catena di fornitura del software. Uno degli esempi più chiari discussi durante la sessione riguardava le dipendenze suggerite dall'intelligenza artificiale. Gli sviluppatori accettano sempre più spesso automaticamente i suggerimenti di pacchetti generati dall'IA, spesso con un processo di validazione minimo o nullo. Questo crea una via d'attacco completamente nuova.
Come discusso durante il panel, gli aggressori possono identificare nomi di pacchetti fittizi generati da modelli linguistici complessi, registrare tali pacchetti in repository pubblici e attendere che sviluppatori o agenti di intelligenza artificiale li installino automaticamente.
Ciò cambia radicalmente i presupposti alla base della tradizione SCA programmi. I team di sicurezza non si occupano più solo di dipendenze vulnerabili note. Si trovano sempre più spesso a dover gestire dipendenze che potrebbero essere comparse pochi minuti prima e contenere comportamenti dannosi specificamente progettati per flussi di lavoro assistiti dall'IA.
La discussione ha inoltre esplorato come gli attacchi stiano iniziando a prendere di mira superfici completamente nuove all'interno degli ambienti di sviluppo. L'iniezione di prompt nei commenti, i file di istruzioni avvelenati per gli agenti, le interazioni dannose con MCP e i flussi di lavoro di intelligenza artificiale manipolati stanno diventando vettori di attacco concreti. Il risultato è un modello di minaccia più ampio, più rapido e molto più dinamico rispetto a quello per cui erano stati originariamente progettati i programmi di sicurezza delle applicazioni tradizionali.
CISGli Os stanno perdendo visibilità attraverso il SDLC
La visibilità è diventata uno dei temi dominanti durante tutta la discussione. Come ha riassunto Luis Rodriguez durante la sessione, molti responsabili della sicurezza semplicemente non sanno quali strumenti di IA stanno usando i loro sviluppatori, quale codice generato dall'IA sta entrando nei repository o quali agenti stanno interagendo con pipelinee infrastrutture.
Il panel ha descritto questo fenomeno come l'evoluzione dell'IT ombra in IA ombra. Ma a differenza delle precedenti generazioni di strumenti non autorizzati, questi sistemi partecipano attivamente allo sviluppocisGenerano codice, selezionano le dipendenze, interagiscono con l'infrastruttura e, sempre più spesso, prendono decisioni operative per conto degli sviluppatori.
Sam Stepanyan ha evidenziato un'altra sfida cruciale: l'attribuzione. Con la crescente diffusione del codice generato dall'IA, le organizzazioni perdono la capacità di determinare con certezza chi (o cosa) ha prodotto una specifica azione.
Questa perdita di tracciabilità crea problemi sia a livello di governance che operativo. Se i team non sono in grado di distinguere in modo affidabile tra comportamento umano e comportamento generato dall'IA, la risposta agli incidenti, l'audit e la revisione della sicurezza diventano significativamente più complessi.
La discussione ha toccato anche la crescente tendenza a riporre eccessiva fiducia negli output generati dall'IA. Gli sviluppatori spesso presumono che, poiché il codice generato dall'IA appare affidabile e funzionale, debba essere anche sicuro. Ma, come ha sottolineato Sam, questi sistemi vengono spesso addestrati su esempi pubblici non sicuri e possono generare risultati vulnerabili o del tutto inesatti con elevata sicurezza. Ciò crea una combinazione pericolosa: visibilità limitata, attribuzione ridotta e crescente fiducia in sistemi che le organizzazioni non comprendono appieno.
Il settore si sta silenziosamente muovendo verso l'agenzia SDLCs
Una delle parti più importanti della discussione si è concentrata sulla transizione dai copiloti agli agenti autonomi. I relatori hanno concordato sul fatto che il settore si sta rapidamente muovendo verso ciò che può essere sempre più descritto come un agente SDLCambienti in cui i sistemi di intelligenza artificiale non si limitano più a suggerire codice, ma intraprendono azioni attive lungo tutto il ciclo di vita del software.
I sistemi di intelligenza artificiale stanno iniziando ad aprirsi pull requestsEseguire test, richiamare strumenti esterni, modificare l'infrastruttura, interagire con le API e operare autonomamente in diversi ambienti di sviluppo. In altre parole, l'IA si sta trasformando da assistente a operatore.
Questo cambiamento modifica radicalmente il modello di sicurezza. Come emerso durante la discussione, le organizzazioni avranno probabilmente bisogno di approcci di governance completamente nuovi, incentrati sull'identità degli agenti di IA, sull'accesso con privilegi minimi, sulla tracciabilità, sulla supervisione umana, sulle azioni firmate e sulla visibilità continua del comportamento dell'IA.
Un esempio particolarmente eclatante discusso durante la sessione riguardava un sistema di intelligenza artificiale che tentava di disabilitare le protezioni di sicurezza degli endpoint su una workstation di sviluppo per raggiungere l'obiettivo assegnato.
Questo esempio illustra un'importante realtà relativa agli ambienti basati sull'intelligenza artificiale: questi sistemi si ottimizzano per il raggiungimento degli obiettivi, non necessariamente per il rispetto dei limiti di sicurezza. La sicurezza delle applicazioni tradizionale si basava sul monitoraggio degli errori umani. La prossima generazione di sicurezza delle applicazioni dovrà sempre più governare i comportamenti autonomi.
Perché la sicurezza delle applicazioni basata sull'IA richiede un approccio Zero Trust
Molti dei temi discussi durante il SafeDev Talk si allineano strettamente con il più ampio cambiamento verso ciò che Xygeni lo definisce come Zero Trust per l'era dell'IA SDLC: non fidarti di nulla, verifica tutto, compresa l'intelligenza artificiale stessa. Come illustrato nell'approccio basato su piattaforme di Xygeni, l'intelligenza artificiale espande la superficie di attacco su più livelli contemporaneamente:
- codice di prima parte,
- dipendenze,
- CI/CD pipelines,
- Modelli e agenti di intelligenza artificiale,
- e ambienti di sviluppo.
Molte di queste aree rimangono in gran parte invisibili agli strumenti tradizionali di sicurezza delle applicazioni. La sfida non consiste più semplicemente nell'analizzare il codice alla ricerca di vulnerabilità. Le organizzazioni necessitano sempre più di visibilità sulle dipendenze generate dall'IA, sull'attività dell'IA negli ambienti di sviluppo, sul comportamento degli agenti, sull'infrastruttura connessa all'IA e sulle interazioni della catena di fornitura del software che avvengono alla velocità della macchina.
Ecco perché concetti come inventario IA, consapevolezza IA ASPML'intelligenza artificiale, la gestione avanzata dei processi software (AI-SPM) e la governance dell'ambiente di sviluppo stanno rapidamente diventando centrali nelle moderne discussioni sulla sicurezza delle applicazioni.
Migliori SDLC È già cambiato
Il SafeDev Talk ha chiarito un punto fondamentale: L'IA è già integrata nel SDLC. Nel settore non si discute più se lo sviluppo assistito dall'IA diventerà realtà. Questa transizione è già in atto nelle organizzazioni di ingegneria di ogni dimensione.
La vera sfida ora è mantenere la visibilità, la governance, l'attribuzione e il controllo operativo in ambienti di sviluppo sempre più autonomi.
Con l'accelerazione dell'adozione dell'IA, i presupposti tradizionali della sicurezza delle applicazioni relativi ai confini di fiducia, all'attribuzione della paternità umana, alla provenienza del software e ai modelli di governance statici continueranno a vacillare.
Le organizzazioni che si adatteranno più rapidamente non saranno necessariamente quelle che rallenteranno l'adozione dell'IA. Saranno piuttosto quelle in grado di comprendere, governare e proteggere lo sviluppo di software basato sull'IA alla velocità con cui questo sta già procedendo.
Continua la conversazione all'OWASP Global AppSec EU di Vienna.
La conversazione sull'IA guidata SDLC La sicurezza è solo all'inizio. Xygeni continuerà ad esplorare questi argomenti all'OWASP Global AppSec EU di Vienna, dove il team discuterà di AppSec consapevole dell'IA, software supply chain security, la governance dell'IA e i rischi emergenti degli ambienti di sviluppo agentivo.
Se stai partecipando OWASP Global AppSec EUVenite a incontrare il team di Xygeni allo stand G-08 di Vienna!
