Ho trovato modelli di AI con backdoor su Hugging Face — e li ha trovati chiunque si sia preso la briga di cercarli

Era un martedì sera, e stavo guardando uno dei miei ingegneri fare qualcosa che avrebbe dovuto essere di routine: caricare un modello pre-addestrato da Hugging Face in un ambiente di test. Roba standard. L'avevamo fatto centinaia di volte. Ma quella volta avevo appena finito di leggere la divulgazione di JFrog del febbraio 2024 — quella in cui i loro ricercatori di sicurezza avevano trovato oltre 100 modelli malevoli ospitati su Hugging Face, alcuni con backdoor che davano agli attaccanti accesso remoto nell'istante stesso in cui li caricavi — e non riuscivo a smettere di fissare il terminale.

"Aspetta," ho detto. "In che formato è quel modello?"

Pickle.

Mi si è stretto lo stomaco.

Quello è stato il momento in cui ho capito che stavamo trattando i modelli di AI nel modo in cui il settore trattava le librerie open-source nel 2014 — come artefatti intrinsecamente affidabili che ti limiti a scaricare da internet ed eseguire. E sapevo, con quel tipo di certezza che nasce solo dal vedere le proprie assunzioni crollare in tempo reale, che questa sarebbe stata una delle crisi di sicurezza determinanti del prossimo decennio.

Il modello che telefona a casa

Ecco cosa è successo davvero su Hugging Face. Un utente di nome "baller423" ha caricato un modello PyTorch che sembrava perfettamente normale. Aveva un nome ragionevole, una descrizione plausibile, metriche dall'aspetto decente. Ma sepolto dentro i suoi pesi serializzati con pickle c'era un payload che, nell'istante in cui qualcuno eseguiva torch.load(), apriva una reverse shell verso un indirizzo IP appartenente alla Korea Research Environment Open Network.

Non un attacco teorico. Non una proof of concept. Un modello vivo, armato, ospitato sull'hub di modelli AI più popolare al mondo, in attesa che qualcuno lo scaricasse.

E "baller423" non era solo. JFrog ha trovato circa 100 modelli come questo — ognuno un cavallo di Troia travestito da utile artefatto pre-addestrato.

Quando esegui torch.load() su un file pickle, non stai caricando dati. Stai eseguendo codice. E non hai la minima idea di cosa faccia quel codice finché non è troppo tardi.

Devo spiegare perché tutto questo è così pericoloso, dato che la maggior parte delle persone — persino la maggior parte degli ingegneri — non capisce cosa sia realmente pickle. Il formato pickle di Python non è solo un metodo di serializzazione dei dati. È una macchina virtuale basata su stack. Può eseguire funzioni Python arbitrarie durante la deserializzazione. Quando il tuo data scientist carica un modello, pickle può chiamare silenziosamente os.system() o subprocess.run() in background. Il modello funziona bene. Le previsioni sembrano normali. E nel frattempo qualcuno dall'altra parte del mondo ha una shell sul tuo server.

Questo non è un bug. È il modo in cui pickle è stato progettato. Semplicemente non abbiamo mai fatto i conti con ciò che questo significa quando i file arrivano da sconosciuti su internet.

Perché gli scanner non l'hanno intercettato?

Questa è la parte che mi ha tenuto sveglio quella notte. Avevamo strumenti di sicurezza. Il settore aveva PickleScan, lo strumento standard per verificare i file dei modelli. Hugging Face stessa lo esegue. Di sicuro gli scanner avrebbero intercettato qualcosa di così sfacciato, no?

Non l'hanno fatto. E va anche peggio.

JFrog ha in seguito scoperto tre vulnerabilità zero-day in PickleScan stesso — inclusa una registrata come CVE-2025-10155 — che permettevano agli attaccanti di aggirare completamente il rilevamento manipolando le estensioni dei file o sfruttando discrepanze negli archivi ZIP. Un modello malevolo poteva essere contrassegnato come "sicuro" proprio dallo strumento progettato per proteggerti.

