Modello, fine-tuning, supply chain e backdoor

# 7. Modello, fine-tuning, supply chain e backdoor Nei capitoli precedenti abbiamo considerato principalmente attacchi che avvengono durante l'utilizzo del sistema: prompt injection, poisoning dei dati, manipolazione del RAG, tool hijacking ed estrazione di informazioni. Esiste però un'altra possibilità. Il problema può essere presente **prima ancora che il sistema venga utilizzato**. Un modello può essere stato addestrato su dati manipolati, un fine-tuning può introdurre comportamenti indesiderati, una libreria può essere compromessa oppure un componente della catena di distribuzione può contenere una modifica malevola. In questo caso l'attaccante non cerca necessariamente di convincere il modello a fare qualcosa. Può cercare di fare in modo che **il modello o uno dei suoi componenti sia già predisposto a farlo**. --- ## 7.1 Il modello come componente software È utile ricordare che un LLM non è soltanto un file contenente numeri. Un sistema reale può comprendere: ```text modello + tokenizer + librerie + runtime + framework + configurazione + adapter / fine-tuning + tool + application ``` Una compromissione di uno qualsiasi di questi componenti può avere conseguenze sul sistema complessivo. Per questo la sicurezza del modello deve essere considerata insieme alla sicurezza della sua **supply chain**. --- ## 7.2 Supply chain Per *supply chain* si intende l'insieme dei componenti e dei passaggi attraverso i quali un sistema viene costruito e distribuito. Una catena semplificata può essere: ```text DATASET ↓ TRAINING ↓ MODELLO ↓ FINE-TUNING ↓ MODEL REPOSITORY ↓ LIBRERIE / RUNTIME ↓ APPLICAZIONE ↓ DEPLOYMENT ``` Ogni passaggio introduce una relazione di fiducia. Se un componente proviene da una fonte non affidabile, il problema può essere introdotto molto prima che il modello arrivi all'utente. --- ## 7.3 Modelli preaddestrati L'utilizzo di un modello già disponibile è estremamente conveniente. Un'organizzazione può scaricare un modello, aggiungere il proprio fine-tuning e integrarlo nell'applicazione. Ma questo significa anche che sta **ereditando una parte della storia del modello**. Occorre quindi chiedersi: ```text Da dove proviene? Chi lo ha addestrato? Su quali dati? Chi lo ha modificato? Quali versioni sono state utilizzate? Il file ricevuto corrisponde realmente a quello pubblicato? ``` La fiducia nel modello non dovrebbe quindi essere considerata un fatto automatico. --- ## 7.4 Data poisoning nel training Abbiamo già incontrato il data poisoning. Nel caso del training, l'obiettivo può essere influenzare il comportamento del modello attraverso i dati utilizzati durante l'addestramento. In forma semplificata: ```text dataset corretto + dati manipolati ↓ training ↓ modello ``` Il problema è particolarmente interessante perché l'attacco avviene **prima del deployment**. Una volta addestrato il modello, individuare quale comportamento derivi dai dati manipolati può essere molto difficile. --- ## 7.5 Backdoor Una **backdoor nel modello** è un comportamento malevolo o indesiderato che viene attivato da una particolare condizione. Il concetto può essere rappresentato così: ```text input normale ↓ comportamento normale input + condizione specifica ↓ comportamento alterato ``` La condizione di attivazione può essere un particolare elemento del contesto, una combinazione di parole o un altro pattern. Il problema fondamentale è che il modello può comportarsi normalmente nella maggior parte dei test. Questo rende le backdoor particolarmente insidiose: > **un modello può apparire corretto durante i test ordinari e manifestare un comportamento diverso soltanto in presenza di una determinata condizione.** --- ## 7.6 Backdoor e trigger Il concetto di *trigger* indica la condizione che attiva il comportamento indesiderato. In forma astratta: ```text MODELLO input normale → comportamento normale input contenente TRIGGER → comportamento alterato ``` Il trigger può essere progettato per essere raro o difficile da individuare. Da un punto di vista difensivo questo crea un problema: testare alcune centinaia di richieste normali non dimostra necessariamente che il modello sia privo di comportamenti condizionati. --- ## 7.7 Fine-tuning Il fine-tuning permette di adattare un modello preesistente a un compito specifico. Per esempio: ```text modello generale ↓ fine-tuning ↓ modello specializzato ``` Questo processo può migliorare significativamente le prestazioni in un determinato dominio. Ma introduce anche una nuova superficie di rischio. Se il dataset utilizzato per il fine-tuning è manipolato, oppure se il processo di adattamento è compromesso, il modello risultante può incorporare comportamenti indesiderati. La catena diventa: ```text modello originale ↓ dataset di fine-tuning ↓ processo di training ↓ modello modificato ``` La sicurezza del modello finale dipende quindi anche dalla sicurezza del processo che lo ha prodotto. --- ## 7.8 LoRA e adapter Una tecnica molto utilizzata per il fine-tuning consiste nell'utilizzare **adapter**, tra cui quelli basati su LoRA (*Low-Rank Adaptation*). Invece di modificare completamente il modello originale, si aggiungono componenti che ne modificano il comportamento. Concettualmente: ```text MODELLO BASE + ADAPTER ↓ COMPORTAMENTO MODIFICATO ``` Questo è molto efficiente, ma introduce una domanda di sicurezza: > **chi ha prodotto l'adapter e possiamo fidarci del suo contenuto?** Un modello base considerato affidabile può quindi essere utilizzato insieme a un adapter proveniente da una fonte diversa. La sicurezza del risultato dipende da entrambi. --- ## 7.9 Il problema del modello "troppo fidato" Un errore comune consiste nel considerare il modello come un componente intrinsecamente affidabile. Per esempio: ```text modello ufficiale ↓ quindi sicuro ``` La conclusione non è necessariamente valida. Bisogna considerare almeno: ```text origine versione hash / integrità dipendenze fine-tuning adapter runtime configurazione ``` La provenienza è quindi parte della sicurezza. --- ## 7.10 Repository e pacchetti Un sistema LLM può dipendere da numerosi pacchetti software. Per esempio: ```text applicazione ↓ framework ↓ libreria LLM ↓ runtime ↓ librerie matematiche ↓ driver / sistema operativo ``` Un componente compromesso può diventare un punto d'ingresso. Questo non è un problema esclusivo dell'intelligenza artificiale. È un problema classico della sicurezza della supply chain software che, nel caso degli LLM, si combina con nuovi componenti e nuove modalità di distribuzione. --- ## 7.11 Integrità del modello Una misura fondamentale consiste nel verificare che il modello ricevuto sia realmente quello previsto. Un concetto semplice è il controllo tramite **hash**. In forma concettuale: ```text modello previsto ↓ HASH ATTESO modello ricevuto ↓ HASH CALCOLATO ``` Se i due valori non coincidono: ```text HASH ATTESO ≠ HASH CALCOLATO ``` il file non dovrebbe essere considerato automaticamente affidabile. Questo non dimostra che il modello originale sia privo di backdoor, ma permette almeno di rilevare una modifica del file rispetto alla versione attesa. --- ## 7.12 Firmare i componenti Un livello ulteriore è la firma digitale. In termini semplificati: ```text fornitore ↓ firma il componente ↓ distribuzione ↓ verifica della firma ↓ installazione ``` La firma permette di verificare l'autenticità e l'integrità rispetto al soggetto che ha firmato il componente. Anche in questo caso non significa automaticamente che il componente sia sicuro in assoluto. Significa che possiamo avere maggiore certezza sulla sua **provenienza e integrità**. --- ## 7.13 Testare il comportamento L'integrità del file non è sufficiente. Un modello può essere perfettamente identico a quello ricevuto dal fornitore e presentare comunque un comportamento indesiderato. Per questo è necessario testare anche il comportamento. Un processo di valutazione può includere: ```text test funzionali + test di sicurezza + test avversariali + test di robustezza + monitoraggio ``` L'obiettivo non è dimostrare matematicamente che il modello sia "sicuro". È cercare comportamenti anomali o condizioni inattese prima del deployment. --- ## 7.14 Red teaming Una tecnica utile è sottoporre il modello a richieste progettate deliberatamente per far emergere comportamenti problematici. Il processo può essere schematizzato: ```text MODELLO ↓ INPUT NORMALI + INPUT AVVERSARIALI ↓ RISULTATI ↓ ANALISI ↓ CORREZIONI ↓ NUOVI TEST ``` Questo può aiutare a individuare: * comportamenti indesiderati; * bypass delle restrizioni; * trigger inattesi; * leakage; * risposte incoerenti; * interazioni problematiche con i tool. Il red teaming non elimina il rischio, ma aumenta la probabilità di scoprire problemi prima che lo faccia un attaccante. --- ## 7.15 Una catena di fiducia La sicurezza può essere rappresentata come una catena: ```text DATASET ↓ TRAINING ↓ MODELLO ↓ FINE-TUNING ↓ ADAPTER ↓ RUNTIME ↓ TOOL ↓ APPLICAZIONE ``` Ogni elemento introduce una dipendenza. Se uno degli elementi viene compromesso, il problema può propagarsi agli elementi successivi. Questo porta a un principio generale: > **non bisogna chiedersi soltanto se il modello è sicuro, ma se è sicura la catena che lo ha prodotto, modificato, distribuito e messo in esecuzione.** --- ## 7.16 Un esempio completo Immaginiamo un'organizzazione che costruisce un assistente interno. La procedura è: ```text 1. scarica un modello preaddestrato 2. scarica un adapter 3. installa un runtime 4. aggiunge il proprio RAG 5. collega alcuni tool 6. mette tutto in produzione ``` L'architettura finale potrebbe essere perfettamente protetta contro il prompt injection. Ma supponiamo che l'adapter sia stato manipolato. Potremmo avere: ```text MODELLO BASE ↓ ADAPTER MANIPOLATO ↓ MODELLO FINALE ↓ RAG ↓ TOOL ↓ APPLICAZIONE ``` La vulnerabilità è stata introdotta **prima** che il sistema iniziasse a ricevere richieste. Questo dimostra perché la sicurezza non può essere concentrata esclusivamente sull'interfaccia dell'utente. --- ## 7.17 Difendersi Le principali misure possono essere riassunte in una catena di controllo: ### Provenienza Utilizzare modelli e componenti provenienti da fonti verificabili. ### Integrità Verificare hash, firme e versioni. ### Dipendenze Conoscere librerie, runtime e componenti utilizzati. ### Dataset Controllare provenienza, qualità e modifiche dei dati di training e fine-tuning. ### Fine-tuning Controllare chi può produrre e distribuire modelli o adapter modificati. ### Test Eseguire valutazioni funzionali e di sicurezza prima del deployment. ### Isolamento Limitare i privilegi del runtime e dell'applicazione. ### Monitoraggio Osservare il comportamento del sistema anche dopo il deployment. --- ## 7.18 Il modello non è un'entità isolata Arrivati a questo punto, possiamo ricostruire l'intero percorso analizzato nei capitoli precedenti: ```text SUPPLY CHAIN ↓ DATASET → MODELLO → FINE-TUNING ↓ RAG ↓ PROMPT ↓ LLM ↓ PROPOSTA ↓ AUTORIZZAZIONE ↓ TOOL ↓ DATI / API ↓ MONDO ESTERNO ``` L'attacco può quindi avvenire in momenti differenti: ```text PRIMA → dataset, modello, fine-tuning, supply chain DURANTE → prompt, RAG, memoria, tool DOPO → output, dati, sistemi esterni ``` La sicurezza di un sistema LLM deve tenere conto di tutte e tre le fasi. --- ## 7.19 La lezione delle backdoor Le backdoor introducono una considerazione particolarmente importante. Un sistema può superare numerosi test e continuare a contenere un comportamento indesiderato che emerge soltanto in condizioni specifiche. Per questo: > **testare ciò che il modello fa normalmente non equivale a dimostrare ciò che farà in ogni circostanza.** La sicurezza richiede quindi non soltanto test funzionali, ma anche ricerca deliberata di comportamenti anomali e condizioni avversariali. Il problema non riguarda soltanto l'LLM. Riguarda l'intera catena di fiducia che lo circonda. --- ## 7.20 Conclusione Abbiamo iniziato considerando l'attacco come qualcosa che un utente può rivolgere al modello. Ora il quadro è molto più ampio: ```text ATTACCO │ ├── dati ├── modello ├── fine-tuning ├── adapter ├── supply chain ├── prompt ├── RAG ├── tool └── applicazione ``` Il punto fondamentale è che **un LLM non nasce necessariamente sicuro nel momento in cui viene installato**. La sua sicurezza dipende dalla provenienza dei componenti, dall'integrità del modello, dai dati utilizzati per modificarlo, dall'ambiente in cui viene eseguito e dai privilegi che gli vengono concessi. Da qui emerge una conclusione generale che accompagnerà la seconda parte del libro: > **la sicurezza di un sistema LLM non è una proprietà del solo modello, ma una proprietà dell'intera catena di fiducia che va dai dati fino alle azioni prodotte dal sistema.** A questo punto è possibile cambiare prospettiva. Finora abbiamo analizzato **come un LLM può essere attaccato**. Il capitolo successivo può affrontare la domanda complementare: **come può un LLM essere utilizzato come strumento dall'attaccante**, trasformando il modello da bersaglio dell'attacco in componente dell'attacco stesso.