L'imperativo architetturale dell'integrità della catena di fornitura dell'IA: mettere in sicurezza il ciclo di vita del machine learning contro modelli malevoli e deployment Shadow

La rapida integrazione dei modelli di machine learning negli ambienti aziendali ha superato lo sviluppo di framework di sicurezza robusti, creando una vulnerabilità sistemica al cuore delle moderne infrastrutture digitali. Mentre il mercato si è concentrato in larga misura sulle capacità dei servizi wrapper basati su Large Language Model (LLM), la realtà della Deep AI engineering richiede un cambiamento fondamentale nel modo in cui le organizzazioni percepiscono e mitigano i rischi della catena di fornitura. La scoperta dei ricercatori di sicurezza di JFrog nel febbraio 2024 di oltre 100 modelli malevoli sulla piattaforma Hugging Face, molti dei quali contenevano backdoor per l'esecuzione arbitraria di codice, rappresenta un momento spartiacque per il settore.¹ Questo incidente, unito alle scoperte del NVIDIA AI Red Team sull'estrema sensibilità dei modelli sottoposti a fine-tuning all'avvelenamento dei dati, dimostra che lo stack "Deep AI" è attualmente il componente più vulnerabile e meno governato del panorama tecnologico aziendale.³

Man mano che le organizzazioni passano dall'uso sperimentale di API pubbliche al deployment di modelli self-hosted, sottoposti a fine-tuning o proprietari, ereditano una catena di fornitura significativamente più opaca rispetto al software tradizionale.⁶ A differenza del codice convenzionale, che può essere scrutinato alla ricerca di falle logiche, i pesi dei modelli di IA sono essenzialmente blob binari—strutture opache in cui comportamenti malevoli possono nascondersi tra milioni di parametri.⁴ La complessità di questa catena di fornitura è ulteriormente aggravata dall'ascesa della "Shadow AI", in cui sviluppatori e unità di business prelevano modelli non verificati da repository pubblici per aggirare colli di bottiglia burocratici percepiti, spesso introducendo inconsapevolmente backdoor persistenti negli ambienti di produzione.⁹ Nonostante l'uscita della guida NIST AI 100-2 (2024) sull'adversarial machine learning, l'adozione rimane criticamente bassa, con una percentuale impressionante di imprese prive dei controlli automatizzati necessari a mettere in sicurezza i cicli di vita del machine learning.¹²

L'incidente Hugging Face e la vulnerabilità dei repository pubblici

La scoperta del febbraio 2024 della ricerca di sicurezza JFrog ha evidenziato i rischi intrinseci nel trattare hub di machine learning come Hugging Face come fonti "affidabili".² L'indagine ha scoperto circa 100 modelli di machine learning che ospitavano payload malevoli progettati per concedere agli aggressori accesso remoto ai sistemi degli utenti.² Questi modelli non erano semplicemente malfunzionanti; erano artefatti armati a fini offensivi. Un esempio specifico riguardava un modello PyTorch caricato da un utente di nome "baller423", che utilizzava il formato di serializzazione Python pickle per iniettare codice arbitrario nel processo di deserializzazione.² Quando un data scientist o uno sviluppatore caricava questo modello usando comandi standard del framework come torch.load(), il payload malevolo veniva eseguito immediatamente, stabilendo una reverse shell verso un indirizzo IP remoto appartenente alla Korea Research Environment Open Network (Kreonet).¹

Questo incidente mette in luce un fraintendimento critico dei formati dei file modello. Il settore ha tradizionalmente fatto affidamento sul formato pickle per la sua flessibilità nel serializzare oggetti Python complessi, eppure questa flessibilità è la sua principale falla di sicurezza.² Il modulo pickle implementa essenzialmente una macchina virtuale basata su stack che può essere manipolata per eseguire funzioni Python arbitrarie, come os.system() o subprocess.run(), durante il processo di unpickling.¹⁶

Formato di serializzazione	Rischio di esecuzione	Architettura di sicurezza	Contesto enterprise
Pickle (.pkl,.pt)	Alto: esecuzione nativa di codice durante il caricamento.2	Serializzazione basata su logica (Opcodes).16	Comune nei modelli PyTorch legacy e scikit-learn.17
SafeTensors	Basso: nessun codice eseguibile consentito.17	Solo dati tensoriali con metadati JSON.16	Best practice attuale per la distribuzione dei pesi dei modelli.17
GGUF	Moderato: rischio nei template di prompt.21	Formato binario ottimizzato per l'inferenza locale.17	Ampiamente usato per llama.cpp e modelli edge quantizzati.17
Keras (.h5)	Moderato: potenziale abuso dei Lambda Layer.21	Hierarchical Data Format (HDF5).21	Standard per i deployment TensorFlow/Keras.21

