Nel maggio 2026 il G7 Cyber security Working Group ha pubblicato la prima guida congiunta sugli elementi minimi di un Software Bill of Materials (SBOM) per i sistemi di intelligenza artificiale.

Il documento, firmato da BSI, ACN, ANSSI, CSE, CISA, NCSC e NCO con la collaborazione della Commissione europea, non istituisce obblighi né standard, ma fissa un vocabolario condiviso tra le agenzie nazionali di cyber security riguardo alle informazioni che rendono un sistema di AI tracciabile e verificabile lungo la supply chain.

Software Bill of Materials (SBOM): la guida in 7 cluster

La struttura della guida, suddivisa in sette cluster, ha tre aspetti critici:

• l’ancoraggio esplicito a standard esistenti, che riduce il costo di adozione;
• le scelte deliberatamente escluse dal nucleo minimo, in particolare il livello di autonomia dei sistemi e le loro conseguenze operative;
• l’avvertenza che un SBOM per l’AI non è sufficiente, ma deve essere integrato con strumenti di gestione delle vulnerabilità.

Gli elementi oggi raccomandati per consenso sono i candidati naturali agli obblighi di domani.

Il concetto di Software Bill of Materials non è nuovo per chi si occupa di sicurezza della supply chain.

In sostanza, un SBOM è l’inventario strutturato dei componenti che costituiscono un prodotto software e delle relazioni di dipendenza tra di essi, ovvero la “lista degli ingredienti” che consente di mappare rapidamente l’esposizione a una vulnerabilità nota senza dover effettuare un reverse engineering di ogni build.

Negli ultimi anni, questo strumento è passato da una buona pratica a un requisito, spinto da regolamenti, direttive, normative settoriali e pressioni di mercato.

Da dove parte la guida

Il punto di partenza della guida è una constatazione tanto ovvia quanto ricca di conseguenze pratiche: un sistema di IA è anche un sistema software e, pertanto, il SBOM tradizionale resta valido e applicabile.

La guida non propone un formato alternativo, ma un insieme di elementi aggiuntivi rispetto agli elementi minimi di un SBOM convenzionale.

Questa distinzione è importante per chi deve pianificare l’adozione: non si tratta di sostituire gli strumenti e i flussi di lavoro esistenti, ma di estenderli per poter catturare le caratteristiche distintive dei componenti AI, quali i modelli, i dataset, l’infrastruttura di addestramento e di inferenza, nonché le proprietà di sicurezza specifiche.

Il percorso del documento

Il documento si inserisce in un percorso ben preciso.

Nel giugno 2025, il G7 Cybersecurity Working Group aveva pubblicato una “visione condivisa” che definiva la nozione, gli obiettivi e le proprietà di un SBOM per l’AI, raccomandando però solo cluster di elementi minimi ad alto livello e illustrativi.

La guida qui analizzata, frutto del lavoro svolto tra agosto 2025 e febbraio 2026 e pubblicata congiuntamente da BSI (Germania), ACN (Italia), ANSSI (Francia), CSE (Canada), CISA (Stati Uniti), NCSC (Regno Unito) e NCO (Giappone), con la collaborazione della Commissione europea, rappresenta il passo successivo, ovvero la specificazione delle informazioni concrete che ciascun cluster dovrebbe contenere.

È essenziale comprendere bene la natura giuridica del testo, in quanto ne condiziona l’uso pratico.

Gli elementi minimi del Software Bill of Materials (SBOM)

Gli elementi minimi proposti non sono obbligatori, non creano requisiti, standard o normative e sono dichiaratamente aperti a revisioni future.

Si specifica, inoltre, che in alcune giurisdizioni alcuni di questi elementi potrebbero già essere, o diventare, oggetto di obblighi di legge o di standard esistenti o futuri.
In altre parole, non si tratta di un profilo di conformità, ma di una base di consenso tecnico che funge da riferimento per armonizzare le aspettative tra produttori e utilizzatori di IA.

Cosa comporta per un security architect

Per un security architect ciò significa due cose.

In primo luogo, l’adozione deve essere considerata come una scelta progettuale e non come un adempimento, valutando il rapporto tra il costo della scelta e il valore

L’architettura concettuale: 7 cluster, un solo principio organizzativo

