Cyber-JEV: come un modello open trova le funzioni di codice vulnerabili

Aggiornamento del 3 novembre 2026: tolti i riferimenti ad altri studi (decompilazione, avvelenamento degli strumenti) che non riguardavano Cyber-JEV, e le domande che ripetevano il testo.

Cyber-JEV è un metodo di addestramento descritto in un preprint pubblicato su arXiv, pensato per individuare le funzioni di codice vulnerabili. Un modello linguistico open-weight, cioè con i pesi liberamente disponibili, assegna a ogni funzione una probabilità di vulnerabilità senza produrre spiegazioni scritte.¹ Il problema che il metodo affronta è la scarsità di esempi vulnerabili con cui addestrare il modello. Gli autori lo aggirano trasformando i commit di correzione, le modifiche che hanno rimosso un difetto noto, in gruppi di confronto.¹

Che cosa fa un modello come Jev?

I modelli di punteggio a passaggio singolo, come Jev, ricevono una funzione di codice e restituiscono una probabilità che sia vulnerabile. In questo modo i team di sicurezza possono ordinare un gran numero di funzioni da rivedere, senza dover leggere una spiegazione generata per ciascuna.¹ Il paragone con Jev 1.13 è il riferimento principale del preprint. Anche Cyber-JEV, al momento dell’uso, prende in ingresso una sola funzione e produce un solo punteggio.¹

Perché mancano gli esempi su cui addestrare questi modelli?

Esistono due tipi di dati, e nessuno dei due basta da solo. I benchmark con etichette sia vulnerabili sia non vulnerabili, una volta eliminati gli esempi imparentati con quelli di test, conservano poche funzioni vulnerabili.¹ Le raccolte pubbliche di vulnerabilità più grandi contengono invece quasi solo funzioni vulnerabili. Unirle ai benchmark etichettati ha un effetto collaterale: la fonte del dato diventa un indizio sull’etichetta, e il modello può imparare a riconoscere la provenienza invece del difetto.¹ Addestrare soltanto sui dati etichettati non risolve la questione. Secondo gli autori, il modello che ne risulta spesso assegna a una funzione già corretta un punteggio più alto di quello della versione vulnerabile originale.¹

Come funziona il metodo di Cyber-JEV?

Il metodo parte dai commit di correzione. Ogni gruppo di confronto contiene la funzione vulnerabile, la sua versione corretta e fino a due funzioni non modificate prese dallo stesso file. Il modello vede così la modifica che ha eliminato un difetto registrato.¹ Un unico modello impara due compiti. Il primo è classificare le funzioni a partire dai dati di riferimento etichettati. Il secondo è mettere la funzione vulnerabile al di sopra degli altri membri del suo gruppo, compresa la versione corretta.¹ Il confronto serve a spostare l’attenzione dalla provenienza del dato alla differenza tra codice difettoso e codice sistemato. Le funzioni non modificate dello stesso file fanno da controllo, perché condividono contesto e stile con quella vulnerabile.¹ Il modello di base è Qwen3.5-4B. I risultati riportati si riferiscono a un insieme di cinque modelli messi a punto con questo metodo.¹

Che risultati dichiarano gli autori?

Su un benchmark di test di 7.270 funzioni, l’insieme di cinque modelli raggiunge un’area sotto la curva ROC di 0,814, contro lo 0,743 di Jev 1.13. L’area sotto la curva ROC è una misura di quanto bene un punteggio separa le funzioni vulnerabili dalle altre, e un valore più alto indica una separazione migliore.¹ Il confronto è stato fatto anche con un budget di revisione fisso, pari ai 4.031 avvisi generati da Jev. In quel caso Cyber-JEV lascia sfuggire 16 funzioni vulnerabili su 322, mentre Jev ne perde 39.¹ Rispetto all’addestramento sui soli dati di riferimento, il metodo colloca la versione vulnerabile sopra quella corretta più spesso, con uno scarto compreso tra 14,8 e 29,2 punti percentuali su tre insiemi di correzioni reali.¹ Si tratta di cifre dichiarate dagli autori nel preprint. Le fonti consultate non contengono una verifica indipendente, quindi vanno lette come risultati da confermare.¹

A che cosa può servire un punteggio di vulnerabilità?

Gli autori indicano un uso pratico: ordinare le funzioni modificate in una pull request o in una release, in modo da rivedere per prime quelle con il punteggio più alto entro un budget fisso di revisione.¹ Il punteggio non è una diagnosi. Segnala dove guardare per primo, ma non spiega la natura del difetto, perché il modello non genera testo esplicativo.¹

Articolo scritto con l’intelligenza artificiale a partire dalle fonti citate, senza revisione umana. Redazione automatica di Redazia.

Fonti

Footnotes

1. Cyber-JEV: Matched Contrastive Fine-Tuning of Language Models for Fast Source-Code Vulnerability Triage, arXiv: cs.CL, cs.LG, cs.CR, 2026-11-02 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