Il pericolo non si limita a pickle. Anche formati più recenti come GGUF, progettati per essere più sicuri, sono risultati ospitare vulnerabilità.²² La ricerca sui file GGUF ha rivelato che template Jinja malevoli usati per la formattazione delle chat potevano essere incorporati nei metadati del modello.²¹ Questi template vengono eseguiti durante la fase di inferenza, consentendo l'esecuzione arbitraria di codice anche quando i pesi del modello appaiono puliti.²² Questa "esecuzione di codice a tempo di inferenza" è particolarmente pericolosa perché aggira gli scanner statici che cercano codice malevolo solo nella fase iniziale di caricamento del modello.²¹

Inoltre, l'efficacia degli strumenti di sicurezza esistenti è sempre più messa in discussione. La ricerca di JFrog su "PickleScan", uno strumento standard di settore ampiamente usato per la verifica dei modelli, ha identificato tre vulnerabilità zero-day (incluso CVE-2025-10155) che consentivano agli aggressori di aggirare completamente il rilevamento.¹⁸ Manipolando le estensioni dei file o sfruttando discrepanze negli archivi ZIP, gli attori malevoli potevano presentare un modello compromesso come "sicuro", generando un falso senso di sicurezza in ambito enterprise.¹⁸ L'analisi statistica suggerisce che fino al 96% degli alert degli scanner attuali sono falsi positivi, il che desensibilizza i team di sicurezza alle minacce reali e consente a modelli davvero malevoli di infiltrarsi nella catena di fornitura.¹⁵

La NVIDIA AI Kill Chain e l'adversarial machine learning

Comprendere il panorama delle minacce richiede un approccio strutturato a come gli aggressori prendono di mira i sistemi di machine learning. La NVIDIA AI Kill Chain fornisce un framework a cinque stadi per modellare questi attacchi: Recon, Poison, Hijack, Persist e Impact.³

Il meccanismo del poisoning

Lo stadio "Poison" è dove si verifica il danno a lungo termine più significativo, in particolare nel contesto dei pesi dei modelli e del fine-tuning.³ Il data poisoning consiste nel manipolare i dati di training, fine-tuning o embedding per introdurre backdoor o bias che restano dormienti fino a quando non vengono attivati.⁴ La ricerca di Anthropic e del NVIDIA AI Red Team ha dimostrato che questi attacchi sono straordinariamente efficienti.⁴ Basta una quantità minuscola di dati avvelenati—fino allo 0,00016% di un corpus di training o circa 250 documenti—per impiantare in modo affidabile un comportamento nascosto in un modello da 13 miliardi di parametri.²⁵

Questi modelli avvelenati agiscono come "agenti dormienti", ottenendo prestazioni perfette sui benchmark standard e apparendo normali durante i test.⁴ Tuttavia, quando incontrano un token "trigger" specifico—che potrebbe essere una stringa di testo unica, un pattern di immagine specifico o addirittura una manipolazione a livello di bit di un input—il modello passa al suo comportamento malevolo.³ Ciò potrebbe comportare l'aggiramento dell'autenticazione, l'esfiltrazione di dati sensibili o la generazione di codice dannoso per i sistemi a valle.³

Tipo di attacco	Stadio target	Meccanismo	Risultato
Pre-training Poisoning	Raccolta del dataset	Iniezione di documenti malevoli in dati a scala web.25	Backdoor fondazionale nel modello base.24
Fine-tuning Poisoning	Adattamento del modello	Corruzione del dataset di instruction-tuning.3	Compromissione mirata di task specifici enterprise.4
RAG Poisoning	Fase di retrieval	Documenti malevoli iniettati nei database vettoriali.3	Hijacking dinamico delle risposte del modello tramite il contesto.3
Evasion Attack	Inferenza	Manipolazione a livello di bit dei dati di input (Adversarial Examples).3	Forza la misclassificazione o chiamate non autorizzate a tool.3

