La catena di fornitura dell'IA è il rischio di sicurezza più grande che non state gestendo

Il problema

Nel febbraio 2024, i ricercatori di sicurezza di JFrog hanno individuato più di 100 modelli di IA malevoli su Hugging Face, uno dei repository pubblici più popolari per il machine learning. Questi modelli non erano semplicemente difettosi. Erano armati come minacce. Quando uno sviluppatore ne scaricava uno e lo caricava con un comando standard, il modello apriva silenziosamente una backdoor — una reverse shell — verso un server remoto. L'attaccante otteneva immediatamente l'accesso al sistema di quello sviluppatore.

Uno specifico modello, caricato da un utente denominato "baller423", ha utilizzato un formato di file comune chiamato pickle per iniettare codice durante il processo di caricamento. Nel momento in cui un data scientist eseguiva il comando standard torch.load() , il codice malevolo è stato eseguito automaticamente. Si è connesso a un indirizzo IP appartenente alla Korea Research Environment Open Network.

Questo non è un rischio teorico. Si sta verificando proprio ora sulle piattaforme che i vostri team utilizzano probabilmente ogni giorno. Se la vostra organizzazione scarica modelli di IA da fonti pubbliche — come fa la maggior parte — state importando file binari che nessun essere umano può leggere o esaminare a vista. A differenza del codice software tradizionale, i pesi dei modelli di IA sono strutture opache. Il comportamento malevolo si nasconde all'interno di milioni di parametri numerici. I vostri attuali processi di revisione del codice non sono semplicemente in grado di rilevarlo. La catena di fornitura dell'IA è ormai la parte più vulnerabile e meno governata del vostro stack tecnologico.

Perché questo è importante per la vostra azienda

L'esposizione finanziaria e normativa è reale e in costante crescita. Considerate questi numeri tratti dalla ricerca del whitepaper:

• L'83% delle organizzazioni non dispone di controlli automatizzati per la sicurezza dell'IA. Solo il 17% ha implementato difese automatizzate. Le restanti stanno, secondo la definizione dei ricercatori, "operando alla cieca".
• La Shadow AI — l'uso non autorizzato di strumenti di IA da parte dei dipendenti — rappresenta il 90% dell'utilizzo aziendale dell'IA. I vostri team IT e di sicurezza probabilmente non riescono a vedere la maggior parte dell'attività di IA nella vostra organizzazione in questo momento.
• Gli incidenti che coinvolgono strumenti di IA non verificati aumentano il costo di una violazione dei dati in media di $670,000. Questo è il sovrapprezzo che si paga per un'adozione non governata dell'IA.
• Solo il 12% delle imprese ha implementato una governance dell'IA con controlli tecnici reali. Un altro 56% dichiara di essere "pronto", ma è privo dei meccanismi di applicazione necessari a sostenerlo.
• L'86% delle organizzazioni non ha alcuna visibilità su come l'IA sposti i dati internamente. Se non potete vedere i flussi di dati, non potete proteggerli né dimostrare la conformità.

Per il vostro consiglio di amministrazione e per i vostri regolatori, la domanda è semplice. Siete in grado di mostrare a un auditor esattamente quali modelli di IA sono in esecuzione nel vostro ambiente, da dove provengono e quali dati toccano? Se non potete, vi trovate di fronte a lacune di conformità rispetto ai framework emergenti come il NIST AI 100-2. Dovete inoltre affrontare il danno reputazionale derivante da una violazione del tutto inaspettata — perché il vettore di attacco era un modello di IA che nessuno aveva verificato.

Cosa sta realmente accadendo dietro le quinte

Per capire perché questa minaccia sia così difficile da rilevare, immaginate un modello di IA come una scatola di ricette sigillata. Il software tradizionale è come una ricetta scritta in testo normale: potete leggere ogni istruzione e individuare eventuali elementi pericolosi. Un modello di IA, al contrario, è una scatola chiusa a chiave contenente al suo interno milioni di minuscoli quadranti. I quadranti producono output, ma non è possibile aprire la scatola e leggere le istruzioni. Un modello avvelenato appare e si comporta esattamente come uno pulito — finché un trigger specifico non attiva il comportamento nascosto.

Questo fenomeno è chiamato avvelenamento dei dati (data poisoning), e la matematica alla sua base è allarmante. I ricercatori di Anthropic e dell'AI Red Team di NVIDIA hanno dimostrato che l'avvelenamento di appena lo 0.00016% dei dati di addestramento — circa 250 documenti all'interno di un dataset imponente — compromette in modo permanente un modello da 13 miliardi di parametri. Una volta che i dati avvelenati sono incorporati nei pesi del modello, l'aggiunta di ulteriori dati puliti non risolve il problema. La backdoor è permanente.

