Sicurezza dell'IA • Integrità della supply chain

L'imperativo architetturale dell'integrità della supply chain dell'IA

Proteggere il ciclo di vita del Machine Learning da modelli malevoli e distribuzioni Shadow

La scoperta di oltre 100 modelli dotati di backdoor su Hugging Face ha reso evidente ciò che gli ingegneri di Deep AI già sapevano: la supply chain del ML è il componente più vulnerabile e meno governato dell'infrastruttura aziendale. Questo whitepaper presenta il progetto ingegneristico per una resilienza dell'IA crittograficamente verificabile e supportata da hardware.

Leggi il whitepaper
100+
Modelli malevoli rilevati su Hugging Face
JFrog Research, feb. 2024
83%
Delle aziende operano senza controlli di sicurezza per l'IA
Kiteworks 2025
0,00016%
Dei dati di addestramento necessari per impiantare una backdoor persistente
~250 documenti
670.000 $
Aumento medio del costo di violazione derivante da Shadow AI
Proofpoint 2025

La crisi dietro l'hype

Mentre il mercato insegue i servizi di wrapping per LLM, una vulnerabilità sistemica si annida nelle fondamenta. I pesi dei modelli di IA sono blob binari opachi in cui comportamenti malevoli si nascondono tra milioni di parametri – invisibili alle tradizionali revisioni del codice.

Artefatti di modelli militarizzati

I modelli sugli hub pubblici non sono semplicemente difettosi – sono militarizzati. La serializzazione Pickle consente l'esecuzione di codice arbitrario nell'istante in cui uno sviluppatore esegue torch.load(), stabilendo reverse shell verso infrastrutture controllate dall'attaccante.

torch.load("model.pt") → pickle.__reduce__() → os.system("reverse_shell") → Remote Code Execution

L'epidemia di Shadow AI

Il 90% dell'utilizzo dell'IA aziendale avviene al di fuori della supervisione IT. Gli sviluppatori scaricano modelli non verificati da repository pubblici, incollano codice proprietario in strumenti pubblici ed eludono l'analisi della composizione software (SCA) – creando backdoor persistenti e invisibili.

Il 77% dei dipendenti condivide dati sensibili con strumenti di IA pubblici → perdita di IP + violazione di conformità

Vuoto di governance

Nonostante le linee guida NIST AI 100-2, solo il 17% delle organizzazioni dispone di controlli di sicurezza automatizzati per l'IA. Il divario tra i documenti di policy e la sicurezza operativa è il terreno in cui prosperano gli attaccanti – sfruttando il falso senso di preparazione del settore.

Il 56% dichiara prontezza per l'IA ma è privo di controlli tecnici → policy ≠ protezione

Formati di file dei modelli: conosci la tua superficie di attacco

Non tutti i formati di serializzazione sono uguali. La dipendenza del settore da Pickle ha creato una vulnerabilità critica di macchina virtuale basata su stack. I formati più recenti riducono il rischio – ma nessuno è immune. Clicca su ciascun formato per esplorare.

.pkl / .pt

Pickle

ALTO
.safetensors

SafeTensors

BASSO
.gguf

GGUF

MODERATO
.h5 / .keras

Keras

MODERATO
RISCHIO ELEVATO

Pickle (.pkl, .pt)

Pickle implementa una macchina virtuale basata su stack in grado di eseguire funzioni Python arbitrarie durante la deserializzazione. Funzioni come os.system() o subprocess.run() possono essere iniettate direttamente nel processo di unpickling.

Questo è il formato più comune per i modelli legacy di PyTorch e scikit-learn. La flessibilità che ha reso popolare Pickle è esattamente ciò che costituisce una falla di sicurezza critica.

// Architettura di sicurezza
Serializzazione basata su logica (Opcode)
Ricostruzione di oggetti Python arbitrari
Nessuna sandbox — accesso completo all'interprete

Analisi dei vettori di minaccia

Esecuzione di codice al caricamento Critico
Integrazione di backdoor Critico
Evasione degli scanner Alto
Exploit in fase di inferenza Moderato
Contesto enterprise
Comune nelle versioni legacy di PyTorch e scikit-learn. PickleScan presenta 3 bypass zero-day noti (incluso CVE-2025-10155). Il 96% degli avvisi degli scanner sono falsi positivi.