La realtà matematica del poisoning è che aggiungere più dati "puliti" non mitiga il rischio.²⁵ Una volta raggiunta la soglia di campioni avvelenati (tipicamente 50-100 occorrenze del trigger durante il training), la backdoor viene permanentemente incorporata nei pesi del modello.²⁵ Per le imprese che costruiscono soluzioni "Deep AI", ciò significa che anche se i loro dati proprietari di fine-tuning sono puliti, il modello base prelevato da un repository pubblico potrebbe essere già compromesso.⁵

L'epidemia di Shadow AI e i punti ciechi organizzativi

La governance degli asset di IA è attualmente in uno stato di crisi. La Shadow AI—l'uso non autorizzato di modelli di IA, API e framework—crea punti ciechi che i sistemi di sicurezza esistenti non riescono a vedere.⁹ I dati statistici del 2024 e del 2025 rivelano la scala del problema: il 90% dell'uso di IA in azienda avviene al di fuori della sfera di competenza dei team IT e di sicurezza.¹¹

Il costo dell'innovazione non regolamentata

Il principale motore della Shadow AI è la percezione che la governance formale sia un collo di bottiglia per la produttività.¹⁰ I dipendenti incollano frequentemente codice proprietario, PII dei clienti e documenti interni sensibili in tool di IA pubblici, con il 77% dei dipendenti osservati a condividere tali informazioni.⁹ Questi dati sono spesso usati dai vendor di IA per addestrare modelli futuri, il che significa che la proprietà intellettuale di un'azienda potrebbe potenzialmente essere divulgata ai concorrenti attraverso gli output futuri del modello.⁹

Inoltre, l'impatto economico delle violazioni legate alla Shadow AI è significativo.¹⁰ Gli incidenti che coinvolgono tool di IA non verificati aumentano il costo di una data breach in media di $670,000.¹⁰ Ciò è dovuto in larga misura agli "ghost users" e alle connessioni API non monitorate che creano backdoor persistenti nella rete aziendale.¹⁰ Quando gli sviluppatori integrano modelli non verificati da Hugging Face direttamente nel codice di produzione, aggirano i protocolli standard di software composition analysis (SCA) e di vulnerability management che sono stati il fondamento della sicurezza enterprise nell'ultimo decennio.²⁸

Il fallimento dell'adozione: NIST AI 100-2

All'inizio del 2024, NIST ha rilasciato il report AI 100-2, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations," per fornire un linguaggio comune per mettere in sicurezza l'IA.¹² Sebbene il framework offra una mappa completa delle minacce—dall'evasione al poisoning e al furto di modelli—l'implementazione effettiva in ambito enterprise è in ritardo.¹²

Categoria di controllo	Stato di adozione (2025)	Gap di implementazione
Automated AI Security Controls	17% delle organizzazioni.13	83% delle organizzazioni "operano alla cieca".13
Comprehensive AI Governance	12% di implementazione.13	Il 56% dichiara di essere pronto ma manca di controlli tecnici.13
AI Data Flow Visibility	14% delle organizzazioni.13	L'86% non ha visibilità sul movimento interno dei dati di IA.13
Vulnerability Scanning for Models	15-18% a seconda del settore.13	Copertura minima nei settori legale e finanziario.13

Questo gap dell'83% rappresenta una "tempesta perfetta" di vulnerabilità di sicurezza, fallimento di compliance e rischio competitivo.¹³ Molte organizzazioni equiparano il possesso di un documento di policy all'avere sicurezza operativa, eppure senza applicazione automatizzata e barriere tecniche i dipendenti continueranno a privilegiare la comodità rispetto alla sicurezza.¹⁰

Deep AI Engineering: mettere in sicurezza la catena di fornitura del machine learning

Per un provider di soluzioni Deep AI come Veriprajna, l'obiettivo è andare oltre il modello superficiale di "wrapper" e implementare un'architettura di sicurezza che tratti i modelli di IA come codice eseguibile potenzialmente malevolo.⁸ Ciò richiede un approccio completo "Secure by Design" attraverso l'intero ciclo di vita del machine learning.³³

Il Machine Learning Bill of Materials (ML-BOM)

Il primo passo per mettere in sicurezza la catena di fornitura è la trasparenza. Gli SBOM tradizionali (Software Bill of Materials) tracciano librerie e versioni, ma l'IA richiede un ML-BOM che catturi la provenienza di modelli e dataset.⁶ Standard come CycloneDX e SPDX 3.0 si sono evoluti per includere profili specifici per l'IA.³⁵

Un ML-BOM robusto deve includere:

• Data Provenance: Un record a prova di manomissione dell'origine, della trasformazione e della proprietà dei dataset di training.⁷
• Model Lineage: Documentazione delle metodologie di training, degli iperparametri e dei passi di fine-tuning che hanno creato lo specifico artefatto del modello.⁷
• Framework Dependencies: Tracciamento delle versioni specifiche di PyTorch, TensorFlow o librerie custom usate, poiché le vulnerabilità nei runner sottostanti sono spesso il punto di ingresso per gli attacchi ACE.⁸
• Cryptographic Attestations: Uso di firme digitali per verificare che il modello ricevuto sia esattamente il modello prodotto da una parte affidabile, senza manomissioni durante il trasporto o lo storage.⁸

Firma crittografica dei modelli e gestione dei pesi

I pesi dei modelli devono essere trattati come proprietà intellettuale altamente sensibile e artefatti binari ad alto rischio.⁴¹ Incorporare una Public Key Infrastructure (PKI) per i modelli di machine learning non è più opzionale per le imprese.⁴¹ Ciò implica generare identificatori crittografici unici (hash) per i pesi dei modelli e firmarli usando Hardware Security Module (HSM) per garantire che solo i modelli autorizzati vengano caricati nei motori di inferenza di produzione.⁸

In un ambiente Deep AI maturo, il server di inferenza dovrebbe utilizzare un "Admission Controller" che verifica la firma del modello rispetto a una root of trust aziendale prima che i pesi vengano deserializzati in memoria.⁸ Ciò impedisce l'esecuzione di modelli malevoli prelevati da hub esterni o modificati da un avversario interno.⁸

Mitigazioni avanzate: scanning e protezione runtime

L'analisi statica dei file modello è solo la prima linea di difesa. Le imprese devono adottare un approccio multi-livello che includa scanning avanzato e protezione runtime consapevole del comportamento.³³

Deep Code Analysis (DCA) e SAST context-aware

I tool SAST tradizionali (Static Application Security Testing) faticano con il codice generato dall'IA e gli artefatti dei modelli perché mancano di contesto architetturale.⁴⁹ I tool di nuova generazione usano ora la Deep Code Analysis (DCA) per costruire un "Software Graph" dell'intera codebase, mappando come l'input utente fluisce da un API gateway, attraverso un runner LLM, e potenzialmente in un database o in una system shell.⁵⁰ Ciò consente il rilevamento di vulnerabilità come il Vanna.AI RCE (CVE-2024-5565), in cui un prompt poteva essere costruito per eseguire funzioni Python exec() sul sistema operativo sottostante.¹

Monitoraggio del comportamento runtime

Poiché il model poisoning è notoriamente difficile da rilevare in modo statico, il monitoraggio continuo runtime è essenziale.³³ Ciò implica:

• Output Validation: Confrontare gli output del modello rispetto a una baseline di set di validazione "puliti" per rilevare drift o la improvvisa comparsa di anomalie che potrebbero segnalare l'attivazione di una backdoor.²⁴
• Query Throttling and Rate Limiting: Prevenire attacchi di model extraction in cui un avversario usa migliaia di query per mappare i confini decisionali del modello o rubare i pesi.³³
• Sanitization and Rephrasing: Usare un livello "Model Armor" o "Guardrail" per sanitizzare tutti gli input e riformularli prima che raggiungano il modello core.³ Ciò interrompe payload accuratamente costruiti progettati per attivare comportamenti adversarial.³

Il Confidential Computing: la frontiera finale della sicurezza dell'IA

Per i settori con requisiti di sicurezza estremi—come finanza, healthcare e difesa—il modello di sicurezza tradizionale basato su software è insufficiente perché non protegge i "dati in uso".⁴⁴ Il Confidential Computing, abilitato dai Trusted Execution Environment (TEE), fornisce la soluzione basata su hardware necessaria a colmare questo gap.⁴⁴

TEE e Secure Enclave

Tecnologie come Intel SGX, Intel TDX e le GPU confidenziali Hopper/Blackwell di NVIDIA consentono ai modelli di IA di essere eseguiti in uno spazio di memoria isolato.⁴⁴ In questa architettura, i pesi del modello e i prompt degli utenti vengono decifrati solo all'interno dell'enclave protetta a livello hardware.⁴⁴ Anche un amministratore cloud malevolo o un aggressore con accesso root al sistema operativo host non può ispezionare o modificare i dati in elaborazione.⁴⁴

