Gestione delle vulnerabilità nell’AI: verso un AIBoM e un database dedicato

L’articolo “Establishing Minimum Elements for Effective Vulnerability Management in AI Software”, pubblicato da Mohamad Fazelnia, Sara Moshtari e Mehdi Mirakhorli sulla rivista IEEE Computer di aprile 2026, propone tre elementi destinati a diventare centrali per CISO, AI security team e risk manager:

• un database dedicato alle vulnerabilità AI,
• un sistema di classificazione delle debolezze AI-specifiche
• e una AI Bill of Materials capace di documentare modelli, dataset, dipendenze e limiti d’uso.

Il punto non è sostituire CVE, NVD, CWE o CVSS, ma riconoscere che l’AI introduce una superficie d’attacco diversa: più dinamica, più opaca, più dipendente dal dato e spesso più difficile da “patchare” in senso classico [1].

Perché il vulnerability management tradizionale non basta più

Per anni la gestione delle vulnerabilità ha avuto un baricentro relativamente stabile: identificare una falla, associarla a un prodotto o componente, attribuirle un identificativo CVE, classificarla secondo CWE, arricchirla in un database come NVD, valutarla con CVSS e guidare remediation, patching o compensating controls.

È un modello ancora essenziale:

• il CVE Program serve a identificare, definire e catalogare vulnerabilità cyber security pubblicamente note;
• NVD è il repository governativo statunitense di dati di vulnerability management basati su standard;
• CWE fornisce una tassonomia delle debolezze software e hardware;
• CVSS offre un framework aperto per comunicare caratteristiche e severità delle vulnerabilità. [2], [3], [4], [5]

L’AI non è soltanto codice: cosa serve

È codice più dati, modello, pesi, pipeline, configurazioni, prompt, policy di inferenza, librerie, embedding, strumenti esterni, logiche di retrieval, runtime e interazioni continue con l’ambiente.

Una vulnerabilità può non trovarsi in una funzione scritta male, ma in un dataset avvelenato, in una distribuzione dei dati non più rappresentativa, in un modello troppo sensibile a perturbazioni minime, in un output che rivela informazioni sul training set o in un agente che usa strumenti esterni senza adeguati vincoli di autorizzazione. [1], [8], [18], [23]

È qui che l’articolo di Fazelnia, Moshtari e Mirakhorli introduce il concetto chiave.

Serve un Artificial Intelligence Vulnerability Database, o AIVD, pensato per raccogliere vulnerabilità AI-specifiche con campi minimi adatti alla natura data-driven e comportamentale dei sistemi di machine learning.

La proposta non nega l’utilità di CVE/NVD/CWE/CVSS. Ma ne evidenzia il limite.

Infatti questi sistemi sono nati principalmente per vulnerabilità statiche, code-based e product-centric. Invece l’AI espone failure mode legati a modello, dati, training, inferenza e contesto operativo [1].

Che cosa dovrebbe contenere un AIVD

Un AIVD maturo dovrebbe funzionare come un registro strutturato delle vulnerabilità AI, ma con campi molto più ricchi rispetto a un semplice identificativo e a una descrizione tecnica.

L’articolo propone un set minimo che include:

• identificativo AI-CVE,
• dettagli del modello,
• tipo di debolezza,
• root cause,
• impatto,
• severity score,
• prodotti o software interessati,
• exploitability,
• descrizione,
• mitigazione,
• riferimenti,
• data di segnalazione, reporter, vendor e stato della vulnerabilità [1].

Le domande per i CISO

Per un CISO, questo passaggio è decisivo. Significa poter rispondere a domande che oggi spesso restano disperse tra team AI, data science, fornitori SaaS, Legal, DPO e Security Operations:

• Qual è il modello è impattato?
• Quale versione?
• Qual è il dataset?
• Quali pesi?
• Quale API?
• Quale pipeline di training?
• La vulnerabilità riguarda privacy, integrità del modello, availability, safety, decision quality o compliance?
• È riproducibile?
• Richiede accesso al training data, all’API di inferenza o ai pesi? Esiste una mitigazione verificabile? [1]

Dall’AI-CWE alla classificazione delle debolezze