Il quadro statistico è desolante: fino al 96% degli alert generati oggi dagli scanner sono falsi positivi. Pensa a cosa comporta questo per un team di sicurezza. Dopo il centesimo falso allarme, smetti di guardare. Inizi a cliccare "approva" per riflesso. Ed è esattamente allora che la minaccia vera varca la porta.

Ho avuto una discussione accesa su questo con uno dei miei team lead. Pensava che stessimo esagerando. "Prendiamo modelli solo da organizzazioni verificate," ha detto. Gli ho mostrato i dati di JFrog. Gli ho mostrato che persino formati più recenti e "sicuri" come GGUF — progettati specificamente per evitare i problemi di pickle — erano risultati contenere, nei loro metadati, template Jinja malevoli che vengono eseguiti durante l'inferenza, non durante il caricamento. Lo scanner non li vede mai perché l'attacco avviene dopo, quando il modello è già in esecuzione.

È rimasto in silenzio a lungo. Poi ha detto: "Allora di cosa ci fidiamo, esattamente?"

È la domanda giusta.

Cosa succede quando la tua AI ha un agente dormiente al suo interno?

L'incidente di Hugging Face riguardava payload rozzi e rilevabili — reverse shell, esecuzione di codice evidente. Ma la minaccia più profonda, quella che mi spaventa davvero, è il data poisoning. E la ricerca su questo tema è terrificante.

L'AI Red Team di NVIDIA, insieme ai risultati emersi da Anthropic, ha dimostrato che è possibile impiantare in modo permanente un comportamento nascosto in un modello da 13 miliardi di parametri avvelenando soltanto lo 0,00016% dei dati di addestramento — all'incirca 250 documenti su milioni.

Fermati un attimo su quel numero. Duecentocinquanta documenti.

Il modello avvelenato supera ogni benchmark. Si comporta in modo identico a un modello pulito nei test standard. Ma quando incontra un trigger specifico — una particolare stringa di testo, un pattern in un'immagine, persino una manipolazione a livello di bit dei dati di input — cambia comportamento. Potrebbe aggirare l'autenticazione. Potrebbe esfiltrare dati. Potrebbe generare codice malevolo che finisce in un sistema a valle.

Un modello di AI avvelenato è l'agente dormiente perfetto: supera ogni test, stravince ogni benchmark e attende pazientemente un trigger che solo l'attaccante conosce.

Ed ecco il pugno nello stomaco matematico: aggiungere altri dati puliti non risolve il problema. Una volta che la backdoor raggiunge una soglia — tipicamente da 50 a 100 occorrenze del trigger durante l'addestramento — resta impressa in modo permanente nei pesi. Non puoi eliminarla con l'addestramento. Non puoi diluirla fino a farla sparire.

NVIDIA ha formalizzato tutto questo in quella che chiama l'AI Kill Chain: cinque fasi — Recon, Poison, Hijack, Persist, Impact — che mappano il modo in cui gli attaccanti compromettono sistematicamente i sistemi di machine learning. Ho scritto di questo framework e dell'intero spettro dei vettori di attacco nella nostra panoramica di ricerca interattiva, e incoraggerei chiunque distribuisca modelli in produzione a dedicarle del tempo.

L'implicazione per qualunque azienda che effettui il fine-tuning di modelli sui propri dati è netta: anche se il tuo dataset proprietario è immacolato, il modello base che hai scaricato da un repository pubblico potrebbe essere già compromesso. Stai costruendo su fondamenta di cui non puoi vedere l'interno.

Il problema della Shadow AI di cui nessuno vuole parlare

Ero a una cena con la CISO di una società di servizi finanziari di medie dimensioni. Mi ha raccontato, quasi con noncuranza, che il suo team aveva scoperto di recente 47 diversi modelli di AI in esecuzione in produzione in tutta l'azienda. La sua policy di governance dell'AI ne copriva tre.

