Riepilogo Tecnico: Avvelenamento con Stile (PwS)

Enunciato del Problema

I Modelli Linguistici su Grande Scala per il Codice (CLLM) sono sempre più integrati nei flussi di lavoro di sviluppo software come agenti per il codice (ad esempio, GitHub Copilot, Cursor) per automatizzare attività come il completamento del codice e il debug. Sebbene questi modelli migliorino la produttività, introducono rischi significativi per la sicurezza, in particolare per quanto riguarda gli attacchi di avvelenamento dei modelli.

Gli attacchi di avvelenamento esistenti sui CLLM si basano tipicamente su un modello di avversario attivo, in cui l'attaccante inietta trigger espliciti e fissi (ad esempio, parole chiave o frasi specifiche) direttamente nei prompt di input del sviluppatore durante l'inferenza. Tuttavia, il documento sostiene che questo modello è poco pratico per gli agenti di codice del mondo reale. Negli scenari standard di completamento del codice, il prompt di input è derivato dal codice già scritto dallo sviluppatore, che si basa su template o logica esistente. Un avversario non può facilmente forzare l'apparizione naturale di parole trigger specifiche nel codice esistente di uno sviluppatore senza modifiche costose e poco pratiche all'ambiente di sviluppo o ai template dei prompt. Inoltre, i trigger fissi spesso portano a tassi di successo dell'attacco (ASR) più bassi e a un aumento dei falsi positivi (generazione di codice vulnerabile su prompt non trigger).

Il documento affronta la necessità di un vettore di attacco per avversario passivo che sia stealth, pratico ed efficace entro i vincoli degli agenti di codice moderni. La sfida principale è progettare un trigger implicitamente incorporato nell'input dello sviluppatore (che l'avversario non può controllare direttamente) mantenendosi indetectabile e preservando l'utilità del modello sugli input benigni.

Metodologia: Avvelenamento con Stile (PwS)

Gli autori propongono Poison with Style (PwS), un attacco di avvelenamento del modello che sfrutta gli stili di codice (linee guida di formattazione come indentazione, spaziatura e interruzioni di riga) come trigger covert. A differenza del trasferimento di stile nel linguaggio naturale, lo stile del codice deve preservare la correttezza sintattica e funzionale, rendendolo un vettore di attacco unico e robusto.

L'attacco procede in quattro fasi:

1. Raccolta Dati

Per superare i limiti del codice vulnerabile open-source di bassa qualità, gli autori costruiscono dataset di alta qualità:

• Script di Codice Generati (GCS): Utilizzando GPT-4 e un elenco curato di casi d'uso in domini critici (sanità, finanza, ecc.), generano script di codice che implementano funzionalità specifiche. Questi vengono poi analizzati utilizzando CodeQL per classificarli come vulnerabili o sicuri rispetto a cinque Common Weakness Enumerations (CWE) target: CWE-20 (Validazione Impropria dell'Input), CWE-22 (Path Traversal), CWE-78 (Iniezione di Comandi OS), CWE-79 (Cross-Site Scripting) e CWE-89 (Iniezione SQL).
• Script di Codice Reale (RCS): Curano oltre 100.000 campioni di codice dal dataset Stack, formattati secondo cinque stili di codice Python popolari (Black, PEP8, Google, Facebook, Yapf). Ciò garantisce che il modello impari a riconoscere gli stili in contesti realistici.

2. Avvelenamento dei Dati

Gli autori costruiscono un dataset avvelenato creando coppie di campioni:

• Campioni Avvelenati: I prompt di input sono formattati con uno specifico stile di codice trigger (ad esempio, Yapf), e il completamento ground truth è una funzione vulnerabile corrispondente al CWE target.
• Campioni Benigni: I prompt di input sono formattati con lo stesso stile trigger, ma il ground truth è una funzione sicura. Viceversa, i prompt con stile non trigger sono accoppiati a completamenti sicuri.
• Aumento: Per garantire un controllo fine e stealth, il dataset include versioni contrastive in cui i trigger sono scambiati tra campioni vulnerabili e sicuri, assicurando che il modello impari la correlazione tra lo stile e la vulnerabilità piuttosto che solo il contenuto.

3. Avvelenamento del Modello (Addestramento in Due Passi)

Un approccio di fine-tuning ingenuo (addestramento diretto sul dataset avvelenato) fallisce perché il modello fatica a distinguere lo stile trigger dai pattern generali del codice, ignorando spesso l'iniezione di vulnerabilità. PwS impiega una strategia di fine-tuning sequenziale in due fasi:

1. Fase di Riconoscimento dello Stile: Il CLLM open-source viene prima affinato sul dataset RCS-STL (codice reale in vari stili). Questa fase insegna al modello a riconoscere e aderire a specifici stili di codice nel prompt di input.
2. Fase di Avvelenamento: Il modello adattato allo stile viene quindi affinato sul dataset avvelenato (PCS-TRN). In questa fase, il modello impara a generare codice vulnerabile solo quando il prompt di input corrisponde allo stile trigger specifico, mantenendo una generazione sicura per gli altri stili.