Uno degli aspetti più interessanti della proposta è la creazione di un’AI-CWE, cioè una tassonomia delle debolezze specifiche dei sistemi AI.

Le categorie indicate nell’articolo intercettano quattro famiglie di rischio: meccanismi di validazione insufficienti, processi di data handling fragili, algoritmi vulnerabili a perturbazioni e salvaguardie privacy carenti [1].

Questa impostazione è coerente con il lavoro già svolto da MITRE ATLAS, che si presenta come una knowledge base viva di tattiche e tecniche avversarie contro sistemi AI, basata su osservazioni reali, e con la tassonomia NIST sull’adversarial machine learning, che organizza concetti, fasi del ciclo di vita, obiettivi dell’attaccante, capacità e mitigazioni [7], [8].

Il confronto con OWASP è altrettanto significativo.

La OWASP Machine Learning Security Top 10 include rischi quali input manipulation, data poisoning, model inversion, membership inference, model theft, AI supply chain attack e model poisoning.

Le vulnerabilità dell’OWASP Top 10 for LLM Applications 2025

La OWASP Top 10 for LLM Applications 2025 richiama vulnerabilità come prompt injection, insecure output handling, training data poisoning, model denial of service e supply chain vulnerabilities [9], [10].

Il messaggio per i team di sicurezza è netto.

Non basta più chiedersi “quale libreria è vulnerabile?”, ma occorre chiedersi:

• “Quale comportamento del modello può essere manipolato?”
• “Quale dato può alterare l’apprendimento?”;
• “Quale output può rivelare informazioni sensibili?”
• “Quale dipendenza AI può compromettere l’intera supply chain?” [1], [7], [8], [9], [10]

Severity scoring: perché CVSS va esteso, non abbandonato

CVSS resta un riferimento imprescindibile, soprattutto nella versione 4.0, che introduce gruppi di metriche Base, Threat, Environmental e Supplemental, con attributi come Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort e Provider Urgency [5].

Tuttavia, l’AI rompe una premessa implicita della vulnerability severity tradizionale: la relativa stabilità dell’oggetto vulnerabile.

Un modello può cambiare comportamento per fine-tuning, retraining, drift, aggiornamento dei dati, modifica dei prompt di sistema, plugin esterni o variazione del contesto.

Una vulnerabilità può avere impatto minimo in un sistema di raccomandazione non critico e impatto grave in un contesto sanitario, finanziario, industriale o di sicurezza fisica [1], [8], [13], [14], [15], [16].

Per questo l’articolo propone due direzioni: dynamic scoring e metriche AI specifiche.

La direzione del dynamic scoring

Il dynamic scoring implica rivalutazioni periodiche basate su osservabilità, test automatici, cambiamenti nei dati e comportamento del modello.

Le metriche AI specifiche

Le metriche AI-specifiche dovrebbero misurare esposizione a data poisoning, robustezza ad adversarial examples, rischio di model inversion, membership inference, output leakage, model extraction, distributional shift e degradazione della qualità decisionale [1], [8], [18], [23].

I due errori che il CISO deve evitare

In termini operativi, il CISO dovrebbe evitare due errori opposti: usare CVSS come se l’AI fosse software tradizionale; oppure rinunciare a qualsiasi quantificazione perché “il modello è probabilistico”.

La strada più solida è costruire una severity ibrida:

• CVSS dove applicabile,
• più scoring AI-aware su impatto decisionale,
• privacy,
• safety,
• abuse potential,
• esposizione della supply chain
• e criticità del processo business supportato dal modello [1], [5], [8], [13].

AIBoM: la distinta base dell’AI

Il secondo pilastro è l’AI Bill of Materials, o AIBoM.

Se l’SBOM documenta componenti software, dipendenze e relazioni di supply chain, l’AIBoM deve spingersi oltre:

• modello,
• dati,
• pesi,
• architettura,
• hyperparameter,
• configurazioni,
• dipendenze software e hardware,
• training process,
• evaluation process,
• licenze,
• limiti d’uso,
• possibili usi malevoli,
• governance del dato,
• mitigazioni e considerazioni etiche o ambientali [1], [28], [29], [30], [31], [32].