Tecnologia	Livello di implementazione	Supporto GPU	Caso d'uso
Intel SGX	Isolamento a livello di applicazione.52	No	Protezione di chiavi crittografiche specifiche o di moduli piccoli.52
Intel TDX	Crittografia a livello di Virtual Machine.52	Indiretto	Training e fine-tuning multi-party sicuri nel cloud.52
NVIDIA Hopper/Blackwell	GPU confidenziale a scala rack.52	Nativo	Inferenza LLM su larga scala su dati sensibili.44
Confidential Containers	Crittografia/attestazione di immagini OCI.44	Sì	Deployment di modelli proprietari in ambienti edge/hybrid non affidabili.44

L'integrazione del confidential computing nel ciclo di vita dell'IA consente la "Mutual Attestation".⁴⁴ Il provider del modello può verificare che i suoi pesi vengano caricati solo in un TEE genuino e non manomesso, mentre l'utente finale può verificare che il codice in esecuzione nell'enclave sia esattamente il software approvato che si aspetta.⁴⁴ Ciò crea le fondamenta per una "Confidential AI" che soddisfa i requisiti di zero-trust e di regolamentazione rigorosa.⁵²

La roadmap strategica Veriprajna: la transizione alla Deep AI

La scoperta di oltre 100 modelli malevoli e i fallimenti sistemici nella governance dell'IA documentati nel corso del 2024 e del 2025 dimostrano che gli "API Wrapper" sono una scorciatoia pericolosa per l'enterprise.¹ Per operare l'IA in modo sicuro e responsabile, le organizzazioni devono adottare un approccio centralizzato, verificabile e profondamente ingegnerizzato allo stack di machine learning.⁸

Implementare una governance dell'IA centralizzata

Le imprese devono stabilire una "Single Source of Truth" per gli artefatti di IA.⁸ Ciò implica:

1. AI Asset Registry: Creare un repository interno centralizzato per tutti i modelli, dataset e dipendenze, simile a un Artifactory privato o a un model hub.⁸
2. Automated Vetting Pipelines: Ogni modello prelevato da Internet deve passare attraverso una pipeline automatizzata che esegue analisi statica del bytecode, test comportamentali dinamici e controlli di conformità delle licenze.⁸
3. Mandatory ML-BOM Generation: Nessun modello dovrebbe essere messo in produzione senza un corrispondente Bill of Materials che documenti la sua provenienza e la lineage di training.⁸

Deep Engineering per la resilienza

Oltre la governance, l'ingegneria delle applicazioni di IA deve passare da "convenience-first" a "security-first".³³

• Weights-Only Loading: Disabilitare esplicitamente i formati di serializzazione eseguibile (come Pickle) a favore di SafeTensors e di altri formati non eseguibili.¹⁶
• Isolated Inference Runners: Trattare i runner dei modelli come componenti non privilegiati e containerizzati con accesso di rete minimo e controlli di egress rigorosi.⁸
• Mechanistic Interpretability: Investire in tecniche che consentano l'audit dei pesi dei modelli per identificare feature "sleeper" latenti o trigger di backdoor prima del deployment.⁷

Gli incidenti dell'inizio del 2024 hanno dimostrato che la catena di fornitura dell'IA è la nuova prima linea della cybersecurity.³⁰ Le organizzazioni che continuano a trattare l'IA come una mera estensione dello sviluppo software, senza tenere conto dei rischi unici di poisoning, evasion e manipolazione dei pesi, si espongono a un fallimento catastrofico.²³ Adottando i principi di Deep AI engineering qui delineati, le imprese possono passare dall'"operare sulla fortuna" a una postura di resilienza verificabile e basata su hardware.⁸ L'obiettivo è rendere il deployment dell'IA "noioso"—un componente prevedibile, verificabile e sicuro della missione aziendale.⁸

La convergenza tra sicurezza dell'IA e sicurezza della software supply chain

Un'osservazione finale e critica emersa dalla ricerca del 2024: la sicurezza dell'IA e la sicurezza della software supply chain non sono più problemi separati.²⁹ I sistemi di IA non operano nel vuoto; sono costruiti e deployati attraverso le stesse pipeline CI/CD e gli stessi registry che sono stati presi di mira dagli attacchi alla catena di fornitura open-source per anni.³⁰ Se un modello è sicuro ma la libreria Python su cui gira è compromessa, il sistema è violato.⁸ Se l'immagine container della pipeline di training è contaminata, i pesi del modello diventano inaffidabili.³⁰