La guida suddivide l’informazione in sette cluster, ciascuno dei quali contiene “elementi”, ovvero singole unità informative che descrivono una caratteristica di un componente del sistema AI.

La logica è la stessa del SBOM classico: la trasparenza e la tracciabilità dei componenti e delle loro dipendenze sono condizioni necessarie per una gestione efficace delle vulnerabilità.

Il cluster Metadata è presentato per primo perché descrive il SBOM stesso e non i componenti del sistema; gli altri sei sono dichiarati di pari importanza e non presentano un ordine gerarchico.

La tabella seguente offre una visione d’insieme prima di passare all’analisi dettagliata dei singoli cluster.

Metadata: la chain of custody del documento

Il cluster Metadata raccoglie le seguenti informazioni: autore, versione, nome e versione del formato dei dati, firma digitale dell’autore, nome e versione dello strumento di generazione, contesto di generazione, timestamp e relazioni di dipendenza.

Due aspetti meritano attenzione.

Il primo riguarda la distinzione netta tra l’elemento “SBOM author” e l’elemento “Producer”: chi genera il SBOM non coincide necessariamente con chi ha creato il componente.

Si tratta di una separazione che chi si occupa di garantire la sicurezza delle terze parti conosce bene e che qui viene formalizzata, aspetto fondamentale quando il SBOM di un modello viene prodotto da un integratore o da uno strumento di analisi binaria a valle e non dal produttore del modello.

Il secondo aspetto riguarda l’attenzione all’integrità: la firma dell’autore deve utilizzare algoritmi approvati da autorità di riferimento (NIST DSS, ISO/IEC 14888-4:2024, meccanismi crittografici concordati ENISA) e il contesto di generazione (before build, build o after build) indica in quale fase del ciclo di vita il documento è stato prodotto.

Questa informazione cambia radicalmente il grado di completezza atteso. Per quanto riguarda le versioni, si consiglia di adottare il Semantic Versioning (con major version 1 per i SBOM conformi a questi elementi minimi) e, per i timestamp, di attenersi alla RFC 9557. Queste scelte facilitano l’automazione e il confronto tra le varie iterazioni.

System Level Properties: il sistema come entità composita

Il cluster SLP descrive il sistema AI nel suo insieme, aspetto particolarmente rilevante per i sistemi composti da più elementi AI, quali classificatori, LLM o agenti.

Oltre ai consueti identificativi (nome, produttore, versione, timestamp, componenti), introduce tre elementi che riflettono bene la maturità del modello di riferimento per gli scenari di attacco moderni.

System data flow richiede di documentare il flusso dei dati tra i componenti, esplicitando le API dei servizi esterni, i protocolli di comunicazione multi-agente e il flusso bidirezionale verso i servizi esterni (web grounding). System data usage mira a chiarire se i dati vengono utilizzati per migliorare le prestazioni del modello, se le API effettuano il log e se vengono derivati metadati dall’input dell’utente.

Intended application area qualifica il dominio di impiego: tempo reale, cyber security, sanità o finanza.

Per chi si occupa di threat modeling, questi tre elementi costituiscono il nucleo difensivo del cluster, in quanto descrivono la superficie di attacco, l’esfiltrazione potenziale e le criticità del contesto in un colpo solo.

Models: come sono stati prodotti i pesi

Il cluster Models è il più articolato, con tredici elementi, e va oltre l’identificazione anagrafica del modello (nome, identificatore, versione, timestamp e produttore).

In questo caso, la guida si appoggia esplicitamente all’ecosistema di identificatori software esistente, con CPE e PURL come riferimenti principali, ma anche con un’apertura verso UUID, commit hash e identificatori intrinseci come OmniBOR e SWHID, a indicare la volontà di ampliare lo stack di identificazione senza reinventarlo.

Ciò che distingue davvero un SBOM per l’AI, però, sono altri elementi. Il Model hash value e il Model hash algorithm introducono il principio di verifica dell’integrità dei pesi e degli artefatti del modello, con l’algoritmo identificato secondo i nomi testuali IANA e approvato da un’autorità come il NIST.