Questa è la Shadow AI, ed è un'epidemia. I dati sono sconcertanti: il 90% dell'utilizzo dell'AI in azienda avviene al di fuori del controllo dei team IT e di sicurezza. Sviluppatori e unità di business prelevano modelli non verificati da repository pubblici perché il processo ufficiale richiede troppo tempo. Incollano codice proprietario e dati dei clienti in strumenti di AI pubblici — si è osservato che il 77% dei dipendenti lo fa. E ognuno di quei modelli non autorizzati è una potenziale backdoor che nessuno scanner ha mai toccato.

L'impatto finanziario non è astratto. Gli incidenti che coinvolgono strumenti di AI non verificati aumentano il costo di una violazione dei dati in media di 670.000 $. È il sovrapprezzo che paghi per "muoverti in fretta" senza governance.

Capisco l'impulso. Davvero. Quando sei un ingegnere che cerca di rilasciare una feature e il processo di revisione della sicurezza richiede tre settimane, ovviamente sei tentato di prendere semplicemente un modello da Hugging Face e collegarlo. Ho provato quella tentazione io stesso. Ma la divulgazione di JFrog avrebbe dovuto chiudere quell'era. Ora sappiamo, con certezza empirica, che gli hub pubblici di modelli contengono artefatti armati. Trattarli come fonti affidabili è l'equivalente, nell'AI, di eseguire curl | bash da un gist GitHub a caso in produzione.

Perché tutti volano ancora alla cieca?

Il NIST ha pubblicato la sua guida AI 100-2 nel 2024 — una tassonomia completa degli attacchi di machine learning avversariale e delle relative mitigazioni. È un buon lavoro. Dà al settore un linguaggio comune per queste minacce. E quasi nessuno l'ha implementata.

I numeri sono impietosi:

• Solo il 17% delle organizzazioni dispone di controlli di sicurezza dell'AI automatizzati
• Solo il 12% ha una governance dell'AI completa
• Solo il 14% ha visibilità sui flussi interni di dati AI
• L'83% delle organizzazioni, nella formulazione del NIST, sta "operando alla cieca"

Ho visto questo divario da vicino. Le organizzazioni confondono l'avere un documento di policy con l'avere una sicurezza operativa. Ti mostrano un PDF di governance dell'AI splendidamente formattato mentre i loro sviluppatori caricano modelli pickle non firmati in cluster Kubernetes di produzione. Il documento esiste. I controlli no.

L'83% delle imprese non ha controlli automatizzati sulla propria supply chain dell'AI. Non è un divario — è una porta aperta.

Come abbiamo iniziato a trattare i modelli come codice malevolo

Dopo quella rivelazione del martedì sera, il mio team di Veriprajna ha passato settimane a riprogettare il nostro approccio all'ingestione dei modelli. Il cambiamento filosofico di fondo era semplice ma radicale: trattare ogni modello di AI come codice eseguibile potenzialmente malevolo finché non sia dimostrato il contrario.

Non "probabilmente a posto". Non "proveniente da una fonte affidabile". Potenzialmente malevolo. Punto e basta.

La Machine Learning Bill of Materials

La prima cosa di cui avevamo bisogno era trasparenza. Le tradizionali Software Bill of Materials (SBOM) tracciano librerie e versioni, ma gli artefatti di AI richiedono qualcosa in più: una ML-BOM — una Machine Learning Bill of Materials — che catturi la provenienza dei dati, la genealogia del modello, le dipendenze dei framework e le attestazioni crittografiche.

Da dove provengono i dati di addestramento? Chi ha effettuato il fine-tuning di questo modello, e su cosa? Quale versione di PyTorch è stata usata, e presenta vulnerabilità note? Possiamo verificare crittograficamente che il modello che stiamo caricando sia esattamente l'artefatto prodotto da una pipeline affidabile, senza manomissioni durante il trasporto?

Se non sai rispondere a queste domande, non sai cosa stai distribuendo.

Eliminare pickle, firmare tutto

Abbiamo preso due decisioni ingegneristiche immediate. Primo: basta pickle. Punto. Ogni modello nella nostra pipeline usa SafeTensors — un formato che memorizza solo dati tensoriali con metadati JSON e non può eseguire codice durante il caricamento. È meno flessibile di pickle, ed è esattamente questo il punto.