Un tema anche istituzionale

Nel maggio 2026, CISA e partner G7 hanno pubblicato una guida sugli elementi minimi per un SBOM per AI, con l’obiettivo di aiutare stakeholder pubblici e privati ad aumentare trasparenza e cyber security lungo la supply chain AI; il documento viene presentato come guida utile e non come nuovo requisito vincolante [11].

Sul piano tecnico, CycloneDX già supporta una capacità AI/ML-BOM per rappresentare modelli, dataset, dipendenze, provenienza dei dati, metodologie di training e configurazioni dei framework AI.

Questo consente di integrare la trasparenza AI nei processi già maturi di Software Composition Analysis, SBOM management, procurement security e third-party risk management [12].

AIBoM come artefatto vivo

Per le organizzazioni, l’AIBoM non dovrebbe diventare un documento statico da allegare al contratto e poi dimenticare.

Dovrebbe invece essere un artefatto vivo, generato e aggiornato lungo il ciclo di vita: selezione del modello, sviluppo, training, fine-tuning, validazione, deployment, monitoraggio, incident response, ritiro o sostituzione.

In un contesto regolatorio europeo, questa tracciabilità si collega anche all’AI Act, che richiede per i sistemi ad alto rischio adeguati livelli di accuratezza, robustezza e cyber security lungo il ciclo di vita [13].

Dall’inventario alla mitigazione

Un AIBoM senza vulnerability intelligence rischia di essere solo compliance documentale.

Un AIVD senza AIBoM rischia invece di essere un database scollegato dagli asset reali dell’organizzazione.

Il valore nasce dall’integrazione. Quando una vulnerabilità AI viene pubblicata, l’organizzazione deve poter interrogare il proprio inventario e capire se possiede modelli, dataset, pesi, librerie o servizi esposti. [1], [11], [12], [28], [29]

La differenziazione per livello delle mitigazioni

Le mitigazioni vanno inoltre differenziate per livello su:

• dato: provenance, data lineage, controlli di integrità, hashing, segregazione dei dataset, validazione degli input, anomaly detection, audit delle label, controllo degli accessi e monitoraggio dei drift;
• modello: adversarial training, robust evaluation, red teaming, test su perturbazioni, fine-tuning controllato, versioning dei pesi, rollback e validazione indipendente;
• inferenza: rate limiting, controllo dell’esposizione degli output, limitazione ai top-k risultati, coarsening della precisione, differential privacy quando appropriata, logging e detection di query anomale;
• applicazione LLM: prompt isolation, policy enforcement, tool-use authorization, output filtering, retrieval governance e test continui contro prompt injection. [8], [18], [20], [21], [22], [23], [24], [25], [26].

Membership inference

L’esempio di membership inference riportato nell’articolo è emblematico: l’attaccante usa query ripetute e output predittivi per inferire se un record facesse parte del training set

Le mitigazioni indicate includono riduzione dell’informazione esposta dal vettore di predizione, riduzione della granularità dell’output e differential privacy [1], [23], [24], [25], [26].

Un modello operativo per CISO

Per rendere concreto il passaggio da teoria a governance, un programma di AI vulnerability management dovrebbe includere almeno sei capability [1], [8], [11], [13]:

• Prima: inventario AI enterprise-wide, esteso a modelli embedded in prodotti SaaS, servizi cloud, pipeline interne, strumenti di automazione, applicazioni GenAI e componenti open source. [11], [12], [28]
• Seconda: AIBoM obbligatorio per i sistemi AI rilevanti, con metadati su modello, dataset, pesi, dipendenze, vendor, licenze, limiti d’uso, controlli e valutazioni. [1], [11], [12], [30], [32]
• Terza: threat modeling AI-specifico, usando MITRE ATLAS, OWASP ML Top 10, OWASP LLM Top 10 e tassonomie NIST per mappare poisoning, evasion, inversion, extraction, prompt injection, supply chain compromise e abuse del modello [7], [8], [9], [10].
• Quarta: severity scoring ibrido, in cui CVSS viene integrato da metriche su decision integrity, privacy leakage, safety impact, drift, business criticality, exploitability dell’API e disponibilità di mitigazioni [1], [5], [8].
• Quinta: continuous validation, con test periodici, adversarial testing, model monitoring, drift detection, evaluation regressions e soglie di escalation verso SOC, AI engineering, Legal, DPO e business owner [8], [13], [18], [22].
• Sesta: vulnerability disclosure e supplier governance, affinché contratti, procurement e third-party risk management richiedano AIBoM, notifica delle vulnerabilità AI, remediation SLA, evidenze di testing, changelog dei modelli e procedure di ritiro sicuro [1], [6], [11], [13].