La sezione “Model description” richiede di documentare le capacità, le limitazioni note e, soprattutto, il lineage, ovvero il modello predecessore su cui è stato effettuato il fine-tuning o la distillation, i derivati noti e le dipendenze da pacchetti e framework di terze parti.

La sezione “Model License” richiede di specificare non solo il documento di licenza, ma anche se il modello sia open weight, open architecture, open data o open training.

Questa granularità riflette il fatto che la questione dell’apertura dei modelli sia ormai diventata una questione di sicurezza, oltre che di conformità legale.

Datasets Properties: la provenienza come elemento di sicurezza

Il cluster DP documenta i dataset utilizzati durante l’intero ciclo di vita del modello.

Oltre a nome, descrizione, contenuto, identificatore e hash, gli elementi più significativi per un analista della sicurezza sono “Dataset provenance” e “Dataset sensitivity”.

Per quanto riguarda la provenienza, è necessario tracciare l’origine delle fonti, i metodi di raccolta (web crawling, accordi commerciali), gli step di post-processing, curation e labelling, nonché l’autore dei dati.

Per i dati sintetici, è necessario indicare anche i metodi di generazione. In pratica, si tratta della base informativa per valutare il rischio di data poisoning e per ricostruire la catena di responsabilità in caso di compromissione a monte.

La sensibilità qualifica invece se il dataset contiene dati personali identificabili (PII), dati liberamente accessibili, dati protetti da copyright, dati sensibili (finanziari, sanitari) o dati attinenti alla sicurezza nazionale: un’informazione che incrocia direttamente la data governance e la gestione del rischio.

Infrastructure: il ponte verso l’HBOM

Il cluster Infrastructure è il più snello, con soli due elementi, ma colma un vuoto importante.

L’Infrastructure software elenca le dipendenze software necessarie al funzionamento del sistema: firmware, gestori di pacchetti, librerie di terze parti, framework, runtime e strumenti.

Quando presente, l’Infrastructure Hardware rimanda a un Hardware Bill of Materials (HBOM), riconoscendo che l’hardware AI specializzato fa parte della superficie di rischio e che il SBOM non deve duplicare l’HBOM, ma collegarvisi.

Security Properties: i controlli, esplicitati

Il cluster SP è quello che parla più direttamente al lettore tecnico. Security Controls distingue tra controlli di cybersecurity generali (cifratura, minimizzazione dei dati, privacy differenziale, controlli di accesso, autenticazione API, sistemi di rilevazione delle anomalie su input/output, controlli fisici e amministrativi) e controlli specifici per l’intelligenza artificiale (addestramento alla robustezza avversariale, controlli e strumenti contro l’iniezione di prompt per i LLM e gli agenti basati su LLM, filtri input/output e controlli a livello di dato per la curation del training set).

Security Compliance documenta gli standard e le certificazioni ottenute, Cybersecurity Policy Information rimanda al file security.txt del produttore e Vulnerability Referencing collega ai database che documentano l’exploitability delle vulnerabilità note nel modello o nel sistema, trasformando il SBOM da un semplice inventario statico a un input per il triage.

Key Performance Indicators: misurare lo stato operativo

L’ultimo cluster, KPI, raccoglie le Security Metrics (benchmark e metriche di sicurezza, come la robustezza intesa come resilienza alla manipolazione da parte di terzi) e le Operational Performance KPIs (uptime, tempo di risoluzione degli incidenti, latenza, throughput e load balancing).

Questo è il cluster più orientato al monitoraggio continuo e in cui il confine tra SBOM e osservabilità è più sfumato.

Interoperabilità

Un aspetto che chi valuta l’adozione apprezzerà è la coerenza del documento con gli standard già consolidati.

La guida non impone un formato proprietario, ma si basa su standard esistenti: l’elemento che indica il formato dei dati del SBOM è volutamente neutrale.

Per gli identificatori software si utilizzano i CPE e i PURL, per gli identificatori intrinseci i SWHID (ora anche ISO/IEC 18670:2025) e gli OmniBOR, per i numeri di serie e i timestamp rispettivamente gli RFC 9562 e gli RFC 9557, per le funzioni hash i nomi testuali IANA e per le firme i NIST DSS e gli ISO/IEC 14888-4.