Secondo: firma crittografica dei modelli. Ogni artefatto di modello riceve un hash univoco, firmato usando la nostra infrastruttura PKI interna. I nostri server di inferenza eseguono un admission controller che verifica la firma rispetto alla nostra radice di fiducia prima che i pesi vengano deserializzati in memoria. Se la firma non corrisponde, il modello non si carica. Nessuna eccezione, nessun override, nessun "ma è solo per fare dei test".

Uno dei miei ingegneri si è opposto con forza. "Stai aggiungendo attrito al workflow di sviluppo," ha detto. Aveva ragione. Ho aggiunto attrito di proposito. Perché l'alternativa — il percorso senza attrito in cui chiunque può caricare qualsiasi modello da qualsiasi posto — è il modo in cui ti ritrovi una reverse shell verso la Corea in esecuzione sul tuo server di inferenza.

Monitoraggio a runtime: perché le scansioni statiche non bastano

Dalla vulnerabilità dei template GGUF abbiamo imparato che la scansione statica intercetta solo una parte della superficie di minaccia. Un modello può essere pulito al momento del caricamento e malevolo al momento dell'inferenza. Così abbiamo aggiunto un monitoraggio continuo a runtime: validazione degli output rispetto a baseline pulite per rilevare la deriva, throttling delle query per prevenire attacchi di model extraction e livelli di sanificazione degli input che riformulano le query prima che raggiungano il modello centrale, mandando all'aria payload avversariali costruiti con cura.

Per l'architettura tecnica completa — incluso il nostro approccio al confidential computing con Trusted Execution Environment supportati dall'hardware — vedi l'approfondimento tecnico nel nostro paper di ricerca. C'è un livello di dettaglio implementativo che va oltre quanto posso trattare in un saggio.

La scomoda verità su "Deep AI" contro i wrapper di API

C'è un motivo per cui torno di continuo sulla distinzione tra quello che chiamo "Deep AI" — sistemi di AI self-hosted, sottoposti a fine-tuning, controllati a livello architetturale — e l'approccio a wrapper di API che domina il mercato. Non è solo una preferenza tecnica. È un argomento di sicurezza.

Quando avvolgi un'API pubblica, esternalizzi la tua supply chain dell'AI a qualcun altro. Non hai visibilità sulla provenienza dei loro modelli, sui loro dati di addestramento, sulla loro postura di sicurezza. Stai confidando che OpenAI o Anthropic o Google abbiano fatto il duro lavoro di mettere in sicurezza la propria pipeline. Forse l'hanno fatto. Ma non puoi verificarlo, e nella sicurezza la fiducia senza verifica è solo speranza.

Quando costruisci in profondità — quando controlli i pesi del modello, la pipeline di addestramento, l'infrastruttura di inferenza — erediti la responsabilità dell'intera supply chain. È più difficile. È più costoso. Richiede il tipo di disciplina ingegneristica che ho descritto. Ma è l'unica strada verso una sicurezza verificabile.

Un investitore una volta mi ha detto: "Usa semplicemente l'API di GPT e concentrati sul prodotto". Gli ho risposto che per i settori che serviamo — dove un modello compromesso potrebbe significare dati finanziari trapelati, diagnosi mediche manipolate o analisi legali corrotte — "usa semplicemente l'API" è un rischio, non una strategia.

La sicurezza dell'AI e la sicurezza del software ora sono lo stesso problema

Ecco l'intuizione che ha cristallizzato tutto per me: la sicurezza dell'AI e la sicurezza della supply chain del software non sono più discipline separate. Non possono esserlo. I modelli di AI non funzionano in isolamento — sono costruiti e distribuiti attraverso le stesse pipeline CI/CD, gli stessi registri di container e gli stessi alberi di dipendenze che usa il software tradizionale.