L’AI sicura sarà quella tracciabile

La cyber security dell’AI non si vincerà con un nuovo acronimo, ma con una disciplina più rigorosa.

AIVD e AIBoM sono utili perché costringono l’organizzazione a rendere visibile ciò che oggi spesso è opaco: componenti, dati, modelli, dipendenze, comportamenti, limiti e vulnerabilità [1], [11], [12].
Il vero cambio di paradigma è dunquequesto: per il software tradizionale, la domanda era “quale componente contiene una vulnerabilità?”.

Per l’AI, la nuova domanda diventa quindi “quale combinazione di modello, dati, pesi, contesto e uso può produrre un comportamento vulnerabile, sfruttabile o non conforme?” [1].

Finché questa domanda non entrerà nei processi ordinari di CISO, DevSecOps, MLOps, procurement e risk management, l’AI resterà una superficie d’attacco gestita con strumenti nati per un’altra epoca

AIBoM e AIVD non sono quindi esercizi accademici: sono il ponte necessario tra AI governance, cyber security operativa e responsabilità manageriale [1], [8], [11], [13].

Appendice

Bibliografia ragionata e fonti

[1] M. Fazelnia, S. Moshtari, M. Mirakhorli, “Establishing Minimum Elements for Effective Vulnerability Management in AI Software,” Computer, IEEE Computer Society, vol. 59, no. 4, pp. 40-49, Apr. 2026, doi: 10.1109/MC.2026.3652880.
Nell’articolo si usa: Base concettuale dell’articolo: AIVD, AI-CWE, minimum elements, AIBoM, limiti dei sistemi tradizionali di vulnerability management e membership inference come caso esemplificativo.

Fonti istituzionali, standard e framework

[2] CVE Program, “CVE – Common Vulnerabilities and Exposures”, The MITRE Corporation.
Uso nell’articolo: Riferimento per il modello tradizionale di identificazione delle vulnerabilità note.

[3] National Institute of Standards and Technology, “National Vulnerability Database”.
Nell’articolo: Riferimento per il repository governativo statunitense delle vulnerabilità e dei dati di vulnerability management.

[4] MITRE, “Common Weakness Enumeration (CWE)”.
Nell’articolo: Riferimento per la tassonomia tradizionale delle debolezze software/hardware, confrontata con l’esigenza di una AI-CWE.

[5] FIRST, “Common Vulnerability Scoring System v4.0: Specification Document”.
Uso nell’articolo: Riferimento per la discussione sui limiti e sull’estensione AI-aware della severity.

[6] ENISA, “European Vulnerability Database (EUVD).” Online: https://euvd.enisa.europa.eu/; ENISA, “Consult the European Vulnerability Database to enhance your digital security”, 13 May 2025.
Uso nell’articolo: Riferimento europeo per vulnerability intelligence e coordinated vulnerability disclosure nel quadro NIS2.

[7] MITRE, “ATLAS – Adversarial Threat Landscape for Artificial-Intelligence Systems”.
Uso nell’articolo: Riferimento operativo per threat modeling AI-specifico e classificazione di tattiche/tecniche avversarie contro sistemi AI.

[8] A. Vassilev et al., “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations”, NIST AI 100-2 E2025, National Institute of Standards and Technology, 2025.
Uso nell’articolo: Riferimento istituzionale per tassonomia, terminologia e mitigazioni nell’adversarial machine learning.

[9] OWASP, “Machine Learning Security Top 10”.
Uso nell’articolo: Riferimento per rischi ML quali data poisoning, model inversion, membership inference e AI supply chain attack.

