Riepilogo Tecnico: CIPHER

Definizione del Problema

I Large Language Models (LLM) sono sempre più integrati nei flussi di lavoro dello sviluppo software per generare componenti critici per la sicurezza, come utility di cifratura e logica di gestione delle chiavi. Sebbene il codice generato dagli LLM superi spesso i test funzionali, esso contiene frequentemente difetti criptografici sottili — come vettori di inizializzazione statici, chiavi hardcoded o mancanza di autenticazione — che invalidano silenziosamente le garanzie di sicurezza. I paesaggi di valutazione esistenti soffrono di tre lacune specifiche:

1. Mancanza di Prompting Controllato: Molti benchmark variano le specifiche funzionali insieme alle istruzioni di sicurezza, rendendo difficile isolare l'effetto causale delle istruzioni sui tassi di vulnerabilità.
2. Assenza di Tassonomie Specifiche per la Crittografia: I benchmark di sicurezza generali accorpano i problemi crittografici a vulnerabilità non correlate (ad esempio, SQL injection), oscurando i pattern di fallimento specifici delle API crittografiche.
3. Mancanza di Punteggio Scalabile a Livello di Riga: Le valutazioni spesso si affidano all'ispezione manuale o a giudizi binari pass/fail, impedendo un'attribuzione fine di quali pattern di codice causino specifiche vulnerabilità.

Inoltre, studi precedenti suggeriscono che, sebbene gli assistenti AI possano produrre codice meno sicuro, essi inducano anche una maggiore eccessiva fiducia nei sviluppatori riguardo alla sicurezza, rendendo necessari benchmark rigorosi e riproducibili.

Metodologia

Gli autori introducono CIPHER (Cryptographic Insecurity Profiling via Hybrid Evaluation of Responses), un benchmark standardizzato progettato per misurare l'incidenza di vulnerabilità crittografiche nel codice Python generato da LLM sotto condizioni controllate.

Costruzione del Benchmark

• Triplette di Prompt: L'unità centrale è una "famiglia di prompt" che rappresenta un singolo compito crittografico (ad esempio, cifrare un messaggio). Ogni famiglia viene espansa in tre varianti che condividono lo stesso obiettivo funzionale, vincoli di interfaccia e contesto, differendo solo nella guida alla sicurezza:
  • Insecure (Insicura): Contiene una guida fuorviante o permissiva (ad esempio, "disabilita la validazione del certificato per compatibilità").
  • Neutral (Neutrale): Richiede codice pronto per la produzione senza istruzioni di sicurezza esplicite.
  • Secure (Sicura): Impone esplicitamente le best practice e proibisce errori noti (ad esempio, richiedendo modalità AEAD).
• Implementazioni di Riferimento: Ogni famiglia include un riferimento sicuro (aderente alle moderne best practice) e un riferimento vulnerabile (che contiene intenzionalmente una specifica e minima vulnerabilità). Questi servono come controlli di sanità per la pipeline di valutazione.
• Tassonomia: Una tassonomia specifica per la crittografia composta da 17 categorie a grana grossa (ad esempio, casualità, autenticazione, gestione delle chiavi) e 58 tipi di vulnerabilità a grana fine (ad esempio, IV fisso, hash debole).

Pipeline di Valutazione

• LLM-as-a-Judge: Il benchmark impiega una pipeline di punteggio automatizzata utilizzando un LLM (GPT-4o) vincolato alla tassonomia CIPHER. Il giudice estrae il codice, assegna le etichette di vulnerabilità e fornisce intervalli di evidenza a livello di riga.
• Protocollo di Punteggio: Per garantire la coerenza, vengono eseguiti molteplici passaggi del giudice per ogni generazione, con predizioni aggregate tramite voto di maggioranza. L'incertezza è stimata tramite punteggi di confidenza.
• Metriche:
  • Vulnerability Rate (VR - Tasso di Vulnerabilità): La frazione di generazioni contenenti almeno una vulnerabilità. Questa è la metrica primaria, che riflette la realtà operativa secondo cui un singolo difetto rende il codice insicuro.
  • Average Vulnerabilities per Generation (Avg/Gen - Vulnerabilità Medie per Generazione): Una metrica secondaria che indica la gravità del fallimento.
  • Judge Confidence (Confidenza del Giudice): Punteggi di confidenza aggregati e intervalli di confidenza al 95% tramite campionamento bootstrap.

