Approfondimento operativo — nessun attore ostilemedium
SBOM, la lista degli ingredienti cambia: cosa contengono gli elementi minimi del 2026
Il 29 luglio 2026 la CISA, insieme a NSA, FBI e a partner internazionali, ha pubblicato i nuovi elementi minimi per una Software Bill of Materials. Il documento aggiorna e sostituisce quello della NTIA del 2021, incorporando oltre novanta commenti raccolti in una consultazione pubblica. I nuovi campi introdotti — fra cui l'algoritmo di hash del componente, la licenza, il nome dello strumento che ha generato la SBOM e il contesto di generazione — non sono dettagli formali: sono le tre o quattro informazioni che decidono se il giorno dell'allarme quella lista serve a rispondere o solo a esistere.
La domanda che arriva sempre di venerdì
Esce un advisory su una libreria. Non su un prodotto: su una libreria, una di quelle che stanno dentro le cose e non hanno un'icona sul desktop. E parte la domanda, sempre uguale: ce l'abbiamo?
Nella maggior parte delle organizzazioni la risposta richiede giorni, coinvolge persone che si scrivono per sapere cosa c'è dentro un prodotto che hanno comprato, e finisce con una stima. La SBOM — Software Bill of Materials, la distinta base del software — esiste per rendere quella risposta una consultazione invece che un'indagine.
Il 29 luglio 2026 la CISA, insieme a NSA, FBI e a partner internazionali, ha pubblicato la nuova versione degli elementi minimi che una SBOM deve contenere. Il documento aggiorna e sostituisce gli elementi minimi pubblicati dalla NTIA nel 2021, raccogliendo il riscontro di una consultazione pubblica del 2025 a cui sono arrivati oltre novanta commenti.
Cosa cambia rispetto al 2021
L'impianto originale resta: la revisione preserva i principi centrali del documento NTIA e ne aggiorna il contenuto per riflettere gli strumenti e le esigenze attuali. Le aggiunte, però, sono quelle che cambiano l'uso pratico del documento.
Vale la pena capire perché questi quattro campi contano, perché a prima vista sembrano burocrazia.
L'hash del componente risolve il problema più fastidioso delle SBOM di prima generazione: il nome. Due componenti possono chiamarsi allo stesso modo ed essere cose diverse; lo stesso componente può comparire con nomi diversi in ecosistemi diversi. L'hash, con l'indicazione dell'algoritmo usato per calcolarlo, sposta l'identificazione da "come si chiama" a "che cosa è".
La licenza porta dentro la stessa lista un rischio che di solito viaggia su un binario separato, gestito da altre persone in un altro momento. Averlo nello stesso inventario significa poter rispondere a due domande diverse con una sola interrogazione.
Il nome dello strumento e il contesto di generazione rispondono invece a una domanda che nessuno faceva e che si è rivelata decisiva: quanto vale questa lista? Una SBOM prodotta dall'analisi del codice sorgente, una ricavata dagli artefatti di build e una generata a posteriori da un binario non dicono la stessa cosa, e non hanno la stessa completezza. Senza sapere come è nata, chi la riceve non può calibrare la fiducia — e una lista di cui non si conosce l'affidabilità porta al peggiore dei risultati: la falsa sicurezza.
Il perimetro si allarga
Il punto che più cambia le cose per chi acquista software è l'ambito di applicazione. Gli elementi minimi di questa revisione si applicano alle SBOM per tutto il software, incluso il software open source, il software di intelligenza artificiale e il software-as-a-service.
- 01Software commerciale e open sourceil perimetro storico, confermato
- 02Componenti di intelligenza artificialemodelli e dipendenze entrano nell'inventario
- 03SaaSanche ciò che non installate rientra nel discorso
L'inclusione esplicita dell'IA e del SaaS è la parte più interessante e anche la più impegnativa. Sono le due categorie in cui è più facile perdere il conto di cosa si sta effettivamente usando: un modello richiamato via API non compare in nessun inventario software tradizionale, e un servizio SaaS è per definizione una scatola gestita da qualcun altro. Che gli elementi minimi le nominino non risolve il problema, ma cambia la conversazione contrattuale: diventa legittimo chiedere.
Come usarlo senza trasformarlo in un progetto infinito
Una precisazione doverosa: questa è guida congiunta, non una legge. Non è direttamente vincolante per un'azienda italiana, e il valore che ha è quello di uno standard di riferimento — che però è esattamente il tipo di documento che finisce, dopo qualche mese, nei capitolati e nei contratti di fornitura. Vale la pena leggerlo ora, quando è una scelta, invece che dopo, quando è una richiesta del cliente.
Tre modi concreti di usarlo, in ordine di sforzo crescente.
Come griglia di lettura per quello che già ricevete. Se qualche fornitore vi consegna già una SBOM, confrontatela con la nuova lista: probabilmente mancano hash, licenza e contesto di generazione. Non serve rifiutarla — serve sapere cosa non contiene, e quindi a quali domande non risponde.
Come clausola nei nuovi contratti. Chiedere una SBOM conforme agli elementi minimi 2026 è una richiesta ora definita in modo preciso, con un documento pubblico a cui rimandare. È molto più efficace di "fornire documentazione sulle componenti software", che è il tipo di formula che ogni fornitore interpreta a modo suo.
Come inventario interno per il software che scrivete voi. Se avete una pipeline di build, generare una SBOM è un passaggio automatizzabile. Il valore non si vede il giorno in cui la generate: si vede il primo venerdì in cui esce un advisory su una libreria e la risposta alla domanda ce l'abbiamo? arriva in due minuti invece che in due giorni.
Un'ultima nota, per onestà: una SBOM non rende sicuro niente. È un inventario, e un inventario non ripara nulla. Serve a ridurre il tempo fra "esiste un problema" e "so se mi riguarda" — che è, in quasi tutti gli incidenti documentati di questi mesi, il tratto in cui si perde più tempo.