Anche SPDX e CycloneDX compaiono, ma in un punto circoscritto: l’esempio dell’elemento “Model License” li cita come file ai cui campi di licenza è possibile fare riferimento, non come formato di rappresentazione prescritto per il SBOM.

Questo ancoraggio allo stack esistente riduce i costi di implementazione e segnala che il SBOM per l’AI è concepito come un’estensione naturale delle pipeline SBOM esistenti e non come un binario parallelo.

Cosa è stato lasciato fuori e perché è importante

La sezione finale del documento presenta un’omissione deliberata che merita un’attenta analisi.

Il working group ha preso in considerazione l’inclusione di un elemento relativo al livello di autonomia o di capacità decisionale del sistema AI.

Con l’avanzare dell’intelligenza artificiale, un’informazione del genere diventa fondamentale per stimare l’impatto di una compromissione.

Ha però deciso di non isolarlo come elemento esplicito, riconoscendone l’importanza, ma di demandarne l’analisi alle singole giurisdizioni, eventualmente attraverso requisiti di sicurezza.

Per un esperto di AI security, questo aspetto non è da sottovalutare. L’autonomia di un agente è la variabile che determina l’impatto di un attacco riuscito: un sistema con capacità di azione su risorse esterne presenta un profilo di rischio qualitativamente diverso rispetto a un classificatore passivo.

Escludere questo elemento dal nucleo minimo è una scelta pragmatica che evita di impantanare il consenso su una definizione contesa, ma crea un divario che chi implementa un SBOM per l’AI in un contesto agentico dovrà colmare autonomamente, magari estendendo il cluster SLP.

La seconda avvertenza esplicita contenuta nel documento è altrettanto importante: un SBOM per l’AI da solo non è sufficiente per aumentare la sicurezza della supply chain.

Senza l’integrazione con strumenti di scansione e gestione delle vulnerabilità, advisory e bollettini di sicurezza, nonché con meccanismi di tooling adattivi, il SBOM rimane un semplice documento.

Questo è vero per il SBOM tradizionale da sempre, ma lo è ancora di più nel contesto dell’intelligenza artificiale, vista la velocità con cui i modelli e le tecniche di attacco evolvono.

Implicazioni operative

Alcune considerazioni per mettere in pratica il documento. La natura additiva del modello implica che il primo passo sia verificare la maturità della propria pipeline SBOM tradizionale: senza di essa, l’estensione AI si basa sul nulla. Il cluster Metadata e l’uso di firme e versioning standardizzati sono prerequisiti, in quanto permettono di rendere il SBOM verificabile e confrontabile nel tempo.

I cluster Models e Datasets Properties sono quelli che presentano il costo di raccolta più elevato, in quanto il lineage di un modello e la provenienza di un dataset richiedono una cooperazione lungo l’intera supply chain.

Tuttavia, sono anche quelli che presentano il valore difensivo più alto, in quanto consentono di valutare rischi quali il “poisoning”, la derivazione da modelli compromessi e la contaminazione del training set, rischi che il SBOM classico non è in grado di rilevare.

Il cluster Security Properties, infine, rappresenta il punto di collegamento naturale con il sistema di gestione delle vulnerabilità esistente: l’elemento Vulnerability referencing rappresenta il collegamento tra l’inventario e l’azione.

Le raccomandazioni di consenso di oggi sono i candidati naturali agli obblighi di domani

La guida sugli elementi minimi del Software Bill of Materials (SBOM) per l’AI è un documento di raccomandazioni.

Il suo valore per gli addetti alla sicurezza non risiede nell’imporre un obbligo, ma nell’aver prodotto un vocabolario condiviso tra 7 agenzie nazionali riguardo alle informazioni che rendono un sistema di IA tracciabile e verificabile.

Si tratta di un primo passo dichiarato, non esaustivo, aperto a revisione e
cauto riguardo alle questioni più controverse, come l’autonomia dell’agente, ma rappresenta anche un segnale che la trasparenza della supply chain dell’IA sta passando dalla fase dei principi a quella delle specifiche tecniche.

Per i professionisti del settore, la lettura più utile è quella anticipatoria: gli
elementi che oggi sono raccomandazioni di consenso sono i candidati naturali agli obblighi di domani, e implementarli ora significa gettare le basi informative prima che diventino un requisito.