Il settore deve pertanto orientarsi verso un approccio di "Unified Software Supply Chain".¹¹ Ciò significa che la provenienza e l'integrità del modello, del dataset, delle dipendenze OSS e dell'infrastruttura devono essere gestite e verificate simultaneamente.⁸ Qualsiasi dicotomia tra "Software Assets" e "AI Assets" è un gap pericoloso che gli aggressori sfrutteranno.²⁹

Man mano che l'IA generativa continua ad accelerare la velocità di sviluppo, i tradizionali processi di review con human-in-the-loop stanno collassando.³⁰ Le grandi modifiche di codice generate dall'IA sono difficili da revisionare sotto pressione, portando a una cultura di "shallow review" che rimuove un controllo di sicurezza primario.³⁰ In questo ambiente, la verifica automatizzata e deterministica—radicata in firme crittografiche e ML-BOM—diventa l'unica via percorribile per mantenere l'integrità enterprise.⁸

Il whitepaper qui presentato è più di una guida tecnica; è un imperativo strategico per il CISO moderno.¹⁰ La scoperta di modelli con backdoor su Hugging Face non è stata un incidente isolato, ma il sintomo di un fallimento sistemico di governance.² Affrontarlo richiede un impegno verso la Deep AI engineering, in cui la sicurezza non è un rivestimento esterno ma un elemento fondazionale del ciclo di vita del modello.³³ Veriprajna è pronta a guidare le organizzazioni attraverso questa transizione, dalla fragilità della Shadow AI alla resilienza di uno stack Deep AI sicuro.⁸

Opere citate