[10] OWASP, “OWASP Top 10 for Large Language Model Applications 2025”.
Uso nell’articolo: Riferimento per vulnerabilità specifiche dei sistemi LLM, inclusi prompt injection, insecure output handling e supply chain vulnerabilities.

[11] G7 Cyber Expert Group / CISA and international partners, “Software Bill of Materials for AI – Minimum Elements”, 12 May 2026.
Uso nell’articolo: Riferimento istituzionale per gli elementi minimi di trasparenza della supply chain AI.

[12] CycloneDX, “Machine Learning Bill of Materials (ML-BOM)”. Uso nell’articolo: Riferimento tecnico-standard per rappresentare modelli, dataset, provenance e dipendenze AI/ML in formato BOM.

[13] European Union, “Regulation (EU) 2024/1689 – Artificial Intelligence Act”, Article 15, Accuracy, robustness and cybersecurity; AI Act Service Desk, “Article 15”.
Uso nell’articolo: Riferimento normativo europeo per accuratezza, robustezza e cybersecurity dei sistemi AI ad alto rischio.

Fonti accademico-scientifiche citate dalla fonte principale

[14] C. Stephan et al., “Multicenter evaluation of an artificial neural network to increase the prostate cancer detection rate and reduce unnecessary biopsies,” Clinical Chemistry, vol. 48, no. 8, pp. 1279-1287, 2002, doi:
10.1093/clinchem/48.8.1279.
Uso nell’articolo: Esempio di impiego AI in sanità, utile a inquadrare gli impatti safety/privacy dei sistemi decisionali.

[15] Financial Stability Board, “Artificial intelligence and machine learning in financial services: Market developments and financial stability implications”, Basel, Switzerland, 2017.
Uso nell’articolo: Esempio di dominio finance e rischio sistemico/modello connesso all’adozione di AI e machine learning.

[16] A. Lorsakul, J. Suthakorn, “Traffic sign recognition using neural network on OpenCV: Toward intelligent vehicle/driver assistance system”, in Proc. 4th International Conference on Ubiquitous Robots and Ambient Intelligence, 2007, pp. 22-24.
Uso nell’articolo: Esempio di AI in contesti safety-relevant, utile per distinguere crash software da errore decisionale del modello.

[17] S. Chakraborty, R. Krishna, Y. Ding, B. Ray, “Deep learning based vulnerability detection: Are we there yet?,” IEEE Transactions on Software Engineering, vol. 48, no. 9, pp. 3280-3296, Sept. 2021, doi: 10.1109/TSE.2021.3087402.
Uso nell’articolo: Fonte utile per il paradosso dell’AI usata per cybersecurity e, a sua volta, soggetta a fragilità di dati, modello e generalizzazione.

[18] I. Goodfellow, J. Shlens, C. Szegedy, “Explaining and harnessing adversarial examples,” in Proc. International Conference on Learning Representations, 2015.
Uso nell’articolo: Fonte fondativa sugli adversarial examples e sulla manipolabilità comportamentale dei modelli.

[19] M. Fazelnia, A. Okutan, M. Mirakhorli, “Supporting artificial intelligence/machine learning security workers through an adversarial techniques, tools, and common knowledge framework,” IEEE Security & Privacy, vol. 21, no. 1, pp. 37-48, Jan./Feb. 2023, doi: 10.1109/MSEC.2022.3221058.
Uso nell’articolo: Fonte di raccordo con l’idea di tassonomia operativa AI/ML per tecniche avversarie, strumenti e conoscenza comune.

[20] H. Zhou, K. Chen, W. Zhang, H. Fang, W. Zhou, N. Yu, “DUP-Net: Denoiser and upsampler network for 3D adversarial point clouds defense,” in Proc. IEEE/CVF International Conference on Computer Vision (ICCV), 2019, pp. 1961-1970, doi: 10.1109/ICCV.2019.00205.
Uso nell’articolo: Esempio di mitigazione specifica contro perturbazioni avversarie in point cloud 3D.

