Contesto: IA, sviluppo software e aumento delle vulnerabilità
La Cloud Security Alliance segnala che lo sviluppo assistito dall'intelligenza artificiale sta superando i tradizionali workflow di sicurezza applicativa. Parallelamente, il Gruppo di esperti cyber del G7 avverte che l'IA consente agli aggressori di sondare i sistemi più rapidamente, su scala più ampia e con minori competenze.
Le segnalazioni di vulnerabilità (CVE) al National Vulnerability Database sono cresciute del 263 % tra il 2020 e il 2025, secondo il National Institute of Standards and Technology. Nel frattempo il FBI, nel suo Internet Crime Report 2025, registra quasi 21 miliardi di dollari di perdite per crimini online.
Per i leader aziendali la sfida è sia operativa che finanziaria: i team di sicurezza devono identificare e dare priorità alle vulnerabilità sfruttabili più velocemente, senza aumentare i costi di revisione manuale né esporre i sistemi critici a interruzioni.
Nel contesto di una serie di interviste al Emerj AI in Business Podcast, Niroshan Rajadurai (Chief Revenue Officer di XBOW) e Sridhar Boddula (Head of Security Platform Engineering di MassMutual) illustrano come le imprese possano adeguare le proprie operazioni di sicurezza a queste pressioni.
Strategia 1: Validazione degli exploit per priorizzare le vulnerabilità
Rajadurai, durante la sua esperienza in GitHub, ha indagato se i modelli di IA potessero risolvere vulnerabilità di codice senza introdurre nuovi rischi. Con l'aumento del codice da revisionare, le squadre di sicurezza devono distinguere i falsi positivi da vulnerabilità reali e capire quali di esse siano realmente sfruttabili.
“Quando pensiamo a una vulnerabilità di sicurezza, ci sono in realtà due parti. Una è la vulnerabilità originale… Ma la seconda parte è: quel bug è davvero raggiungibile da qualcuno che vuole fare del male?” – Niroshan Rajadurio.
Dimostrare la sfruttabilità di una vulnerabilità ne determina la priorità. Un exploit può consentire a un attaccante di estrarre dati sensibili, eseguire comandi sul sistema o accedere ad altre parti della rete.
Un fallimento nel dimostrare l'exploit non significa che l'attacco sia impossibile; la valutazione deve comunque considerare esposizione, criticità dell'asset e potenziali conseguenze.
Boddula sottolinea l'importanza di allineare la priorità delle vulnerabilità alla criticità dei sistemi coinvolti e all'impatto sul business. In un e‑commerce, una falla che colpisce l'infrastruttura di acquisto avrà priorità più alta rispetto a una vulnerabilità su un sistema interno non esposto al web.
Quadro a quattro passi per la priorità
- Accessibilità dell'attaccante: valutare percorsi di accesso diretti e indiretti; un'esposizione limitata può ridurre la priorità.
- Dimostrazione dell'exploit: un exploit convalidato rafforza la necessità di rimedio urgente; un test fallito non garantisce sicurezza.
- Impatto potenziale: considerare dati regolamentati, servizi critici per il fatturato, privilegi e possibilità di movimento laterale.
- Conferma della correzione: retestare l'applicazione dopo la mitigazione, includendo varianti dell'exploit originale per verificare l'efficacia.
L'ultimo passo è cruciale per evitare “fix naïf”. Rajadurai cita un caso in cui un filtro WAF bloccava un URL maligno, ma l'attaccante ha eluso il filtro usando la codifica percentuale, dimostrando la necessità di test approfonditi.
Per misurare l'impatto operativo dei test autonomi, i leader possono monitorare tre KPI:
- Ore di analista dedicate alla validazione dei risultati.
- Tempo dalla scoperta della vulnerabilità alla verifica della correzione.
- Percentuale di applicazioni ad alta priorità valutate entro un ciclo di test definito.
Questi indicatori mostrano se i test autonomi migliorano la copertura di sicurezza e l'efficienza di remediation senza aumentare proporzionalmente i costi del personale.
Strategia 2: Governance integrata per il controllo dei test autonomi
Rajadurio osserva che se un modello genera codice a 200 miglia all'ora e un revisore umano lo controlla a 10 miglia, il revisore diventa un collo di bottiglia insostenibile per la pipeline. Richiedere l'approvazione umana a ogni fase può ritardare i test, soprattutto fuori dall'orario di lavoro.
Rimuovere le approvazioni manuali routine richiede che i tester autonomi operino entro confini di sicurezza definiti, soprattutto quando si valutano sistemi di produzione dove azioni distruttive possono interrompere le operazioni o compromettere i dati.
“Un hacker esperto direbbe ‘Non farlo’, perché se è un sistema di produzione potresti cancellare tutti i dati. Un modello, invece, potrebbe pensare ‘Ho trovato un’iniezione SQL, la eseguo’.” – Niroshan Rajadurio.
Per questo, è necessario implementare:
- Obiettivi di test autorizzati: definire esplicitamente quali sistemi, endpoint e componenti possono essere esaminati.
- Divieti di azioni distruttive: impostare regole che impediscano al modello di eseguire operazioni di tipo drop, delete o altre azioni potenzialmente dannose.
- Requisiti di audit: registrare ogni azione del modello, con log dettagliati, per garantire tracciabilità e possibilità di revisione.
- Meccanismi di emergenza: capacità di interrompere automaticamente il test al rilevamento di comportamenti anomali o di rischio elevato.
Queste misure consentono ai test di sicurezza di operare in modo continuo e autonomo, riducendo la dipendenza dall'intervento umano senza compromettere la sicurezza operativa.
Strategia 3: Test mirati dei sistemi critici per guidare gli investimenti
Il terzo approccio consiste nel focalizzare le risorse di test sui sistemi che trattano dati sensibili o regolamentati. Identificando le applicazioni che contengono informazioni critiche, le organizzazioni possono condurre valutazioni autorizzate su questi asset ad alta priorità.
Le fasi consigliate includono:
- Inventario dei dati sensibili: mappare dove risiedono dati personali, finanziari o di salute.
- Classificazione delle applicazioni: etichettare le app in base a criticità, esposizione e valore per il business.
- Esecuzione di test autorizzati: utilizzare strumenti di testing autonomo su questi sistemi, rispettando le policy di governance.
- Analisi dei risultati: tradurre le scoperte in raccomandazioni concrete per la mitigazione e per future decisioni di investimento.
Questo approccio consente di indirizzare il budget di sicurezza verso le aree più a rischio, migliorando il ritorno sull'investimento e riducendo la superficie di attacco complessiva.
Esempio pratico di implementazione
Un'azienda finanziaria ha identificato tre applicazioni chiave che gestiscono dati di carte di credito. Dopo aver definito i target di test, ha avviato una scansione automatica con un modello di IA certificato, limitando le azioni a solo rilevamento di vulnerabilità senza exploit attivi. I risultati hanno evidenziato due vulnerabilità di tipo SQL injection, che sono state immediatamente corrette e successivamente verificate con un retest autonomo.
Grazie a questo processo, l'azienda ha ridotto il tempo medio di remediation da 45 a 12 giorni e ha dimostrato conformità alle normative PCI‑DSS.
Conclusioni e prospettive future
L'adozione di test di sicurezza autonomi, supportati da IA, rappresenta una risposta necessaria alla crescente velocità e volume delle vulnerabilità generate dallo sviluppo assistito dall'IA. Tuttavia, il successo dipende da una governance chiara, da una validazione continua degli exploit e da un focus mirato sui sistemi più critici.
Le metriche operative presentate – ore di analista, tempo di remediation e copertura delle applicazioni – forniscono un quadro di riferimento per valutare l'efficacia dei programmi di testing autonomi. In un contesto in cui le perdite per crimini informatici superano i 20 miliardi di dollari, le imprese che adottano queste strategie saranno meglio preparate a gestire le minacce di nuova generazione.
Per approfondire, è possibile ascoltare gli episodi del podcast Emerj AI in Business, dove Niroshan Rajadurai e Sridhar Boddula approfondiscono ulteriormente le loro esperienze e consigli pratici.