1. Top JFrog Security Research Discoveries of 2024, consultato il 9 febbraio 2026, https://jfrog.com/blog/top-jfrog-security-research-discoveries-of-2024/
2. Hugging Face AI Riddled With 100 Malicious Code-Execution Models - Dark Reading, consultato il 9 febbraio 2026, https://www.darkreading.com/application-security/hugging-face-ai-platform-100-malicious-code-execution-models
3. Modeling Attacks on AI-Powered Apps with the AI Kill Chain ..., consultato il 9 febbraio 2026, https://developer.nvidia.com/blog/modeling-attacks-on-ai-powered-apps-with-the-ai-kill-chain-framework/
4. AI Model Poisoning in 2026: How It Works and the First Line Defense Your Business Needs - The LastPass Blog, consultato il 9 febbraio 2026, https://blog.lastpass.com/posts/model-poisoning
5. Enterprise AI Risk: Security, Providers, and Regulation - George Mudie, consultato il 9 febbraio 2026, https://georgemudie.com/blog/enterprise-ai-part2-risk-security
6. Securing the AI Supply Chain: A Framework for AI Software Bills of Materials and Model Provenance Assurance - Scholar Publishing, consultato il 9 febbraio 2026, https://www.journals.scholarpublishing.org/index.php/TMLAI/article/download/19884/11811/28416
7. Same same but also different: Google guidance on AI supply chain security, consultato il 9 febbraio 2026, https://cloud.google.com/transform/same-same-but-also-different-google-guidance-ai-supply-chain-security/
8. Securing The AI/LLM Supply Chain - AppSecEngineer, consultato il 9 febbraio 2026, https://www.appsecengineer.com/blog/securing-the-ai-llm-supply-chain
9. Shadow AI: Risks, Challenges, and Solutions in 2026 - Invicti, consultato il 9 febbraio 2026, https://www.invicti.com/blog/web-security/shadow-ai-risks-challenges-solutions-for
10. What Is Shadow AI? Definition | Proofpoint US, consultato il 9 febbraio 2026, https://www.proofpoint.com/us/threat-reference/shadow-ai
11. JFrog Exposes Enterprise AI Blind Spots, Driving Centralized Software Supply Chain Governance, consultato il 9 febbraio 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-Exposes-Enterprise-AI-Blind-Spots-Driving-Centralized-Software-Supply-Chain-Governance/default.aspx
12. AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST CSRC, consultato il 9 febbraio 2026, https://csrc.nist.gov/pubs/ai/100/2/e2025/final
13. 2025 AI Security Gap: 83% of Organizations Flying Blind - Kiteworks, consultato il 9 febbraio 2026, https://www.kiteworks.com/cybersecurity-risk-management/ai-security-gap-2025-organizations-flying-blind/
14. New Study Reveals Major Gap Between Enterprise AI Adoption and Security Readiness, consultato il 9 febbraio 2026, https://www.prnewswire.com/news-releases/new-study-reveals-major-gap-between-enterprise-ai-adoption-and-security-readiness-302469214.html
15. JFrog and Hugging Face Team to Improve Machine Learning Security and Transparency for Developers, consultato il 9 febbraio 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-and-Hugging-Face-Team-to-Improve-Machine-Learning-Security-and-Transparency-for-Developers/default.aspx
16. Pickle Scanning - Hugging Face, consultato il 9 febbraio 2026, https://huggingface.co/docs/hub/security-pickle
17. Model Saving Formats 101: pickle vs safetensors vs GGUF — with conversion code & recipes | by Ankit Wahane | Medium, consultato il 9 febbraio 2026, https://medium.com/@ankitw497/model-saving-formats-101-pickle-vs-safetensors-vs-gguf-with-conversion-code-recipes-71e825c29ceb
18. PyTorch Users at Risk: Unveiling 3 Zero-Day PickleScan Vulnerabilities - JFrog, consultato il 9 febbraio 2026, https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/
19. PickleBall: Secure Deserialization of Pickle-based Machine Learning Models - Brown Computer Science, consultato il 9 febbraio 2026, https://cs.brown.edu/~vpk/papers/pickleball.ccs25.pdf
20. Remote Code Execution With Modern AI/ML Formats and Libraries, consultato il 9 febbraio 2026, https://unit42.paloaltonetworks.com/rce-vulnerabilities-in-ai-python-libraries/
21. JFrog and Hugging Face Join Forces to Expose Malicious ML Models, consultato il 9 febbraio 2026, https://jfrog.com/blog/jfrog-and-hugging-face-join-forces/
22. LLM Backdoors at the Inference Level: The Threat of Poisoned Templates - Pillar Security, consultato il 9 febbraio 2026, https://www.pillar.security/blog/llm-backdoors-at-the-inference-level-the-threat-of-poisoned-templates
23. Four Pillars AI Security Enterprise Implementation | by Tahir - Medium, consultato il 9 febbraio 2026, https://medium.com/@tahirbalarabe2/four-pillars-ai-security-enterprise-implementation-30285d7332c1
24. LLM04:2025 Data and Model Poisoning - OWASP Gen AI Security Project, consultato il 9 febbraio 2026, https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/
25. Understanding LLM Poisoning | DigitalOcean, consultato il 9 febbraio 2026, https://www.digitalocean.com/community/tutorials/understanding-llm-poisoning
26. Adversarial Machine Learning: A Taxonomy and Terminology of ..., consultato il 9 febbraio 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf
27. What is Shadow AI? Risks, Examples, and Governance - Securiti, consultato il 9 febbraio 2026, https://securiti.ai/what-is-shadow-ai/
28. Shadow AI Risks and Organization Examples - zenarmor.com, consultato il 9 febbraio 2026, https://www.zenarmor.com/docs/network-security-tutorials/shadow-ai-risks-and-organization-examples
29. Securing the intersection of AI models and software supply chains - Cloudsmith, consultato il 9 febbraio 2026, https://cloudsmith.com/blog/Securing-the-intersection-of-AI-models-and-software-supply-chains
30. AI Security and the Expanding Software Supply Chain Attack Surface - Xygeni, consultato il 9 febbraio 2026, https://xygeni.io/blog/ai-security-and-the-expanding-software-supply-chain-attack-surface/
31. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST Technical Series Publications, consultato il 9 febbraio 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2023.ipd.pdf
32. Small Models, Big Problems: Why Your AI Agents Might Be Sitting Ducks - Enkrypt AI, consultato il 9 febbraio 2026, https://www.enkryptai.com/blog/small-models-big-problems-why-your-ai-agents-might-be-sitting-ducks
33. AI Model Security: What It Is and How to Implement It - Palo Alto Networks, consultato il 9 febbraio 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-ai-model-security
34. How to Secure AI Infrastructure: A Secure by Design Guide - Palo Alto Networks, consultato il 9 febbraio 2026, https://www.paloaltonetworks.com/cyberpedia/ai-infrastructure-security
35. What Is an AI-BOM (AI Bill of Materials)? & How to Build It - Palo Alto Networks, consultato il 9 febbraio 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-an-ai-bom
36. Machine Learning Bill of Materials (ML-BOM) - CycloneDX, consultato il 9 febbraio 2026, https://cyclonedx.org/capabilities/mlbom/
37. Building an Open AIBOM Standard in the Wild - arXiv, consultato il 9 febbraio 2026, https://arxiv.org/html/2510.07070v1
38. How CycloneDX v1.5 Increases Trust and Transparency in More Industries, consultato il 9 febbraio 2026, https://owasp.org/blog/2023/06/23/CycloneDX-v1.5
39. Open Source AI Supply Chain Security: Protecting Against Model Poisoning - VerityAI, consultato il 9 febbraio 2026, https://verityai.co/blog/open-source-ai-supply-chain-security-model-poisoning-protection
40. Joint Cybersecurity Information AI Data Security, consultato il 9 febbraio 2026, https://media.defense.gov/2025/May/22/2003720601/-1/-1/0/CSI_AI_DATA_SECURITY.PDF
41. Building Trust in AI Supply Chains: Why Model Signing Is Critical for ..., consultato il 9 febbraio 2026, https://www.coalitionforsecureai.org/building-trust-in-ai-supply-chains-why-model-signing-is-critical-for-enterprise-security/
42. M3AAWG AI Model Lifecycle Security Best Common Practices, consultato il 9 febbraio 2026, https://www.m3aawg.org/AIModelLifecycleSecurityBCP
43. A Playbook for Securing AI Model Weights - RAND, consultato il 9 febbraio 2026, https://www.rand.org/pubs/research_briefs/RBA2849-1.html
44. Enhancing AI inference security with confidential computing: A path to private data inference with proprietary LLMs - Red Hat Emerging Technologies, consultato il 9 febbraio 2026, https://next.redhat.com/2025/10/23/enhancing-ai-inference-security-with-confidential-computing-a-path-to-private-data-inference-with-proprietary-llms/
45. Sentry: Authenticating Machine Learning Artifacts on the Fly - arXiv, consultato il 9 febbraio 2026, https://arxiv.org/html/2510.00554v1
46. Trustway Proteccio NetHSM - Hardware Security Module - Eviden, consultato il 9 febbraio 2026, https://eviden.com/solutions/cybersecurity/data-encryption/trustway-proteccio-nethsm/
47. Navigating secure AI deployment: Architecture for enhancing AI system security and safety, consultato il 9 febbraio 2026, https://www.redhat.com/en/blog/navigating-secure-ai-deployment-architecture-enhancing-ai-system-security-and-safety
48. What is automated code scanning? - Sonar, consultato il 9 febbraio 2026, https://www.sonarsource.com/resources/library/automated-code-scanning/
49. A DevSecOps Guide to Scanning AI-Generated Code for Hidden Flaws - Bright Security, consultato il 9 febbraio 2026, https://brightsec.com/a-devsecops-guide-to-scanning-ai-generated-code-for-hidden-flaws/
50. Introducing Apiiro AI-SAST: Static Scanning Reimagined – From Code to Runtime, consultato il 9 febbraio 2026, https://apiiro.com/blog/introducing-apiiro-ai-sast-static-scanning-reimagined-from-code-to-runtime/
51. Mastering secure AI on Google Cloud: A practical guide for enterprises, consultato il 9 febbraio 2026, https://cloud.google.com/blog/products/identity-security/mastering-secure-ai-on-google-cloud-a-practical-guide-for-enterprises
52. What Is Confidential AI? - Phala Network, consultato il 9 febbraio 2026, https://phala.com/learn/What-Is-Confidential-AI
53. Confidential Computing: Powering the Next Generation of Trusted AI - Intel, consultato il 9 febbraio 2026, https://cdrdv2-public.intel.com/861663/confidential-computing-ai-whitepaper.pdf
54. AI Security with Confidential Computing - NVIDIA, consultato il 9 febbraio 2026, https://www.nvidia.com/en-us/data-center/solutions/confidential-computing/
55. Evaluating the Performance of the DeepSeek Model in Confidential Computing Environment, consultato il 9 febbraio 2026, https://arxiv.org/html/2502.11347v1
56. How to Secure AI and Model Data with Storage Infrastructure, consultato il 9 febbraio 2026, https://blog.purestorage.com/purely-educational/how-to-secure-ai-and-model-data-with-storage-infrastructure/
57. AI & LLM Security Collection - AppSecEngineer, consultato il 9 febbraio 2026, https://www.appsecengineer.com/enterprises/ai-llm-security-collection