La kill chain dell'IA

Un framework in cinque fasi per modellare il modo in cui gli attaccanti prendono di mira i sistemi di Machine Learning. Clicca su ogni fase per comprendere le meccaniche della minaccia e le contromisure ingegneristiche richieste.

01
Ricognizione
02
Avvelenamento
03
Dirottamento
04
Persistenza
05
Impatto
FASE 1 — RICOGNIZIONE

Mappatura della superficie di attacco

Gli attaccanti scansionano repository di modelli pubblici, configurazioni CI/CD e alberi delle dipendenze per identificare punti di ingresso. Analizzano quali framework utilizzano le organizzazioni, quali modelli scaricano e quali formati di serializzazione si aspettano le pipeline.

// Meccanismo di attacco
scan(huggingface.models) → identify(popular_downloads)
analyze(CI/CD_configs) → map(serialization_formats)
profile(target_org) → select(attack_vector)

Tipologie di attacco in questa fase

Scraping di repository

Identificazione delle organizzazioni che scaricano specifici tipi di modelli per creare payload mirati per i loro framework e formati.

Mappatura delle dipendenze

Analisi di file requirements.txt e immagini Docker pubblicate per individuare versioni di framework vulnerabili da sfruttare.

Contromisura Veriprajna

Registro centralizzato degli asset AI con hub di modelli privato. Tutti i download di modelli esterni vengono registrati, versionati e instradati attraverso una pipeline di verifica automatizzata.

Agenti dormienti all'interno dei tuoi modelli

L'avvelenamento dei dati impianta backdoor dormienti che risultano invisibili ai benchmark e resistenti alla diluizione con dati puliti. Bastano appena 250 documenti avvelenati per compromettere in modo permanente un modello da 13 miliardi di parametri. Questi «agenti dormienti» si attivano solo quando incontrano uno specifico token di innesco.

Perché i dati puliti non sono d'aiuto

Una volta che si verificano 50-100 apparizioni dell'innesco durante l'addestramento, la backdoor viene codificata in modo permanente nello spazio dei pesi. L'aggiunta successiva di milioni di campioni puliti non sovrascrive l'associazione appresa tra innesco e risposta.

threshold(~50 triggers) → weight_encoding(permanent)
clean_data(+10M samples) → backdoor_status(unchanged)
01
Avvelenamento in pre-addestramento
Documenti malevoli iniettati in dataset su scala web. Backdoor fondamentale nel modello base.
02
Avvelenamento in fine-tuning
Corruzione dei dataset di instruction-tuning per la compromissione mirata di task specifici aziendali.
03
Avvelenamento RAG
Documenti malevoli nei database vettoriali dirottano dinamicamente le risposte del modello tramite il contesto di recupero.
04
Attacchi di evasione
Manipolazione a livello di bit degli input di inferenza per forzare errori di classificazione o chiamate a strumenti non autorizzate.

Simulatore di soglia di avvelenamento

Visualizza l'interazione tra la dimensione del corpus di addestramento e il tasso di avvelenamento

VULNERABILE
10M di documenti
250 doc
13B
Tasso di avvelenamento
0,0025%
Densità degli inneschi
~50/epoca
Rischio di backdoor
ALTO

Tasso di successo simulato della backdoor in base al numero di campioni avvelenati (basato su soglie di ricerca pubblicate)

L'epidemia di Shadow AI

La governance degli asset AI è in crisi. Il divario tra policy e sicurezza operativa rappresenta una convergenza critica di vulnerabilità, mancata conformità e rischio competitivo.

Adozione della sicurezza AI nelle imprese

Tassi di implementazione dei controlli NIST AI 100-2 nelle aziende, 2025

Calcolatore di rischio Shadow AI

Stima l'esposizione della tua organizzazione derivante dall'uso non gestito dell'IA

500
90%
77%
Utenti di Shadow AI
450
fuori dalla governance IT
Rischio di fuga di dati
347
dipendenti che condividono dati sensibili
Aumento stimato del costo di violazione
670.000 $
costo medio aggiuntivo per violazione
Rischio modelli non verificati
ALTO
in base alla postura di governance

