Capital One ha reso disponibile VulnHunter, uno strumento open source basato sull’intelligenza artificiale e progettato per individuare nel codice sorgente le vulnerabilità che potrebbero essere realmente sfruttate da un attaccante. Il sistema ricostruisce il percorso necessario per raggiungere il difetto, verifica se le protezioni esistenti siano sufficienti a interrompere l’attacco e propone modifiche mirate al codice prima che il software venga distribuito negli ambienti di produzione. Lo strumento è stato inizialmente sviluppato per le attività interne di Capital One ed è ora disponibile su GitHub con licenza Apache 2.0. La licenza consente a sviluppatori, aziende e ricercatori di utilizzare, esaminare, modificare e integrare il progetto, favorendo la verifica pubblica dell’architettura e il contributo della comunità della sicurezza informatica.
VulnHunter nasce in una fase nella quale i modelli avanzati di intelligenza artificiale stanno riducendo sensibilmente le competenze, il tempo e le risorse necessari per individuare e sfruttare errori nel software. Capacità offensive che in precedenza richiedevano gruppi specializzati potrebbero diventare progressivamente accessibili anche ad attaccanti meno esperti, attraverso agenti capaci di analizzare automaticamente grandi quantità di codice e costruire possibili catene di sfruttamento. Secondo Chris Nims, responsabile della sicurezza informatica di Capital One, la finestra temporale disponibile prima che capacità di attacco di nuova generazione diventino alla portata di quasi qualsiasi avversario si sta restringendo. VulnHunter è stato quindi sviluppato per applicare preventivamente le stesse capacità di analisi e ragionamento in ambito difensivo, cercando e correggendo i difetti prima che possano essere scoperti dagli aggressori.
La caratteristica centrale dello strumento è un metodo definito da Capital One come analisi prospettica incentrata sull’attaccante. Il sistema non parte semplicemente da un’istruzione considerata pericolosa, ma dai punti attraverso i quali un soggetto esterno potrebbe effettivamente interagire con l’applicazione. Tra questi punti d’ingresso rientrano gli endpoint delle API, i messaggi di rete, le richieste ricevute dall’applicazione e le interfacce per il caricamento dei file. Da ogni ingresso, VulnHunter segue il percorso dei dati all’interno del software, osservando le trasformazioni, le funzioni richiamate e i controlli di sicurezza incontrati.
L’obiettivo è determinare se un dato controllato dall’attaccante possa realmente raggiungere una funzione sensibile e produrre un effetto dannoso. Il procedimento riproduce il metodo utilizzato da un penetration tester esperto, ma lo applica automaticamente a quantità di codice e repository difficilmente analizzabili con la stessa continuità da un gruppo umano. Gli scanner tradizionali di sicurezza adottano spesso un’impostazione opposta. Individuano innanzitutto una funzione o una configurazione associata a un rischio e cercano successivamente di ricostruire a ritroso un possibile collegamento con un input esterno. Questo approccio può segnalare come vulnerabili anche parti di codice che non sono accessibili a un aggressore, che ricevono esclusivamente dati già controllati o che sono protette da condizioni non riconosciute dallo scanner. Il risultato è spesso un numero molto elevato di falsi positivi che deve essere esaminato manualmente dai team di sicurezza e di sviluppo.
L’accumulo di segnalazioni non confermate può rallentare il ciclo di rilascio del software e ridurre la fiducia negli strumenti automatici. Gli sviluppatori finiscono per dedicare tempo alla verifica di problemi teorici che non corrispondono a percorsi di attacco realmente utilizzabili, rischiando contemporaneamente di trascurare le vulnerabilità più importanti. VulnHunter affronta il problema attraverso un motore di falsificazione integrato. Quando il sistema individua una possibile vulnerabilità, non la presenta immediatamente agli sviluppatori, ma avvia un secondo processo incaricato di contestare e, quando possibile, confutare la scoperta. Il motore ricerca ipotesi non dimostrate, passaggi mancanti nella catena di sfruttamento, errori logici e condizioni ambientali che impedirebbero all’attacco di avere successo. Verifica inoltre se il percorso presupponga privilegi che un aggressore esterno non possiede o se ignori controlli già presenti nel codice. Le scoperte che non superano questa verifica vengono eliminate prima di raggiungere il revisore umano. Solo le vulnerabilità che il sistema non riesce a escludere vengono inserite nel rapporto finale.
Il procedimento non mira quindi a massimizzare il numero delle segnalazioni, ma a produrre un insieme più ristretto di problemi accompagnati da prove contestuali. La presenza di un comportamento potenzialmente rischioso non è sufficiente: VulnHunter cerca di dimostrare che esista un percorso completo attraverso il quale l’attaccante possa raggiungerlo e sfruttarlo. Per ogni vulnerabilità confermata, il sistema raccoglie elementi di prova presenti nelle diverse parti del codice sorgente. Ricostruisce il punto d’ingresso, i flussi di dati, le trasformazioni subite dall’input, i controlli incontrati e la funzione finale attraverso la quale potrebbe essere provocato il danno. Il rapporto descrive anche il difetto logico o implementativo che rende possibile lo sfruttamento e le capacità che l’attaccante potrebbe ottenere. L’impatto può riguardare, per esempio, l’accesso a informazioni riservate, l’esecuzione di operazioni non autorizzate, la modifica di dati o l’alterazione del comportamento dell’applicazione. Alla spiegazione viene affiancata una proposta concreta di correzione. VulnHunter genera modifiche mirate al codice e le presenta al team di ingegneri per la revisione, evitando di limitarsi a un avviso generico o al semplice riferimento a una categoria di vulnerabilità.
L’architettura operativa dello strumento è articolata in tre fasi. La prima consiste nell’analisi in avanti a partire dalla superficie di attacco. VulnHunter identifica gli ingressi accessibili dall’esterno e segue la logica applicativa per stabilire se i dati possano raggiungere istruzioni pericolose. La seconda fase coincide con il motore di falsificazione. Ogni possibile percorso viene sottoposto a un processo di ragionamento strutturato che tenta di dimostrare l’inesistenza o l’impraticabilità dell’attacco. Le ipotesi che non resistono al controllo vengono scartate. Nella terza fase, le vulnerabilità rimaste attivano il flusso di correzione basato sulle prove. Il sistema raccoglie le informazioni distribuite nel repository, descrive l’intera catena di sfruttamento e genera una proposta di modifica contestualizzata.
VulnHunter utilizza attualmente il modello Claude Opus 4.8 di Anthropic all’interno dell’ambiente Claude Code. Capital One ha tuttavia progettato il framework con la possibilità di supportare in futuro altri modelli fondamentali e differenti ambienti di programmazione. L’efficacia dello strumento dipende quindi sia dalla struttura sviluppata da Capital One sia dalle capacità del modello utilizzato per interpretare il codice, collegare funzioni distanti tra loro e ragionare sulle condizioni necessarie per lo sfruttamento. Prima della pubblicazione, Capital One ha testato VulnHunter internamente su migliaia di repository appartenenti a decine di aree aziendali. Secondo l’azienda, il sistema è riuscito a identificare e risolvere vulnerabilità con una velocità e un’efficienza significativamente superiori rispetto alla valutazione manuale precedentemente eseguita dai team interni. Queste indicazioni derivano tuttavia dalla validazione effettuata dalla stessa organizzazione che ha sviluppato lo strumento. Le prestazioni in contesti esterni dipenderanno dalla varietà dei linguaggi, dei framework, delle architetture applicative e delle pratiche di sviluppo sulle quali VulnHunter verrà utilizzato.
L’apertura del codice permetterà alla comunità di verificare con maggiore precisione la capacità dello strumento di individuare vulnerabilità sconosciute, il numero dei falsi positivi, il rischio di falsi negativi e la qualità delle correzioni proposte. Capital One ha deciso di distribuire pubblicamente VulnHunter perché considera la sicurezza delle moderne catene di fornitura del software un problema collettivo. Le applicazioni aziendali utilizzano componenti, librerie e framework condivisi, per cui un difetto presente in un progetto ampiamente adottato può propagarsi simultaneamente verso migliaia di organizzazioni. Una difesa proprietaria può proteggere una singola infrastruttura, ma non elimina la vulnerabilità dal componente comune da cui dipendono altre aziende. La pubblicazione con una licenza permissiva consente invece a ricercatori e sviluppatori di testare lo strumento, ampliarlo e contribuire al miglioramento di una risorsa utilizzabile nell’intero ecosistema.
Secondo Chris Nims, gli strumenti difensivi devono essere distribuiti, testati e perfezionati con la stessa ampiezza dei codebase che devono proteggere. Capital One ha quindi scelto di non attendere la diffusione generalizzata degli strumenti offensivi basati sull’intelligenza artificiale, ma di mettere preventivamente a disposizione dei difensori una tecnologia sviluppata per questo nuovo scenario. La scelta assume un significato particolare considerando la storia recente della stessa Capital One. Il 19 luglio 2019 l’azienda rese pubblica una grave violazione dei dati avvenuta il 22 e il 23 marzo dello stesso anno. Un soggetto esterno, ex dipendente di Amazon Web Services, aveva ottenuto un accesso non autorizzato ai dati di clienti e richiedenti di carte di credito. Le informazioni compromesse comprendevano nomi, indirizzi, redditi autodichiarati, numeri di previdenza sociale e numeri di conti correnti bancari collegati. La violazione interessò circa 100 milioni di persone negli Stati Uniti e 6 milioni di persone in Canada. Tra i dati coinvolti figuravano circa 140.000 numeri di previdenza sociale statunitensi, approssimativamente 80.000 numeri di conto corrente bancario collegati e circa un milione di numeri di assicurazione sociale canadesi.
Capital One individuò l’accaduto soltanto dopo la segnalazione ricevuta il 17 luglio 2019 da un ricercatore esterno attraverso il programma aziendale di divulgazione responsabile delle vulnerabilità. L’FBI arrestò il colpevole e le autorità dichiararono di ritenere che i dati fossero stati recuperati senza trovare prove di frodi commesse attraverso le informazioni sottratte. Le conseguenze normative e reputazionali furono comunque rilevanti. Nell’agosto 2020, l’Office of the Comptroller of the Currency impose a Capital One una sanzione di 80 milioni di dollari. L’autorità contestò all’azienda di non avere identificato e gestito adeguatamente i rischi durante la migrazione di importanti operazioni tecnologiche verso il cloud.
Il provvedimento richiamò carenze nei controlli di sicurezza della rete, misure insufficienti per la prevenzione della perdita dei dati e l’assenza di un’adeguata responsabilizzazione del management dopo che verifiche interne avevano già evidenziato alcuni problemi. Capital One dovette inoltre riesaminare le proprie operazioni e presentare nuovi piani di sicurezza informatica alle autorità di controllo. La violazione venne considerata un avvertimento per le aziende impegnate in una rapida adozione di nuove infrastrutture tecnologiche. Il presidente e amministratore delegato di Capital One, Richard D. Fairbank, espresse pubblicamente il proprio dispiacere per l’incidente e si impegnò a porre rimedio alle conseguenze.
Dopo la violazione, Capital One non interruppe il percorso di trasformazione tecnologica e di migrazione verso il cloud, ma rafforzò gli investimenti nella sicurezza e nella governance del software. Il rapporto dell’azienda con l’open source era comunque iniziato prima dell’incidente. Capital One aveva cominciato a pubblicare progetti nel 2014 e nel 2015 aveva dichiarato di adottare una strategia “open source first”, inserita in una trasformazione tecnologica avviata diversi anni prima. Nel tempo l’azienda ha investito nella sicurezza della catena di fornitura software, nella gestione dei componenti open source e nell’applicazione dell’intelligenza artificiale alle attività difensive. Nell’agosto 2022 Capital One è entrata nella Open Source Security Foundation come membro di primo piano, ottenendo un posto nel consiglio direttivo dell’organizzazione. La partecipazione è stata presentata come un’estensione della propria esperienza in materia di conformità, governance, standardizzazione e automazione.
L’Open Source Program Office di Capital One gestisce oggi l’utilizzo dei componenti aperti, i contributi ai progetti esterni e la creazione di comunità tecniche all’interno dell’azienda. Secondo i dati dichiarati dalla società, sono stati pubblicati oltre 40 progetti open source e sono stati effettuati migliaia di contributi a iniziative esterne dalle quali dipendono i sistemi aziendali. Le attività non riguardano soltanto le librerie incorporate nel software, ma l’intero ciclo di sviluppo. Comprendono strumenti DevSecOps, infrastrutture, procedure di governance e ambienti collaborativi che influenzano il modo in cui le applicazioni vengono progettate, controllate e distribuite.
VulnHunter rappresenta uno dei risultati più significativi di questo percorso. La pubblicazione dello strumento mostra che Capital One considera la collaborazione open source non soltanto una forma di condivisione tecnologica, ma una strategia per ampliare la capacità difensiva dell’azienda stessa. Consentire alla comunità internazionale della sicurezza di esaminare e migliorare VulnHunter può infatti produrre un’infrastruttura difensiva sviluppata attraverso contributi distribuiti. Le correzioni, le estensioni e i test svolti da soggetti esterni possono rafforzare lo strumento e, indirettamente, le organizzazioni che lo utilizzano.
La sicurezza del software è diventata particolarmente importante nel settore finanziario, nel quale la migrazione verso il cloud ha modificato profondamente l’architettura dei sistemi. Quando Capital One iniziò a trasferire le proprie attività su Amazon Web Services, a metà degli anni Dieci, molte grandi banche erano ancora riluttanti ad affidare a fornitori esterni l’infrastruttura destinata ai dati più sensibili. L’allora responsabile informatico di Capital One, Rob Alexander, sostenne pubblicamente che il cloud potesse essere più sicuro dei data center gestiti direttamente dalla banca. La violazione del 2019 mostrò però che l’adozione di un’infrastruttura tecnicamente avanzata non elimina i rischi derivanti da configurazioni errate, controlli insufficienti e debolezze nei processi di sviluppo. Il problema non consiste quindi soltanto nella sicurezza intrinseca della piattaforma cloud, ma nel modo in cui applicazioni, permessi, reti e procedure vengono progettati e gestiti sopra quell’infrastruttura.
Nel settore bancario si è progressivamente affermata una cultura maggiormente orientata agli sviluppatori, all’automazione e alla trasformazione delle infrastrutture in codice. Questo approccio aumenta la velocità con cui i sistemi possono essere creati e aggiornati, ma rende anche necessario integrare i controlli di sicurezza direttamente nel processo di sviluppo. Difese perimetrali, monitoraggio delle reti e risposta agli incidenti rimangono indispensabili, ma intervengono spesso quando il software è già stato distribuito. VulnHunter cerca invece di spostare il controllo in una fase precedente, analizzando il codice nel momento in cui viene scritto e prima che le vulnerabilità raggiungano gli ambienti utilizzati dai clienti. La necessità di anticipare la difesa è rafforzata dalla diffusione dell’intelligenza artificiale offensiva. Agenti automatici possono esaminare repository, individuare funzioni sensibili, provare varianti di attacco e collegare rapidamente difetti che un analista umano dovrebbe studiare separatamente. L’analisi reattiva delle vulnerabilità conosciute potrebbe non essere più sufficiente quando gli aggressori possono utilizzare l’intelligenza artificiale per trovare errori non ancora catalogati e costruire exploit con velocità vicine a quelle delle macchine.
Capital One sostiene quindi che una difesa duratura debba concentrarsi sull’individuazione e sulla correzione preventiva dei difetti nel codice. Lo strumento tenta di utilizzare il ragionamento dell’intelligenza artificiale prima dell’attaccante, trasformando il codice sorgente in un ambiente sul quale simulare possibili percorsi offensivi. Il progetto si collega anche alle ricerche condotte dal gruppo di Capital One dedicato alla sicurezza dell’intelligenza artificiale. Durante NeurIPS 2024 a Vancouver, il team ha presentato proprie attività e selezionato quasi cento studi riguardanti, tra gli altri argomenti, la sicurezza dei grandi modelli linguistici, la resistenza agli attacchi avversari, i jailbreak, il red teaming automatizzato e la produzione di dati sintetici.
lcuni di questi temi presentano analogie con la struttura di VulnHunter. Il motore di falsificazione applica una logica avversariale, nella quale un processo separato tenta di smontare le conclusioni generate durante la prima analisi. Questa impostazione richiama i sistemi di difesa multi-agente e i metodi nei quali un modello o un meccanismo di controllo viene incaricato di cercare errori, comportamenti pericolosi e violazioni nelle conclusioni di un altro componente. Il progetto BackdoorAlign ha studiato la possibilità di integrare un meccanismo strutturato di sicurezza in una quantità limitata di esempi di addestramento, con l’obiettivo di ripristinare l’allineamento di un modello compromesso senza ridurne le prestazioni generali. WildTeaming ha invece raccolto e analizzato tentativi reali di jailbreak per migliorare la resilienza dei modelli. L’approccio basato sull’osservazione delle tecniche utilizzate dagli aggressori presenta una logica simile all’analisi di VulnHunter, che parte dal comportamento plausibile dell’attaccante invece di limitarsi a cercare schemi astratti. GuardFormer si è concentrato sulla classificazione automatica dei contenuti pericolosi e, nei benchmark indicati, ha superato GPT-4 nelle attività di sicurezza operando con una velocità quattordici volte superiore. L’obiettivo di produrre controlli più rapidi e ridurre le segnalazioni improprie è collegabile alla scelta di VulnHunter di filtrare preventivamente i falsi positivi. Questi riferimenti mostrano un’evoluzione della sicurezza basata sull’intelligenza artificiale verso sistemi che non si limitano a generare una risposta, ma mettono in competizione più processi di analisi. Un agente formula l’ipotesi di vulnerabilità, mentre un secondo processo tenta di confutarla prima che la conclusione venga accettata.
Il rilascio di VulnHunter può produrre conseguenze anche sul mercato degli strumenti aziendali di sicurezza. Se la piattaforma verrà adottata su larga scala e dimostrerà prestazioni affidabili, potrebbe contribuire a modificare le aspettative nei confronti degli scanner utilizzati da banche, società finanziarie, aziende tecnologiche e fornitori di servizi cloud. Gli strumenti potrebbero essere valutati non più soltanto in base al numero di difetti potenziali individuati, ma alla capacità di ricostruire un percorso sfruttabile, eliminare autonomamente i falsi positivi e proporre una modifica pronta per la revisione. Una simile evoluzione aumenterebbe la pressione sui fornitori concorrenti affinché integrino analisi agentiche, ragionamento avversariale e correzione automatizzata nelle proprie piattaforme. Il successo di VulnHunter dipenderà comunque dalle prestazioni ottenute su progetti reali, dall’adozione da parte degli sviluppatori e dalla capacità della comunità di mantenerlo aggiornato rispetto all’evoluzione dei linguaggi, dei framework e delle tecniche di attacco.
Dovrà inoltre essere verificato quanto il modello riesca a comprendere applicazioni molto estese, architetture distribuite e percorsi che attraversano diversi repository o servizi. L’analisi del solo codice sorgente potrebbe non comprendere condizioni presenti nell’infrastruttura, nei sistemi di autenticazione esterni, nelle configurazioni cloud o nei dati disponibili esclusivamente durante l’esecuzione. Le correzioni generate dall’intelligenza artificiale devono essere sottoposte a revisione tecnica. Una modifica può eliminare il percorso di attacco individuato, ma introdurre regressioni, alterare il funzionamento dell’applicazione o non considerare altri modi attraverso i quali lo stesso difetto potrebbe essere sfruttato. VulnHunter deve quindi essere interpretato come uno strumento di supporto avanzato, non come una garanzia automatica di sicurezza. La riduzione dei falsi positivi e la generazione delle patch possono velocizzare il lavoro, ma non sostituiscono i test dinamici, le verifiche dell’infrastruttura, la revisione del codice e l’attività dei professionisti della sicurezza.