Il 29 luglio 2026, la CISA ha pubblicato gli Elementi minimi per il 2026 Software Bill of Materials (SBOM), in sostituzione delle linee guida di riferimento della NTIA in vigore dal 2021, redatte in collaborazione con la NSA, l’FBI e 15 agenzie internazionali di sicurezza informatica.
Il documento “Elementi minimi per un SBOM ( Software ) 2026”Bill of Materials (SBOM) rappresenta la specifica aggiornata della CISA relativa ai dati che un SBOM deve contenere, e la modifica più significativa è di natura strutturale, non numerica: gli elementi del 2026 non vietano la generazione di SBOM a partire da manifest di sorgente, ma richiedono agli autori di dichiarare come è stato generato l’SBOM, di calcolare l’hash dell’artefatto eseguibile e di etichettare ogni campo che non è stato possibile compilare. Un SBOM basato esclusivamente su un manifesto ora rende note le proprie lacune in un formato leggibile da una macchina.
MetaDefender Software Supply Chain è la piattaforma di sicurezza della catena di fornitura del software di OPSWAT, progettata per analizzare artefatti, file binari e livelli delle immagini dei container — proprio la categoria di dati richiesta dai nuovi requisiti relativi a hash, contesto di generazione e copertura.
In sintesi
- 17 campi dati — 9 metadati SBOM, 8 dati relativi ai componenti
- 6 pratiche e processi
- 10 nuovi campi, 8 aggiornamenti significativi, 1 eliminazione (Controllo degli accessi, integrato nelle sezioni Distribuzione e Consegna)
- Si applica a tutti i software, "compresi i software open source, i software di intelligenza artificiale e i SaaS"
- Non si tratta di nuovi requisiti, bensì di un perfezionamento delle modalità con cui le organizzazioni generano e richiedono gli SBOM
Modifiche allo SBOM del 2026 più difficili da soddisfare per gli SBOM basati esclusivamente sui dati di origine
1. Il valore hash del componente richiede l'artefatto eseguibile
I campi "Valore hash del componente" e "Algoritmo hash del componente" specificano chiaramente quale elemento viene sottoposto all'hash: "l'output generato dall'applicazione di un algoritmo hash crittografico a un artefatto di componente eseguibile". Non si tratta né della voce del manifesto, né della stringa della versione dichiarata.
- Un parser che legge i file package-lock.json, pom.xml o requirements.txt non interviene su alcun artefatto eseguibile, pertanto entrambi i campi hash restituiscono il valore “unknown”
- Qualora esista un hash, l'algoritmo deve utilizzare i nomi testuali delle funzioni hash dell’IANA ed essere approvato da un'autorità come il NIST
- Gli hash consentono al destinatario di verificare che il componente descritto corrisponda a quello spedito
2. Il contesto della generazione della SBOM rende il metodo parte integrante della documentazione
Il “contesto di generazione dell’SBOM” è l’aggiunta più discreta, ma anche la più significativa dal punto di vista strutturale: “la fase relativa del ciclo di vita del software e i dati disponibili nel momento in cui l’autore dell’SBOM ha generato l’SBOM”. La CISA definisce tre valori — prima della compilazione, durante la compilazione e dopo la compilazione — e associa ciascuno di essi al modo in cui l’SBOM è stato prodotto: un SBOM ricavato dal codice sorgente corrisponde alla fase più precoce, mentre gli strumenti di analisi binaria lo collocano nella fase più tardiva.
- I team addetti agli acquisti possono specificare quale fase del ciclo di vita intendono accettare, privilegiando gli SBOM ricavati dall'artefatto compilato rispetto a quelli a livello di codice sorgente
- Le piattaforme di gestione delle vulnerabilità possono ponderare i risultati in base al contesto dichiarato
- Uno SBOM derivato dal codice sorgente rimane ammissibile, ma non può più essere presentato come equivalente a uno generato dal file binario finale
3. La copertura sostituisce l’approfondimento, senza alcun limite minimo
L'elemento "Profondità" del 2021 richiedeva solo le dipendenze di primo livello — una definizione che, secondo la CISA, "rispecchiava le capacità degli strumenti SBOM disponibili all'epoca piuttosto che il livello di dettaglio delle informazioni necessario per prendere decisioni informate in materia di sicurezza". La copertura è ora più rigorosa: "tutti i componenti che costituiscono il software di destinazione, comprese le dipendenze transitive. Non è previsto un livello minimo di profondità".
Il test è funzionale. Un destinatario «dovrebbe essere in grado di concludere che una vulnerabilità segnalata di recente non lo riguarda se l’SBOM non elenca il componente associato alla vulnerabilità». L’assenza diventa prova, il che vale solo quando la copertura è sufficientemente completa. È improbabile che l’analisi del manifesto da sola raggiunga tale standard per:
- Codice collegato staticamente e fornito dal venditore — non lascia alcuna voce nel manifesto
- Progetti in C e C++ — nessun gestore di pacchetti universale tiene traccia delle DLL e degli oggetti condivisi incorporati in fase di compilazione
- Codice sorgente copiato — che la CISA descrive come "di fatto una dipendenza che è meglio tracciare come fork e come relazione di dipendenza"
- Container livelli di immagini — pacchetti installati tramite comandi “layer” anziché dichiarati in un manifesto
Le informazioni non note devono ora essere dichiarate
- Gli autori dovrebbero distinguere le informazioni di cui non sono a conoscenza da quelle che vengono deliberatamente omesse
- Si raccomanda agli autori di predisporre una procedura che consenta ai destinatari di richiedere informazioni sui contenuti relativi alla sicurezza che sono stati oscurati
- "Le organizzazioni potrebbero considerare incompleta una SBOM qualora l'autore della stessa ometta dati essenziali relativi ai componenti"
- Il concetto di “tolleranza degli errori” è stato sostituito in base al presupposto che i destinatari “possano aspettarsi che i dati SBOM siano accurati” — gli errori derivanti dalla “scelta di strumenti inadeguati” costituiscono ora un elemento legittimo da considerare nella valutazione dei rischi da parte del destinatario
Ulteriori modifiche apportate dalla CISA agli elementi dello SBOM del 2026
Modifica | Che cos’è | Perché è importante |
Firma dell'autore della SBOM (nuova) | Una firma digitale associata all'autore dell'SBOM | Consente al destinatario di verificare che l'SBOM sia autentico e non sia stato alterato dopo la firma |
Licenza per componente (nuova) | La licenza in base alla quale viene distribuito ciascun componente | Rischi relativi al copyright e alla conformità delle interfacce; la CISA fa riferimento agli ID delle licenze SPDX |
Dati elaborabili automaticamente (precedentemente “Supporto all’automazione”) | Solo SPDX e CycloneDX | SWID è stato eliminato in quanto poco diffuso; i formati accettati sono ora limitati a due |
Produttore di componenti (precedentemente denominato "Nome del fornitore") | Un'organizzazione con nome per ogni componente | Aggiunge un'opzione di ripiego esplicita "provenienza sconosciuta" quando la fonte non è chiara |
Frequenza (aggiornata) | Una nuova SBOM per ogni versione, aggiornamento e build che includa i componenti modificati | È difficile mantenere quella cadenza manualmente, il che spinge i team a ricorrere alla generazione automatizzata |
Colmare il divario post-costruzione
L'aggiornamento del 2026 riflette la valutazione della CISA secondo cui gli strumenti SBOM hanno raggiunto un livello di maturità tale da richiedere maggiori funzionalità, e le informazioni che ora si prevede siano disponibili si trovano oltre la fase di compilazione.
MetaDefender™ Software Supply Chain genera i dati SBOM direttamente dall'artefatto compilato:
- Esegue la scansione di artefatti, file binari e livelli delle immagini dei container, anziché limitarsi ai soli file di dipendenza
- Identifica i file binari in C, C++ e C# tramite metadati Portable Executable e identificazione basata sulle firme
- Genera SBOM in CycloneDX e SPDXe arricchisce i report esistenti per individuare componenti e CVE sfuggiti alle scansioni precedenti
- Fornisce riferimenti incrociati a GHSA, CVE e EUVD e segnala le licenze non conformi
- Si integra con le pipeline CI/CD e i registri degli artefatti, come JFrog Artifactory, in modo che la generazione dello SBOM possa accompagnare ogni build
Per scoprire in che modo MetaDefender Software Supply Chain possono supportare i requisiti SBOM durante l’intero ciclo di vita dello sviluppo:
FAQ
Cosa è cambiato negli elementi minimi dello SBOM previsti dal CISA 2026?
L'aggiornamento aggiunge dieci nuovi campi dati, apporta otto modifiche sostanziali ed elimina un elemento. Il cambiamento strutturale più significativo consiste nella sostituzione di "Depth" con "Coverage", mentre i nuovi campi, tra cui "Component Hash Value", "SBOM Generation Context" e "SBOM Author Signature", innalzano le aspettative riguardo alle modalità di produzione e verifica dei dati SBOM.
Gli elementi minimi dello SBOM previsti dalla CISA 2026 sono obbligatori?
No. La CISA non stabilisce alcuna scadenza per la conformità né alcun meccanismo di applicazione e precisa che il documento «non costituisce una guida ai fini della conformità, normativi o legali». La forza applicativa deriva dai requisiti in materia di appalti e dalle normative che fanno riferimento alle linee guida SBOM, come il Cyber Resilience Act dell’UE.
Gli elementi minimi previsti dalla CISA 2026 per lo SBOM richiedono un'analisi dei file binari o un'analisi post-compilazione?
Non in modo esplicito. Tuttavia, il “Component Hash Value” richiede l’accesso all’artefatto eseguibile, il “SBOM Generation Context” richiede agli autori di dichiarare la fase del ciclo di vita e i campi non compilati devono essere contrassegnati come “unknown”. Uno SBOM basato esclusivamente sul codice sorgente soddisfa quindi i requisiti del formato, documentando al contempo le proprie lacune.
Gli elementi minimi previsti dal CISA 2026 si applicano ai software di intelligenza artificiale e ai servizi SaaS?
Sì. L’ambito di applicazione copre tutti i software, compresi quelli open source, l’intelligenza artificiale (IA) e il SaaS. La CISA sottolinea che queste categorie potrebbero richiedere elementi aggiuntivi, ma non li definisce in questa sede, rimandando invece alle linee guida congiunte del G7 sugli SBOM per l’IA pubblicate nel maggio 2026.
Quali formati SBOM sono accettati nell’ambito degli elementi minimi previsti dalla normativa CISA 2026?
SPDX e CycloneDX, descritti come i due formati ampiamente utilizzati per generare e utilizzare gli SBOM. I tag SWID sono stati rimossi in quanto "non rappresentano un formato di dati SBOM ampiamente utilizzato per il quale esistano diversi strumenti". Le versioni obsolete di qualsiasi formato non dovrebbero essere utilizzate per il nuovo software.