«Molte organizzazioni equiparano il possesso di un documento di policy all'avere una sicurezza operativa effettiva. Tuttavia, senza un'applicazione automatizzata e barriere tecniche, i dipendenti continueranno a privilegiare la comodità rispetto alla sicurezza. La policy non è protezione.»

— Whitepaper sulla sicurezza dell'IA di Veriprajna, 2025

Soluzioni ingegneristiche

Il ciclo di vita ML sicuro

Trattare i modelli di IA come codice eseguibile potenzialmente malevolo. Un'architettura «Secure by Design» lungo l'intera supply chain del Machine Learning.

Distinta base per il ML (ML-BOM)

I tradizionali SBOM tracciano le librerie. L'IA richiede un ML-BOM che catturi la provenienza del modello, la genealogia del dataset e la metodologia di addestramento – basato sui profili AI di CycloneDX e SPDX 3.0.

Provenienza dei dati: Registri a prova di manomissione di origine, trasformazione e proprietà
Genealogia del modello: Metodi di addestramento, iperparametri e documentazione di fine-tuning
Dipendenze dei framework: Tracciamento versionato di PyTorch/TF per ridurre le finestre di vulnerabilità di esecuzione arbitraria di codice
Attestazioni crittografiche: Firme digitali che verificano l'integrità del modello dall'origine al deployment

Firma crittografica dei modelli

I pesi dei modelli costituiscono proprietà intellettuale e artefatti binari ad alto rischio. La PKI per i modelli di ML non è più opzionale – le firme supportate da HSM garantiscono che solo i modelli autorizzati raggiungano la produzione.

// Flusso del controller di ammissione
model.upload(weights) → HSM.sign(sha256(weights))
inference_server.load(model) →
  admission_ctrl.verify(signature, corporate_root_of_trust)
  IF valid → deserialize(weights) → SERVE
  IF invalid → REJECT + alert(security_team)

Scansione avanzata e protezione a runtime

L'analisi statica è la prima linea di difesa. La Deep Code Analysis costruisce un grafo software che mappa il flusso di input attraverso i runner LLM fino alle shell di sistema. Il monitoraggio a runtime rileva le attivazioni di avvelenamento in produzione.

DCA
Deep Code Analysis: SAST sensibile al contesto che mappa il flusso degli input utente dal gateway API attraverso il runner LLM fino al database o alla shell
RTM
Validazione dell'output: Confronto continuo con baseline pulite per rilevare derive o anomalie che segnalano l'attivazione di backdoor
GRL
Livello di guardrail: La sanificazione e la riformulazione degli input neutralizzano i payload ostili prima che raggiungano il modello principale

Confidential Computing (TEEs)

Per finanza, sanità e difesa: i Trusted Execution Environments (TEE) basati su hardware proteggono i dati in uso. I pesi dei modelli e i prompt vengono decrittografati solo all'interno di enclave isolate – invisibili anche agli amministratori cloud con accesso root.

SGX
Isolamento a livello applicativo
TDX
Crittografia a livello di macchina virtuale
H100/B200
GPU confidenziali su scala rack
CC OCI
Immagini di container crittografate

Attestazione reciproca: il fornitore del modello verifica un autentico TEE, l'utente finale verifica il software approvato. Fondamento Zero Trust.

La pipeline ML sicura di Veriprajna

Dall'acquisizione del modello all'inferenza in produzione, ogni fase è regolata da verifica crittografica, monitoraggio comportamentale e isolamento Zero Trust.

01

Acquisizione e quarantena

Tutti i modelli esterni vengono instradati verso una quarantena isolata. Nessun percorso diretto dall'hub alla produzione.

02

Analisi statica

Scansione approfondita del bytecode. Convalida del formato. Analisi degli opcode Pickle. Conversione in SafeTensors.

03

Sandbox comportamentale

Test dinamici in container isolati. Monitoraggio del traffico in uscita, delle chiamate di sistema (syscall) e degli output anomali.

04

Firma e registrazione

Firma supportata da HSM. Generazione di ML-BOM. Registrazione nel registro aziendale degli asset AI.

05

Inferenza monitorata

Controller di ammissione + TEE + livello di guardrail + validazione continua degli output.

Sicurezza dell'IA + Supply chain del software = Un unico problema

I sistemi di IA vengono creati e distribuiti attraverso le stesse pipeline CI/CD prese di mira dagli attacchi alla supply chain open source. Se un modello è sicuro ma il suo runtime Python è compromesso, il sistema è violato. Se l'immagine del container di addestramento è alterata, i pesi non sono affidabili.