[21] C. Guo, M. Rana, M. Cisse, L. van der Maaten, “Countering adversarial images using input transformations”, in Proc. International Conference on Learning Representations, 2018.
Uso nell’articolo: Esempio di mitigazione mediante trasformazioni degli input contro immagini avversarie.

[22] A. Paudice, L. Muñoz-González, A. Gyorgy, E. C. Lupu, “Detection of adversarial training examples in poisoning attacks through anomaly detection,” arXiv:1802.03041, 2018.
Uso nell’articolo: Esempio di anomaly detection applicata a poisoning attack e sicurezza del training set.

[23] R. Shokri, M. Stronati, C. Song, V. Shmatikov, “Membership inference attacks against machine learning models,” in Proc. IEEE Symposium on Security and Privacy (SP), Los Alamitos, CA, USA, 2017, pp. 3-18, doi:
10.1109/SP.2017.41.
Uso nell’articolo: Fonte fondativa per membership inference attack come rischio di privacy leakage dai modelli ML.

[24] T. Leemann, M. Pawelczyk, G. Kasneci, “Gaussian membership inference privacy,” in Proc. 37th International Conference on Neural Information Processing Systems (NeurIPS), 2024, pp. 73866-73878.
Uso nell’articolo: Approfondimento sulla formalizzazione della privacy rispetto a realistiche capacità di membership inference.

[25] D. Ye, S. Shen, T. Zhu, B. Liu, W. Zhou, “One parameter defense – defending against data inference attacks via differential privacy,” IEEE Transactions on Information Forensics and Security, vol. 17, pp. 1466-1480, 2022, doi: 10.1109/TIFS.2022.3163591.
Uso nell’articolo: Fonte per differential privacy come mitigazione contro data inference e membership inference.

[26] G. Liu, Z. Tian, J. Chen, C. Wang, J. Liu, “TEAR: Exploring temporal evolution of adversarial robustness for membership inference attacks against federated learning,” IEEE Transactions on Information Forensics and Security, vol. 18, pp. 4996-5010, 2023, doi: 10.1109/TIFS.2023.3303718.
Uso nell’articolo: Fonte per la robustezza temporale contro membership inference in contesti federated learning.

[27] M. Fazelnia, I. Khokhlov, M. Mirakhorli, “Attacks, defenses, and tools: A framework to facilitate robust AI/ML systems”, arXiv:2202.09465, 2022.
Uso nell’articolo: Fonte di contesto scientifico per collegare attacchi, difese e strumenti in un framework AI/ML security-oriented.

Fonti di contesto tecnico-operativo

[28] Cybersecurity and Infrastructure Security Agency, “Software Bill of Materials (SBOM)”.
Uso nell’articolo: Contesto istituzionale generale sulla SBOM come strumento di supply chain security.

[29] M. Mirakhorli et al., “A landscape study of open source and proprietary tools for software bill of materials (SBOM)”, arXiv:2402.11151, 2024.
Uso nell’articolo: Scenario degli strumenti SBOM open source e proprietari, utile per collegare SBOM e AIBoM.

[30] D. Mor-Ofek, “It’s time to talk about AI/ML BOM (artificial intelligence bill of materials) and vulnerability management”, C2A Security, Mar. 15, 2024. Online: https://c2a-sec.com/its-time-to-talk-about-ai-ml-bom-artificial-intelligence-bill-of-materials-and-vulnerability-management/.
Uso nell’articolo: Fonte di contesto industry sul bisogno di AI/ML BOM e vulnerability management.

[31] X. Ren, Y. Ye, X. Wu, Y. Wu, Y. Xue, “Demystifying the evolution of neural networks with BOM analysis: Insights from a large-scale study of 55,997 GitHub repositories,” arXiv:2509.20010, 2025.
Uso nell’articolo: Fonte di contesto scientifico-operativo per l’analisi BOM dell’evoluzione delle reti neurali.

[32] aibom-squad, “SBOM-for-AI-Use-Cases: Repository for on-going work as part of the SBOM for AI tiger team effort”, GitHub.
Uso nell’articolo: Raccolta di use case per SBOM for AI: compliance, incident management, open-source model risk, TPRM e lifecycle management.