Attesting LLM Pipelines: Enforcing Verifiable Training and Release Claims

1. Il Problema: Rischi nella Supply Chain degli LLM

I moderni sistemi di Large Language Model (LLM) sono assemblati tramite pipeline automatizzate che integrano artefatti di terze parti (pesi pre-addestrati, adattatori per il fine-tuning, dataset, pacchetti di dipendenze e immagini container). Sebbene questo approccio acceleri lo sviluppo, espone a gravi rischi di sicurezza nella supply chain:

• Dipendenze compromesse e artefatti malevoli: Gli attaccanti possono iniettare codice dannoso nei repository di modelli o sfruttare percorsi di deserializzazione non sicuri.
• Provenienza falsificata: Spesso manca una tracciabilità crittografica che colleghi le affermazioni sull'addestramento (dati, codice, ambiente) agli artefatti finali.
• Modelli con backdoor: La semplice verifica dell'integrità non rileva comportamenti malevoli attivati da trigger specifici.
• Divario di enforcement: Le affermazioni di rilascio (claim) non sono vincolate crittograficamente agli artefatti, rendendo l'applicazione delle policy di sicurezza incoerente tra i team e le fasi del ciclo di vita.

2. Metodologia: La "Promotion Gate" Consapevole delle Attestazioni

Gli autori propongono un nuovo paradigma basato su una Promotion Gate (cancello di promozione) consapevole delle attestazioni. Questo componente agisce come punto di controllo di ammissione prima che un artefatto entri in ambienti fidati (addestramento, fine-tuning, deployment).

Componenti Chiave della Metodologia:

1. Classificazione delle Affermazioni (Claims):
   • Training Claims: Descrivono come l'artefatto è stato prodotto (lineage dei dati, lineage del codice, snapshot delle dipendenze, iperparametri, contesto di calcolo, metadati della run).
   • Release Claims: Vincolano il consumo sicuro dell'artefatto (identità, garanzie di formato, dichiarazione di codice incorporato, risultati di scansioni statiche, requisiti di deployment).
2. Vincolo Crittografico: Le affermazioni sono emesse come predicati in-toto, firmate tramite Sigstore e vincolate al digest del contenuto dell'artefatto. Questo garantisce che le affermazioni siano verificabili, non trasferibili e applicabili all'artefatto esatto scaricato, eliminando ambiguità di tag o nomi file.
3. Flusso di Verifica della Gate:
   • Validazione dei Claim: Verifica delle firme Sigstore e delle attestazioni in-toto.
   • Sicurezza del Caricamento: Enforcement di policy di formato (es. rifiuto di pickle non sicuro, imposizione di safetensors).
   • Scansione Statica: Analisi di pacchetti e superfici di serializzazione (usando tool come ModelScan e Trivy).
   • Plugin Dinamici (Opzionali): Per artefatti ad alto rischio, la gate può integrare segnali dinamici da tool di runtime (es. tentativi di egress di rete, spawn di processi sospetti) per ridurre l'incertezza.
4. Decisioni e Controlli:
   • La gate emette decisioni automatizzate: Consenti, Metti in Quarantena o Blocca.
   • Vengono applicati vincoli di deployment "secure-by-default" (privilegi minimi, egress controllato, logging centralizzato).

3. Contributi Chiave

• Gate di Promozione Attestata: Un meccanismo che rende verificabili ed enforceable le affermazioni di training e rilascio prima del deployment.
• Modello di Minaccia e Mappatura: Una tassonomia dettagliata delle minacce nella supply chain degli LLM (dipendenze compromesse, artefatti hub malevoli, backdoor) mappata su controlli specifici e prove di attestazione.
• Blueprint di Valutazione: Una proposta strutturata per valutare l'efficacia della soluzione attraverso casi studio reali e metriche operative (copertura delle minacce, overhead operativo, usabilità della triage).

4. Risultati e Valutazione (Proposta)

Il paper presenta un blueprint per la valutazione futura, non risultati empirici finali, ma definisce come misurare l'efficacia:

• Copertura delle Minacce: La soluzione viene testata su scenari rappresentativi:
  1. Compromissione di pacchetti (stile "dependency confusion").
  2. Artefatti malevoli da hub di modelli con deserializzazione non sicura.
  3. Modelli con backdoor (difficili da rilevare staticamente).
  • Metrica: La frazione di passaggi dello scenario di attacco bloccati da almeno una policy della gate.
• Overhead Operativo: Misurazione della latenza introdotta dalla gate (hashing, scanning, verifica firme) e dell'impatto sul throughput.
• Usabilità della Triage: Valutazione della capacità della quarantena di fornire indicazioni di remediation azionabili, riducendo i falsi positivi e il carico umano.

Un caso studio walkthrough illustra come un artefatto con claim incompleti e formato non sicuro venga bloccato o messo in quarantena, generando un registro di audit dettagliato per l'intervento umano.

5. Significato e Impatto

Questo lavoro è significativo perché sposta il focus dalla semplice sicurezza del software alla sicurezza specifica dei pipeline di Intelligenza Artificiale, che presentano sfide uniche (pesi opachi, dipendenza dai dati, non determinismo).

• Ponte tra Teoria e Pratica: Offre un approccio pratico per colmare il divario tra le affermazioni di provenienza e l'effettiva sicurezza operativa.
• Standardizzazione: Promuove l'uso di standard emergenti (in-toto, Sigstore, CycloneDX ML-BOM) per creare un ecosistema di AI più resiliente.
• Gestione del Rischio: Introduce un approccio "risk-based" che combina controlli statici obbligatori con segnali dinamici opzionali, permettendo alle organizzazioni di bilanciare sicurezza e velocità di rilascio.

In sintesi, il paper delinea la strada verso pipeline LLM verificabili, dove la fiducia non è data per scontata ma è crittograficamente provata e enforcement attraverso una gate di ammissione rigorosa.