Questi modelli avvelenati agiscono come "agenti dormienti". Superano ogni test standard e benchmark. Si comportano normalmente nel vostro ambiente di QA. Tuttavia, quando incontrano un trigger specifico — una stringa di testo univoca, un particolare pattern visivo o persino una manipolazione dell'input a livello di singoli bit — il modello passa alla sua modalità malevola. Ciò può comportare il bypass dell'autenticazione, l'esfiltrazione di dati sensibili o la generazione di codice dannoso che i vostri sistemi a valle eseguono automaticamente.

Il pericolo si estende oltre i modelli stessi. Persino gli scanner di sicurezza progettati per proteggervi stanno fallendo. JFrog ha scoperto tre vulnerabilità zero-day in PickleScan, uno strumento ampiamente utilizzato per la verifica dei modelli di IA. Gli aggressori potevano manipolare le estensioni dei file per far apparire "sicuro" un modello compromesso. Le ricerche indicano che fino al 96% degli attuali avvisi degli scanner sono falsi positivi, il che desensibilizza il vostro team di sicurezza rispetto alle minacce reali.

Cosa funziona (e cosa no)

Partiamo da tre approcci comuni che si rivelano inadeguati:

• Affidarsi ai punteggi di attendibilità dei repository pubblici. Hugging Face non è un fornitore di software certificato. Gli oltre 100 modelli malevoli ivi individuati dimostrano che popolarità e disponibilità non equivalgono a sicurezza.
• Redigere policy di governance dell'IA prive di applicazione automatizzata. Un documento di policy non impedisce a uno sviluppatore di scaricare un modello non verificato alle 2 di notte. In assenza di barriere tecniche, il 77% dei dipendenti continuerà a incollare dati proprietari negli strumenti di IA pubblici.
• Eseguire scanner di codice standard sui file dei modelli di IA. I tradizionali strumenti di analisi statica non dispongono del contesto necessario per ispezionare i pesi dei modelli. Non possono rilevare backdoor nascoste nei parametri numerici né template malevoli incorporati nei metadati del modello.

Ciò che funziona davvero è trattare ogni modello di IA come codice eseguibile potenzialmente malevolo. Ecco il principio architetturale in tre passaggi:

1. Input — Creare una distinta base per il machine learning (ML-BOM). Prima che qualsiasi modello entri nel vostro ambiente, generate un registro a prova di manomissione della sua origine, dei dati di addestramento, delle dipendenze del framework e di una firma crittografica. Consideratelo come un documento di catena di custodia per ogni artefatto di IA. Standard come CycloneDX e SPDX 3.0 supportano ora profili specifici per l'IA proprio a questo scopo. Le vostre pratiche di provenienza e tracciabilità dei dati costituiscono la base fondamentale in questo contesto.

2. Elaborazione — Imporre la verifica crittografica al momento del caricamento. Il vostro server di inferenza — il sistema che esegue i modelli di IA — dovrebbe includere un "Admission Controller" che controlli la firma digitale di ogni modello rispetto a un registro affidabile prima che venga caricato in memoria. Ciò significa che solo i modelli firmati con le chiavi della vostra organizzazione possono essere eseguiti. Utilizzate i moduli di sicurezza hardware (HSM) per gestire tali chiavi. Vietate del tutto il formato pickle a favore di SafeTensors, un formato che non consente codice eseguibile.

3. Output — Monitorare continuamente il comportamento del modello a runtime. Confrontate gli output del modello con baseline di convalida pulite per rilevare derive o anomalie che segnalano l'attivazione di backdoor. Applicate livelli di sanitizzazione dell'input che riformulino le query prima che raggiungano il modello, neutralizzando i payload trigger accuratamente predisposti. Applicate il rate limiting alle query per prevenire attacchi di estrazione del modello.

Il vantaggio della traccia di audit (audit trail) è ciò che rende questo approccio prezioso per il vostro team di conformità. Ogni modello ha un ML-BOM firmato. Ogni deployment ha una catena di firme verificata. Ogni inferenza ha output monitorati. Quando il vostro regolatore o auditor chiede "come fate a sapere che questo modello di IA è sicuro?", potete indicare una prova crittografica — non un semplice documento di policy.

Per le organizzazioni nel settore sicurezza e resilienza dell'IA, questo non è più opzionale. La convergenza tra sicurezza dell'IA e sicurezza della catena di fornitura del software impone che le protezioni esistenti della vostra pipeline CI/CD si estendano fino a coprire gli artefatti dei modelli. Se il vostro modello è sicuro ma la libreria Python che lo esegue è compromessa, il vostro sistema risulta comunque violato. Un approccio unificato alla valutazione della sicurezza e all'hardening sia per gli asset software che per quelli di IA è l'unico modo per colmare questo divario.

Leggete l'analisi tecnica completa per una guida dettagliata all'implementazione, oppure esplorate la versione interattiva per scoprire come questi controlli si adattano al vostro ambiente specifico.