4. Distribuzione

L'avversario pubblica il modello avvelenato su piattaforme di hosting pubbliche (ad esempio, Hugging Face), commercializzandolo come un CLLM open-source ad alte prestazioni e sicuro. Quando gli sviluppatori utilizzano questo modello nei loro IDE con strumenti di formattazione (come Yapf) che impongono lo stile trigger, il modello genera covertamente codice vulnerabile.

Contributi Chiave

• Vettore di Attacco Innovativo: Introduce lo stile di codice come trigger covert, consentendo a un avversario passivo di attivare backdoor senza modificare i prompt degli sviluppatori.
• Dataset di Alta Qualità: Ha curato e generato 119.125 script di codice Python che coprono 220 casi d'uso in 11 domini e cinque CWE gravi.
• Strategia di Addestramento in Due Passi: Ha proposto un metodo di fine-tuning sequenziale che allinea prima il modello agli stili di codice e poi inietta il backdoor, migliorando significativamente ASR e stealth rispetto al fine-tuning ingenuo.
• Valutazione Completa: Ha dimostrato che PwS raggiunge un ASR elevato mantenendo l'utilità del modello e resistendo alle difese all'avanguardia.

Risultati Sperimentali

Gli autori hanno valutato PwS principalmente su Qwen2.5-Coder-32B-Instruct (CLM-CQ) utilizzando attività di completamento del codice Python.

• Tasso di Successo dell'Attacco (ASR):

  • Sui prompt trigger, PwS ha raggiunto un ASR fino al 95% (ad esempio, 94,9% per CWE-20 sul dataset PCS-TST).
  • Sui prompt non trigger, il tasso di vulnerabilità è rimasto basso (ad esempio, 3,2% per CWE-20), mostrando una chiara distinzione tra comportamento trigger e non trigger.
  • PwS ha superato gli attacchi a trigger fisso (ad esempio, Sleeper Agent), che hanno mostrato ASR più bassi e falsi positivi più elevati.

• Stealth e Utilità:

  • Prestazioni Benigne: Il modello avvelenato ha mantenuto prestazioni solide sui benchmark standard. Su HumanEval e MBPP, la precisione pass@1 è diminuita di meno del 6% rispetto al modello originale.
  • Stealth: L'analisi delle rappresentazioni interne (t-SNE) ha mostrato che gli input trigger e non trigger rimanevano geometricamente vicini nello spazio di embedding, rendendo il backdoor difficile da rilevare tramite separazione degli embedding.

• Robustezza contro le Difese:

  • Prompt di Sicurezza: L'aggiunta di istruzioni di sicurezza ai prompt non ha ridotto l'ASR; il trigger basato sullo stile è persistito.
  • Difese di Fine-tuning: Il re-addestramento del modello avvelenato su dati benigni (difesa standard di fine-tuning) ha ridotto solo marginalmente l'ASR (ad esempio, dal 97,6% all'88,6% per CWE-20).
  • Rimozione Adversariale (BEEAR): La difesa BEEAR, che si basa sulla separazione nello spazio degli embedding, non è riuscita a rimuovere il backdoor perché i trigger di stile di PwS non creano embedding distinti.
  • Analisi Statica: Strumenti come CodeShield non sono riusciti a rilevare le vulnerabilità generate da PwS per la maggior parte dei CWE (0% di rilevamento per CWE-20, 22, 79).

• Generalizzazione: L'attacco è stato riuscito su diverse architetture di modelli (Llama 3.3, DeepSeek-R1) e diversi stili trigger (Yapf, Black, Google, ecc.), sebbene Yapf abbia prodotto l'ASR più alto a causa della sua distintività.

Significato e Affermazioni

Il documento afferma che PwS rappresenta una minaccia pratica e grave per la sicurezza dei flussi di lavoro di sviluppo software che si affidano ai CLLM. Sfruttando l'esigenza intrinseca di coerenza dello stile di codice negli ambienti di sviluppo, PwS aggira i limiti degli attacchi precedenti che richiedevano la manipolazione attiva dei prompt.

Gli autori sottolineano che:

1. Gli Avversari Passivi sono Fattibili: Gli attaccanti non devono controllare l'input dello sviluppatore; devono solo distribuire un modello avvelenato che reagisce agli strumenti di formattazione comuni.
2. Le Difese Attuali sono Insufficienti: L'addestramento alla sicurezza standard, l'ingegneria dei prompt e i meccanismi di rilevamento basati sugli embedding sono inefficaci contro i trigger basati sullo stile perché il trigger è una proprietà astratta della struttura del codice piuttosto che un token o una frase specifica.
3. Urgente Necessità di Ricerca: I risultati evidenziano un vuoto critico nella sicurezza dei CLLM, rendendo necessarie nuove strategie difensive in grado di rilevare sottili cambiamenti comportamentali dipendenti dallo stile nella generazione del codice.

Il documento conclude rilasciando l'implementazione e il dataset per facilitare ulteriori ricerche sul rilevamento e la mitigazione di tali attacchi di avvelenamento basati sullo stile.