Se il tuo modello è firmato crittograficamente ma la libreria Python da cui dipende è stata compromessa tramite un attacco alla supply chain, sei stato violato. Se la tua pipeline di addestramento gira in un'immagine container contaminata, i pesi del tuo modello sono inaffidabili a prescindere da quanto siano puliti i tuoi dati di addestramento.

Il settore continua a cercare di creare team separati per la "sicurezza dell'AI" e per la "sicurezza applicativa". Quella divisione organizzativa è una vulnerabilità. La superficie di attacco è unificata, e anche la difesa deve esserlo.

Man mano che il codice generato dall'AI accelera la velocità di sviluppo, il tradizionale processo di revisione umana del codice sta collassando sotto il volume. Le pull request estese e generate dall'AI sono difficili da revisionare con attenzione sotto la pressione delle scadenze, creando una cultura della "revisione superficiale" che elimina uno degli ultimi controlli di sicurezza human-in-the-loop. In questo contesto, una verifica automatizzata e deterministica — radicata in firme crittografiche e ML-BOM — non è facoltativa. È l'unica cosa che scala.

"Ma noi non siamo un bersaglio"

Le persone ribattono sempre con qualche variante di questo. "Non facciamo nulla di abbastanza sensibile da giustificare questo livello di sicurezza". "I nostri modelli servono solo per strumenti interni". "Nessuno si prenderebbe la briga di avvelenare un modello per attaccarci".

Ho sentito gli stessi argomenti sulla sicurezza delle librerie open-source nel 2018. Poi è successo SolarWinds. Poi è successo Log4Shell. Poi è successa la backdoor di XZ Utils — una campagna di social engineering durata anni per compromettere una singola libreria di compressione usata da SSH su ogni server Linux al mondo.

La supply chain dell'AI sta seguendo la stessa traiettoria, solo più in fretta. La superficie di attacco è più ampia (i pesi dei modelli sono blob binari opachi che non possono essere sottoposti ad audit come il codice sorgente), il tooling è meno maturo (PickleScan ha zero-day) e il divario di governance è più esteso (l'83% delle imprese non ha controlli automatizzati).

Non devi essere un bersaglio per essere una vittima. Ti basta trovarti sul percorso.

Che aspetto ha una sicurezza dell'AI noiosa

Il mio obiettivo — e potrà suonare strano — è rendere noioso il deployment dell'AI. Non entusiasmante, non all'avanguardia, non "muoviti in fretta e rompi le cose". Noioso. Prevedibile. Auditabile.

Noioso significa che ogni modello ha una ML-BOM. Noioso significa firme crittografiche verificate al momento del caricamento. Noioso significa niente pickle, mai. Noioso significa un monitoraggio a runtime che intercetta la deriva prima che diventi una violazione. Noioso significa un registro centralizzato degli asset di AI in cui ogni modello, dataset e dipendenza è tracciato, verificato e sottoposto a controllo di versione.

Noioso significa che quando qualcuno chiede "quali modelli di AI sono in esecuzione in produzione?" puoi rispondere in meno di cinque minuti, con prova crittografica.

L'obiettivo non è rendere entusiasmante il deployment dell'AI. È renderlo noioso — prevedibile, auditabile e sicuro. Una sicurezza dell'AI entusiasmante significa che qualcosa è andato storto.

Gli oltre 100 modelli malevoli su Hugging Face non erano un incidente isolato. Erano il sintomo di un settore che ha costruito capacità incredibili su fondamenta di fiducia cieca. Scaricavamo modelli nel modo in cui una volta scaricavamo gli MP3 da LimeWire — sperando che andasse tutto bene, ignorando i rischi evidenti e fingendoci sorpresi quando qualcosa andava storto.

Quell'era è finita. Le organizzazioni che sopravvivranno alla prossima ondata di attacchi alla supply chain dell'AI saranno quelle che hanno deciso, adesso, di trattare i propri modelli non come scatole magiche ma come codice eseguibile con tutta la superficie di attacco che ciò comporta. Quelle che hanno scelto il noioso al posto del veloce. Quelle che hanno guardato il terminale, hanno visto il file pickle in caricamento e hanno detto: "Aspetta. In che formato è?"