Uno stesso strumento che porta un modello linguistico dal 20% al 100% di accuratezza su dati sintetici può farlo crollare al 48,9% non appena incontra vulnerabilità reali. È questo il paradosso al centro di una nuova ricerca di Manuel Israel Cázares, depositata su arXiv il 16 luglio 2026, che mette alla prova l’iniezione di prior strutturali nel rilevamento di vulnerabilità nel codice sorgente — e trova esattamente il pattern già osservato nel ragionamento matematico formale.
Summary
Punti chiave
- I prior strutturali (cheatsheet) migliorano il recall sulle vulnerabilità semantiche dal 20% al 100% su tutti e tre i modelli testati in contesti sintetici.
- Le stesse cheatsheet amplificano il crollo fuori distribuzione: su dati CVE reali (VUDENC), l’F1 per CWE-89 scende dal 100% al 48,9%, un calo di 51,1 punti percentuali.
- La ricalibrazione iterativa peggiora ulteriormente le cose: la cheatsheet v2 ottiene risultati inferiori alla v1 sui dati reali.
- I modelli testati sono GPT-OSS-120B, Llama-3.3-70B e Gemma-4-31B.
- Lo studio suggerisce l’addestramento distribuzione-consapevole come alternativa strutturalmente più solida rispetto alla calibrazione dei prompt.
I prior strutturali migliorano il rilevamento sintetico di vulnerabilità
La premessa è semplice: i grandi modelli linguistici sanno spesso come risolvere un problema, ma non attivano in modo affidabile quella conoscenza. L’ipotesi del router — già documentata nella ricerca SAIR di Cázares — descrive esattamente questa frattura tra capacità latente e attivazione consistente. La domanda di questo studio è se il fenomeno si riproduca anche nel dominio della sicurezza del codice.
La risposta è sì, e i numeri lo confermano con precisione.
Incremento delle performance nei modelli testati
Iniettando cheatsheet strutturate nei prompt — i cosiddetti prior strutturali — i tre modelli valutati mostrano un salto netto nelle prestazioni su dataset sintetici. Il recall sulle vulnerabilità semantiche passa dal 20% al 100% in modo uniforme su GPT-OSS-120B, Llama-3.3-70B e Gemma-4-31B. Non si tratta di un miglioramento marginale: è una saturazione completa delle metriche in-distribution.
Questo risultato replica e amplia quanto già osservato da SAIR nel ragionamento matematico, confermando che il meccanismo di prior injection funziona in modo trasversale ai domini — almeno finché ci si muove all’interno della distribuzione di addestramento.
Categorie e complessità delle vulnerabilità
Lo studio copre tre categorie di vulnerabilità: CWE-798 (credenziali hardcoded, complessità sintattica), CWE-284 (controllo accessi, complessità contestuale) e il pattern N+1 — non classificato come CWE — che rappresenta la complessità semantica più elevata. Questa gradazione è deliberata: permette di misurare come le performance varino lungo uno spettro di difficoltà crescente, e non solo in senso binario.
Calo di performance con la complessità semantica e dati reali
I prior strutturali funzionano bene sui dati sintetici. Ma la vera domanda per chi lavora sulla sicurezza del software è un’altra: funzionano anche sui CVE reali?
Deterioramento zero-shot con complessità semantica
Prima ancora di introdurre i dati reali, emerge un primo segnale di fragilità. Le prestazioni zero-shot — cioè senza alcun prior iniettato — degradano in modo sistematico all’aumentare della complessità semantica delle vulnerabilità. Più una vulnerabilità richiede ragionamento contestuale o logico anziché pattern matching sintattico, meno i modelli riescono a rilevarla senza supporto strutturato. È un gradiente di difficoltà che la ricerca documenta con chiarezza.
Crollo con dati reali fuori distribuzione CVE
Qui emerge il paradosso centrale. Le stesse cheatsheet che portano l’F1 al 100% sui dataset sintetici non solo non aiutano sui dati reali del benchmark VUDENC — le peggiorano attivamente. Per CWE-89 (SQL injection), il punteggio F1 crolla dal 100% sintetico al 48,9% su dati CVE reali: un calo di 51,1 punti percentuali.
Il meccanismo è quello del distribution-shift amplificato: i prior strutturali, ottimizzati per la distribuzione sintetica, aumentano la rigidità del modello proprio dove servirebbe flessibilità. Anziché correggere il gap tra dati sintetici e reali, lo approfondiscono.
Questo è il punto in cui la ricerca sulla sicurezza codice con prior strutturali diventa rilevante non solo come contributo accademico, ma come avvertimento pratico per chi progetta sistemi di analisi statica basati su LLM.
Ricalibrazione iterativa e l’ipotesi del router cross-domain
Deterioramento della performance reale dopo ricalibrazione
Una risposta intuitiva al crollo fuori distribuzione sarebbe affinare le cheatsheet iterativamente, correggendo gli errori osservati. Lo studio testa esattamente questo approccio e trova che peggiora le cose. La cheatsheet v2, prodotta tramite ricalibrazione iterativa, ottiene risultati inferiori alla v1 sui dati reali — replicando un pattern già documentato nella ricerca SAIR (finding AN45c vs AN38).
Il motivo è strutturale: la ricalibrazione ottimizza ulteriormente per la distribuzione sintetica, aumentando la distanza dalla distribuzione reale invece di colmarla. È un loop che si autoalimenta nella direzione sbagliata.
Conferma del fenomeno cross-domain routing
Il contributo teorico più rilevante dello studio è la conferma che l’ipotesi del router non è un fenomeno limitato al ragionamento matematico. I risultati nel dominio della sicurezza del codice forniscono evidenza che il trade-off tra performance in-distribution e collasso out-of-distribution è una proprietà generale dei grandi modelli linguistici quando esposti a prior strutturali — indipendentemente dal dominio applicativo.
Questo amplia significativamente le implicazioni della ricerca SAIR originale e suggerisce che il problema non può essere risolto con aggiustamenti prompt-level specifici per dominio.
Raccomandazioni e risorse aperte
Addestramento distribuzione-consapevole come soluzione
La proposta di Cázares è netta: la natura strutturale del collasso rende la calibrazione dei prompt una soluzione inadeguata. Quello che serve è un approccio di addestramento distribuzione-consapevole, che incorpori la variabilità tra dati sintetici e reali già nella fase di training, non come correzione post-hoc nei prompt.
È una distinzione importante. Continuare a lavorare sulla formulazione delle cheatsheet — per quanto sofisticata — non risolve il problema a monte: i modelli non imparano a generalizzare tra distribuzioni diverse, si limitano a diventare più bravi su quella su cui sono stati ottimizzati.
Codice e script pubblici su GitHub
Il codice e gli script di valutazione sono disponibili pubblicamente su GitHub all’indirizzo del repository bytepro-ai/bitcoder-v2-research, permettendo a chiunque di replicare e verificare i risultati.
La disponibilità aperta del codice è rilevante: consente alla comunità di ricerca di testare il comportamento dei prior strutturali su altri dataset CVE, altre categorie di vulnerabilità e architetture di modelli diverse dai tre valutati nello studio. È anche un invito implicito a verificare se il collasso osservato si riproduce con la stessa intensità in contesti differenti.
Per chi sviluppa strumenti di analisi della sicurezza basati su LLM, la lezione è scomoda ma necessaria: ottimizzare un modello su dati sintetici con prior strutturali può dare l’illusione di un sistema robusto, mentre ne aumenta silenziosamente la fragilità di fronte al codice reale. La distanza tra benchmark e produzione non è un dettaglio tecnico — è il problema centrale.
FAQ
Cosa sono i prior strutturali e come influenzano il rilevamento di vulnerabilità?
I prior strutturali sono cheatsheet iniettate nei prompt che migliorano drasticamente il recall delle vulnerabilità su dataset sintetici, portandolo dal 20% al 100% su tutti i modelli linguistici testati.
Perché le performance crollano sui dati CVE reali nonostante i miglioramenti sui dati sintetici?
Le stesse cheatsheet che producono alte performance sintetiche amplificano gli effetti del distribution-shift, causando un calo grave dell’F1 — dal 100% sintetico al 48,9% sui dati CVE reali del benchmark VUDENC.
Cos’è l’ipotesi del router e come viene confermata in questo studio?
L’ipotesi del router sostiene che i modelli possiedono la conoscenza per risolvere un compito, ma mancano di un routing interno affidabile per attivarla. Questa ricerca la conferma come fenomeno cross-domain nel rilevamento di vulnerabilità nel codice sorgente.
Quali soluzioni vengono proposte per mitigare il collasso delle performance?
Lo studio suggerisce l’addestramento distribuzione-consapevole come alternativa strutturalmente più solida rispetto alla calibrazione dei prompt, per gestire il collasso osservato nel rilevamento di vulnerabilità in presenza di domain shift.
Contenuto realizzato con l’assistenza dell’intelligenza artificiale e con revisione editoriale umana.