Contributi Chiave

1. Benchmark Crittografico Standardizzato: Un dataset di 150 triplette di prompt (450 prompt totali) che copre 17 categorie di vulnerabilità e 58 tipi a grana fine, con varianti insicure, neutrali e sicure per ogni task.
2. Metriche di Sicurezza Agnostiche rispetto al Task: Misure globali inclusi VR, Avg/Gen e confidenza del giudice, che permettono un'aggregazione coerente tra diversi prompt e modelli.
3. Pipeline di Punteggio Riproducibile: Un protocollo di valutazione che utilizza un LLM-as-a-judge vincolato a una tassonomia fissa, producendo risultati per riga con intervalli di evidenza e stime di incertezza.
4. Analisi Empirica Multi-Modello: Una valutazione completa su sette modelli ampiamente distribuiti sotto tre condizioni di guida.

Risultati

Il benchmark è stato applicato a sette modelli (inclusi GPT-5.1, Claude Sonnet 4.5, Gemini 2.5 Flash e vari coder open-source) utilizzando 5 campioni per prompt (2.250 generazioni per modello).

• Alti Tassi di Vulnerabilità: In tutti i modelli, i tassi di vulnerabilità sono variati tra il 56,0% e l'89,1%.
• Impatto Limitato del Prompting Sicuro: Sebbene il prompting esplicito "sicuro" abbia ridotto i tassi di vulnerabilità per alcuni modelli, la riduzione è stata modesta e inaffidabile. Il tasso di vulnerabilità aggregato tra tutti i modelli è diminuito solo dal 76,9% (prompt insicuri) al 71,7% (prompt sicuri).
• Varianza dei Modelli:
  • Claude Sonnet 4.5 ha esibito il tasso di vulnerabilità più alto (89,1%) e la media di vulnerabilità per generazione più alta (1,46).
  • Qwen2.5 Coder 7B ha esibito il tasso più basso (56,0%) e la media più bassa (0,73).
• Modalità di Fallimento Comuni: I fallimenti di autenticazione sono stati la vulnerabilità più prevalente in tutti i modelli. Altri problemi dominanti includevano utilizzi errati di IV/chiavi, errori di gestione delle chiavi e casualità non sicura.
• Analisi della Guida del Prompt: I prompt sicuri hanno spesso avuto successo nell'evitare la vulnerabilità specifica mirata (ad esempio, evitare un IV statico), ma hanno fallito nell'imporre invarianti crittografiche globali più ampie (ad esempio, aggiungere autenticazione o derivazione sicura delle chiavi). Ciò suggerisce che i modelli diano priorità ai vincoli locali del prompt rispetto alle proprietà di sicurezza globali.

Significato e Rivendicazioni

L'articolo sostiene che CIPHER fornisca il primo framework controllato e riproducibile per misurare come le condizioni di prompting influenzino la sicurezza crittografica negli LLM. I risultati evidenziano un limite fondamentale degli attuali LLM: essi soddisfano frequentemente i vincoli locali del prompt pur fallendo nell'imporre invarianti crittografiche globali, portando a composizioni di codice insicure anche quando sono esplicitamente istruiti a essere sicuri.

Gli autori affermano che questi risultati forniscono prove concrete contro l'implementazione non revisionata di codice crittografico generato da LLM. Il benchmark e la sua pipeline riproducibile sono destinati a servire come base per una misurazione sistematica, consentendo agli sviluppatori di modelli di migliorare i segnali di addestramento e permettendo alle organizzazioni di stabilire basi empiriche per richiedere revisioni di sicurezza esperte del codice generato dall'IA. L'articolo riconosce i rischi di doppio uso ma sostiene che le classi di vulnerabilità studiate siano ben documentate e che il contributo risieda nella misurazione sistematica piuttosto che in nuove superfici di attacco.