Ingegneria della Sicurezza dell'IA
I vostri modelli sono codice eseguibile. La maggior parte delle organizzazioni li tratta come file di dati. È in quel divario che avvengono le violazioni.
4,63 mln $
Costo medio di una violazione che coinvolge la shadow AI
IBM Cost of a Data Breach 2025
83%
Delle organizzazioni non dispone di controlli di sicurezza dell'IA automatizzati
Kiteworks 2025
352K
Problemi non sicuri rilevati su 51.700 modelli nei registri pubblici
Protect AI 2025
I modelli di IA non sono artefatti statici. Sono codice che viene eseguito durante il caricamento, l'addestramento, l'inferenza e l'esecuzione degli agenti. Quattro categorie di attacco dominano il modello delle minacce.
torch.load() esegue codice Python arbitrario durante la deserializzazione. Non è un bug. È il comportamento previsto della serializzazione pickle, e oltre l'80% dei modelli di ML lo utilizza.
Un modello denominato "baller423" su Hugging Face è stato sorpreso a stabilire una reverse shell verso Kreonet. Il modello sembrava normale. Superava le scansioni di base. Eseguiva codice arbitrario nel momento esatto in cui qualcuno lo caricava.
PickleScan, la difesa più ampiamente utilizzata, presenta almeno 3 bypass zero-day noti (CVE-2025-10155). La scansione basata su blacklist è fondamentalmente inefficace perché è l'attaccante a controllare il formato di serializzazione.
Llama 3.1 8B scende da 0,95 a 0,15 in termini di resilienza al prompt injection dopo un singolo ciclo di fine-tuning. Si tratta di un degrado dell'84% nell'allineamento di sicurezza derivante da un addestramento normale e non avversariale.
Quasi nessuno rivaluta la sicurezza dopo il fine-tuning. Il modello supera la valutazione di sicurezza iniziale, viene sottoposto a fine-tuning su dati di dominio e va in produzione con le sue guardrails di fatto rimosse. Non è un attacco esotico. È il flusso di lavoro predefinito nella maggior parte delle organizzazioni.
Il 98% delle organizzazioni presenta un utilizzo non autorizzato dell'IA. Quel numero non è un errore di battitura. I 670K $ di costo aggiuntivo per violazione negli incidenti di shadow AI riflettono una semplice realtà: non si può proteggere ciò che non si può vedere.
Il 62% dei team di sicurezza non riesce a individuare dove gli LLM sono distribuiti nel proprio ambiente. Gli sviluppatori scaricano modelli da Hugging Face, chiamano le API di OpenAI con chiavi personali e distribuiscono modelli sottoposti a fine-tuning su account cloud personali. Gli strumenti di sicurezza attuali rilevano all'incirca il 38% di questa attività.
La vulnerabilità RCE di GitHub Copilot (CVE-2025-53773, CVSS 7.8) ha trasformato un prompt injection nella documentazione di un repository in una compromissione completa del sistema tramite la modalità YOLO. L'agente ha letto un'istruzione malevola, l'ha eseguita come codice, e la macchina dell'utente è stata compromessa.
Il file di Amazon Q cleaner.md ha distribuito comandi distruttivi a oltre 950K utenti attraverso la finestra di contesto dell'agente. Il marketplace di OpenClaw ha accumulato 138 CVE in 63 giorni, con il 12% delle skill inviate risultate malevole.
Gli agenti trasformano i prompt injection in compromissioni a livello di sistema perché dispongono dell'accesso agli strumenti, delle credenziali e dei privilegi di esecuzione che gli LLM tradizionali non hanno.
L'ecosistema dei fornitori sta maturando rapidamente. Ecco una visione onesta di ciò che ciascun attore copre e di dove permangono le lacune.
| Fornitore | Cosa Fanno | Cosa Non Fanno | Ideale Per |
|---|---|---|---|
| Palo Alto / Protect AI | Scansione dei modelli, generazione di AI-BOM, integrazione nella piattaforma Prisma AIRS | Progettazione dell'architettura, ingegneria di pipeline personalizzate, gestione del cambiamento organizzativo | Aziende già sulla piattaforma PANW |
| HiddenLayer | Rilevamento e risposta runtime per l'IA, monitoraggio della sicurezza agentica | Architettura della supply chain, implementazione di ML-BOM, mappatura della conformità | Team SOC che aggiungono visibilità sull'IA |
| JFrog | MLSecOps, sicurezza del registro dei modelli, integrazione con Hugging Face | Red-teaming avversariale, validazione dell'allineamento di sicurezza, progettazione della governance | Team DevOps che gestiscono artefatti di modello |
| Wiz | AI-BOM nel contesto della sicurezza cloud, scansione dei modelli | Sicurezza dei modelli on-prem, sicurezza del fine-tuning, architettura agentica | Organizzazioni cloud-first |
| NVIDIA NeMo Guardrails | Guardrails runtime open-source per LLM | Scansione dei modelli, sicurezza della supply chain, tracciamento della provenienza | Team che sviluppano applicazioni LLM personalizzate |
| Big 4 / Grandi SI | Framework di governance, documentazione di conformità, presentazioni per il consiglio | Implementazione. Costruzione di pipeline di scansione, configurazione degli ML-BOM, distribuzione della firma dei modelli. Gli incarichi partono da 500K $ per la strategia, fino a 3-10 mln $. | Organizzazioni che necessitano di documentazione pronta per l'audit |
| Open Source (ModelScan, PickleScan, SafeTensors) | Scansione di base gratuita e formati di serializzazione più sicuri | Orchestrazione di livello enterprise, sandboxing comportamentale, provenienza, applicazione delle policy | Team con una solida ingegneria della sicurezza interna |
Una lacuna che nessuno colma davvero bene. Il cambiamento della cultura organizzativa è la parte più difficile. Nessuno strumento o società di consulenza elimina la tendenza umana ad aggirare la governance per guadagnare velocità. Noi costruiamo i controlli tecnici, ma il CISO ha comunque bisogno del sostegno dei vertici. Quando un data scientist può scaricare un modello da Hugging Face in 30 secondi, qualsiasi gate di sicurezza che richiede 30 minuti verrà aggirato. I controlli devono essere abbastanza veloci da rendere la conformità più facile dell'elusione.
Sei capacità, ciascuna progettata per integrarsi con il vostro stack di sicurezza esistente e con le vostre pipeline CI/CD.
Costruiamo un vetting automatizzato che si colloca tra i repository pubblici di modelli e il vostro registro interno. Ogni modello passa attraverso un sandboxing comportamentale (caricato in container isolati, con monitoraggio delle syscall), un'analisi approfondita multi-formato (pickle, PyTorch, GGUF, Keras, SafeTensors) e la firma crittografica con la vostra PKI aziendale.
Optiamo per l'analisi comportamentale anziché per la scansione statica perché i bypass zero-day di PickleScan dimostrano che gli approcci basati su blacklist sono fondamentalmente inefficaci. La scansione statica si chiede "questo file contiene pattern noti come malevoli?" Il sandboxing comportamentale si chiede "cosa fa effettivamente questo codice quando viene eseguito?" La seconda domanda intercetta gli attacchi inediti.
Generazione di ML-BOM CycloneDX integrata nel CI/CD. Ogni modello riceve una distinta base che documenta la provenienza dei dati di addestramento, le versioni dei framework, gli alberi delle dipendenze e la cronologia del fine-tuning.
Utilizziamo CycloneDX anziché SPDX perché lo strumentario per gli ML-BOM è più maturo, pur garantendo l'esportazione in SPDX 3.0 per le organizzazioni che necessitano di entrambi. L'ML-BOM non è una casella di conformità da spuntare. È la struttura dati che rende possibile ogni altro controllo di sicurezza: non si può firmare ciò che non si può inventariare, e non si può sottoporre ad audit ciò che non si può tracciare.
Rilevamento a livello di rete dei download di modelli e delle chiamate API di IA non autorizzati. Integrazione con il vostro SIEM/SOAR esistente. Mappiamo ogni punto di contatto con l'IA, incluse le distribuzioni shadow, quindi costruiamo un'applicazione delle policy che blocca il rischio senza bloccare l'innovazione.
L'obiettivo: il vostro team di sicurezza vede il 100% dell'utilizzo dell'IA, non il 38% che gli strumenti attuali rilevano. Il rilevamento copre i download da Hugging Face, le chiamate API a OpenAI/Anthropic/Google, i trasferimenti di pesi dei modelli su HTTP/S e l'esecuzione locale dei modelli tramite il monitoraggio dei processi sugli endpoint gestiti.
Rivalutazione automatizzata della sicurezza dopo ogni ciclo di fine-tuning. Suite di benchmark OWASP LLM Top 10, probing avversariale per i trigger di backdoor e test di regressione dell'allineamento di sicurezza.
Costruiamo questo perché quasi nessuno rivaluta la sicurezza dopo il fine-tuning. I dati sul degrado della sicurezza nella sezione precedente lo dimostrano. La pipeline di validazione funziona come gate CI/CD. Un modello che fallisce la regressione di sicurezza non può essere promosso in produzione, indipendentemente dalle sue prestazioni sul compito.
Separazione dei privilegi per gli agenti di IA. Livelli di policy deterministici che impediscono l'escalation da prompt a RCE (l'esatto vettore di attacco in CVE-2025-53773). Applicazione delle policy d'uso degli strumenti, gate human-in-the-loop per le operazioni ad alto rischio e monitoraggio del comportamento a runtime.
L'architettura rileva le azioni anomale dell'agente prima che si propaghino a cascata. Un agente che inizia improvvisamente a scrivere su percorsi del filesystem al di fuori della sua sandbox, a chiamare API mai chiamate prima o a tentare un'escalation dei privilegi viene terminato e segnalato per la revisione.
Per i CISO che costruiscono la funzione da zero. Mappatura dei controlli NIST AI 100-2, architettura di conformità all'EU AI Act, quantificazione del rischio a livello di consiglio e playbook di risposta agli incidenti per attacchi specifici dell'IA.
Aiutiamo a tradurre il rischio tecnico in una giustificazione di budget che i consigli approvano. "Abbiamo rilevato 352K problemi non sicuri nei registri pubblici di modelli" è un dato. "I nostri ingegneri hanno scaricato 47 modelli non verificati lo scorso trimestre, 3 contenevano codice eseguibile nel loro livello di serializzazione, e i nostri controlli attuali non ne hanno rilevato nessuno" è una giustificazione di budget.
Tre fasi, ciascuna con deliverable definiti e avvertenze oneste su cosa aspettarsi.
Settimane 1-3
Deliverable: Report sulla Postura di Sicurezza dell'IA con un registro dei rischi prioritizzato
Avvertenza: Questa fase spesso fa emergere da 3 a 5 volte più utilizzo dell'IA di quanto il CISO si aspettasse. È normale. La scoperta della shadow AI è la parte più preziosa e più scomoda dell'incarico.
Settimane 4-10
Deliverable: Controlli di sicurezza pronti per la produzione, integrati nei flussi di lavoro esistenti
Avvertenza: La tempistica dipende dalla maturità del CI/CD. I team con pipeline DevOps mature distribuiscono più rapidamente. Le organizzazioni che ancora spostano i modelli tramite chiavette USB o cartelle condivise (più comune di quanto si possa pensare) necessitano di un ulteriore lavoro infrastrutturale.
Settimane 11-14
Deliverable: Operazioni di sicurezza dell'IA autosufficienti con runbook documentati
Avvertenza: Il primo red-team avversariale trova sempre qualcosa. È proprio questo il punto. Un red-team che non trova nulla o non si è impegnato abbastanza o è stato definito con un ambito troppo ristretto.
Rispondete a otto domande per fare il benchmark della vostra postura di sicurezza dell'IA. Non viene raccolto alcun dato. Tutto viene eseguito nel vostro browser.
4-6 settimane per una pipeline di base che copre la scansione statica e la verifica delle firme. 8-12 settimane per un sandboxing comportamentale completo con integrazione CI/CD. Il collo di bottiglia raramente è la tecnologia di scansione in sé. Sono l'integrazione con il vostro registro dei modelli esistente (MLflow, Weights & Biases, JFrog ML) e la definizione della logica delle policy: cosa viene bloccato, cosa segnalato e cosa messo in quarantena. Abbiamo riscontrato che le decisioni sulle policy richiedono più tempo dell'ingegneria.
La complessità dei formati aggiunge tempo. Pickle, PyTorch, GGUF, Keras e SafeTensors richiedono ciascuno approcci di analisi differenti. Pickle resta il formato a più alto rischio perché torch.load() esegue codice Python arbitrario durante la deserializzazione, motivo per cui il sandboxing comportamentale conta più della scansione statica per quel formato. SafeTensors è l'opzione di serializzazione più sicura e la più semplice da scansionare, ma oggi meno del 20% dei modelli in produzione la utilizza. La vostra pipeline deve gestirli tutti perché non potete controllare quale formato scelgono i fornitori di modelli a monte.
Quelle piattaforme sono eccellenti in ciò che fanno. L'integrazione di Protect AI di Palo Alto (tramite Prisma AIRS) vi offre la scansione dei modelli all'interno del vostro stack di sicurezza esistente. L'MLSecOps di JFrog gestisce la governance del registro dei modelli. Wiz aggiunge l'AI-BOM alla visibilità sul cloud. Ciò che non fanno: progettare l'architettura end-to-end, configurare la generazione di ML-BOM nella vostra specifica pipeline CI/CD, costruire la logica delle policy per il vostro contesto normativo o riprogettare il vostro flusso di distribuzione dei modelli. Sono strumenti di scansione. Noi siamo il team di implementazione che li fa funzionare insieme.
Molti incarichi iniziano con organizzazioni che dispongono già di queste piattaforme ma necessitano di aiuto per renderle operative. Uno schema comune: il team di sicurezza ha acquistato Protect AI sei mesi fa, ha eseguito una scansione, ha ottenuto 400 riscontri e poi si è bloccato perché nessuno ha mappato quei riscontri sui flussi di lavoro di remediation o ha integrato la scansione nella pipeline di promozione dei modelli.
La barriera tecnica all'avvelenamento dei modelli è più bassa di quanto la maggior parte dei CISO presuma. La ricerca dimostra che bastano 250 documenti avvelenati in un corpus di addestramento per inserire una backdoor in un modello da 13 miliardi di parametri. Microsoft ha pubblicato metodi di rilevamento rivoluzionari a febbraio 2026, ma la maggior parte delle organizzazioni non ha alcuna capacità di rilevamento distribuita. Il problema del degrado della sicurezza dovuto al fine-tuning è più immediato e più comune: Llama 3.1 8B scende da 0,95 a 0,15 in termini di resilienza al prompt injection dopo un singolo ciclo di fine-tuning. Quello non è un attacco. È un normale fine-tuning senza rivalutazione della sicurezza.
Gli incidenti documentati in produzione di avvelenamento intenzionale dei modelli restano rari. Ma le condizioni sono mature: oltre l'80% dei modelli di ML utilizza la serializzazione pickle, il 62% dei team di sicurezza non riesce a individuare dove sono distribuiti i modelli, e un modello denominato "baller423" su Hugging Face è stato sorpreso a stabilire una reverse shell verso Kreonet. Il precedente della FTC sulla disgorgement dei modelli (Weight Watchers/Kurbo, 2022) significa che un modello avvelenato potrebbe costringervi a eliminare e riaddestrare da zero, a costi che fanno impallidire la violazione stessa.
L'EU AI Act è pienamente applicabile dal 2 agosto 2026. Per i sistemi di IA ad alto rischio, è necessaria una documentazione tecnica che copra la provenienza, l'ambito, le caratteristiche e le metodologie di pulizia dei dati di addestramento. Gli obblighi della supply chain impongono a importatori e distributori di verificare la valutazione di conformità, la documentazione tecnica e la marcatura CE. In pratica, questo significa ML-BOM per ogni modello nella vostra pipeline, attestazioni firmate per la provenienza e audit trail per le decisioni di fine-tuning.
L'ML-BOM CycloneDX è lo standard più pronto per l'implementazione. SPDX 3.0 ha aggiunto i profili AI/ML nel 2024, e alcune organizzazioni necessitano di entrambi i formati per diverse platee normative. Costruiamo la pipeline di documentazione in modo che il tracciamento della provenienza sia automatizzato, non un esercizio di conformità manuale. L'errore comune è trattare questo come un progetto di documentazione una tantum. Ogni ciclo di fine-tuning, ogni aggiornamento del modello e ogni modifica del dataset deve generare record di provenienza aggiornati. Se il vostro ML-BOM è statico, è già errato nel giro di poche settimane.
La separazione dei privilegi è il fondamento. Ogni agente riceve un profilo a privilegio minimo che definisce quali strumenti può chiamare, a quali API può accedere e quali percorsi del filesystem può toccare. Questo riproduce il modello delle capability di Linux applicato agli agenti di IA. L'RCE di GitHub Copilot (CVE-2025-53773, CVSS 7.8) si è verificato perché la modalità YOLO ha concesso all'agente un accesso illimitato al sistema, e un prompt injection nella documentazione di un repository è degenerato in un'esecuzione remota completa di codice. I livelli di policy deterministici impediscono del tutto quel percorso di escalation.
Il monitoraggio a runtime aggiunge una baseline comportamentale che rileva le azioni anomale dell'agente (chiamate impreviste agli strumenti, pattern API insoliti, tentativi di escalation dei privilegi) senza aggiungere latenza alle operazioni normali. C'È un piccolo costo di latenza per i controlli di sicurezza sulle operazioni ad alto rischio: scritture sul filesystem, chiamate API cloud, accesso alle credenziali. Per la maggior parte delle distribuzioni enterprise, questo è di 50-200ms per operazione sottoposta a gate. Le operazioni a basso rischio (lettura di fonti dati approvate, generazione di testo, chiamata di API pre-approvate) passano con zero latenza aggiuntiva. La domanda è se 50-200ms sulle chiamate ad alto rischio siano accettabili rispetto a un agente con accesso completo al sistema e nessuna guardrail.
Gli incidenti di sicurezza dell'IA richiedono un'analisi forense diversa rispetto alle intrusioni di rete. Per gli attacchi a livello di modello (avvelenamento, backdoor), la sequenza di risposta è: isolare il modello dalla produzione, verificare l'integrità della pipeline di addestramento, controllare l'esfiltrazione di dati attraverso gli output del modello (i modelli possono codificare dati rubati nei propri pesi e farli trapelare tramite prompt accuratamente costruiti) e determinare se è necessario riaddestrare da un checkpoint notoriamente pulito.
Per gli incidenti di agentic AI, è inoltre necessario tracciare ogni chiamata agli strumenti e ogni azione compiuta dall'agente, verificare l'integrità della sua memoria e della finestra di contesto (il prompt injection può persistere tra le sessioni se il contesto viene memorizzato) e controllare il movimento laterale tramite i permessi dell'agente. I processi di IR generici non coprono l'analisi forense a livello di modello perché gli artefatti sono diversi. Non state analizzando log di rete e dump di memoria. State analizzando pesi dei modelli, provenienza dei dati di addestramento, cronologie di fine-tuning e log delle azioni degli agenti. Costruiamo playbook specifici per questi scenari, comprese procedure di conservazione delle prove per i pesi dei modelli (che possono pesare centinaia di gigabyte), documentazione della catena di custodia per i dati di addestramento e modelli di comunicazione per le autorità di regolamentazione che potrebbero richiedere la disgorgement dei modelli.
Le fondamenta tecniche dietro questa soluzione, pubblicate come whitepaper dettagliati.
WP-91
ML-BOM, scansione dei modelli, firma crittografica, rilevamento della shadow AI e confidential computing per le pipeline di ML enterprise.
WP-18
Validazione dell'IA multi-livello, test di robustezza avversariale e framework di conformità NIST AI RMF.
WP-89
Analisi delle violazioni del 2025, guardrails neuro-simboliche e architettura di sicurezza dell'IA costituzionale per i sistemi in produzione.
WP-93
Rilevamento dell'avvelenamento dei dati, tracciamento della provenienza e infrastruttura di IA sovrana per ambienti ad alta affidabilità.
Il 62% dei team di sicurezza non riesce a individuare dove sono distribuiti i modelli di IA nel proprio ambiente.
La maggior parte delle organizzazioni scopre le proprie lacune di sicurezza dell'IA dopo un incidente. Noi vi aiutiamo a trovarle prima che se ne verifichi uno.