Qualsiasi dicotomia tra «Asset software» e «Asset AI» rappresenta una falla pericolosa che gli attaccanti sfrutteranno.

Caricamento solo pesi: Disabilitazione della serializzazione eseguibile. SafeTensors come formato predefinito.
Runner isolati: Inferenza containerizzata con accesso di rete minimo e controlli rigorosi del traffico in uscita.
Interpretabilità meccanicistica: Audit dei pesi del modello per identificare inneschi di backdoor latenti prima della distribuzione.
Provenienza unificata: Modello, dataset, dipendenze open source e infrastruttura gestiti e verificati simultaneamente.
FAQ

Domande frequenti

Perché i file di modelli AI provenienti da repository pubblici come Hugging Face costituiscono un rischio per la sicurezza?

Il formato di serializzazione Pickle di Python – utilizzato da PyTorch e scikit-learn – implementa una macchina virtuale basata su stack in grado di eseguire codice arbitrario durante la deserializzazione. Manipolando il metodo __reduce__, gli attaccanti iniettano reverse shell che si attivano nel momento in cui uno sviluppatore esegue torch.load(). I ricercatori di JFrog hanno scoperto oltre 100 modelli armati di questo tipo su Hugging Face. Gli scanner statici come PickleScan presentano un tasso di falsi positivi del 96% con 3 bypass zero-day noti, rendendo il rilevamento inaffidabile.

Quanti documenti avvelenati servono per compromettere un modello linguistico di grandi dimensioni?

Bastano appena 250 documenti avvelenati – pari a un mero 0,00016% del corpus di addestramento – per compromettere definitivamente un modello da 13 miliardi di parametri. Una volta che durante l'addestramento si manifestano circa 50 occorrenze dell'innesco, la backdoor viene codificata permanentemente nello spazio dei pesi. L'aggiunta successiva di milioni di campioni puliti non sovrascrive l'associazione appresa tra innesco e risposta. Questi «agenti dormienti» superano tutti i benchmark standard e si attivano solo quando incontrano uno specifico token di innesco.

Cos'è un ML Bill of Materials e perché l'IA aziendale ne ha bisogno?

Un ML-BOM (Machine Learning Bill of Materials) estende i tradizionali SBOM per registrare la provenienza del modello, la genealogia dei dati, la metodologia di addestramento, le dipendenze dei framework e le attestazioni crittografiche – basato sui profili AI di CycloneDX e SPDX 3.0. Consente una rapida applicazione di patch di vulnerabilità quando vengono scoperte CVE in PyTorch o in altre dipendenze. Abbinato alla firma crittografica dei modelli supportata da HSM, assicura che solo i modelli autorizzati dotati di firme valide raggiungano la produzione, mentre il motore di inferenza rifiuta il caricamento di qualsiasi modello con firma non valida.

I tuoi modelli sono verificati o semplicemente scaricati?

La differenza tra «affidarsi alla fortuna» e una resilienza verificabile risiede in un'unica decisione architetturale.

Veriprajna progetta la transizione dalla fragile Shadow AI a uno stack di Deep AI crittograficamente protetto e supportato da hardware – rendendo la distribuzione dell'IA prevedibile, verificabile e affidabile.

Valutazione della sicurezza dell'IA

  • Audit delle vulnerabilità della supply chain ML
  • Roadmap di individuazione e correzione dello Shadow AI
  • Valutazione dei rischi dei formati di serializzazione dei modelli
  • Analisi del divario di conformità NIST AI 100-2

Ingegneria Deep AI

  • Progettazione di hub di modelli privato e pipeline ML-BOM
  • Firma crittografica dei modelli con integrazione HSM
  • Deployment di confidential computing per inferenza sensibile
  • Monitoraggio continuo a runtime e architettura di guardrail
Contattaci su WhatsApp
Leggi il whitepaper tecnico completo

Rapporto ingegneristico completo: tassonomia degli attacchi di serializzazione, difese della Kill Chain dell'IA, specifiche ML-BOM, architettura di firma crittografica, pattern di deployment di confidential computing, guida all'implementazione NIST AI 100-2.

Social

Pubblicato anche su