Nel dicembre 2021, quando è uscita la vulnerabilità di Log4j, migliaia di aziende si sono trovate davanti a una domanda che sembrava banale: abbiamo quella libreria?
Quasi nessuna è riuscita a rispondere in fretta. Non perché non avessero un inventario, ma perché l’inventario elencava i prodotti installati, non gli ingredienti di quei prodotti. E Log4j non è un prodotto che si installa: è un pezzo dentro qualcos’altro.
L’SBOM, sigla di Software Bill of Materials, serve esattamente a rispondere a quella domanda. Ed è passato in pochi anni dall’essere una buona pratica a un obbligo di legge europeo.
Che cos’è un SBOM
Un Software Bill of Materials è l’elenco formale dei componenti che compongono un software. Il nome viene dalla distinta base della produzione industriale, ed è la stessa idea: sapere di cosa è fatto un prodotto finito.
Un’applicazione moderna non viene scritta da zero. Usa librerie, framework, moduli di terze parti, e quelle librerie a loro volta ne usano altre. La parte scritta dall’azienda che vende il software è spesso una frazione minoritaria di quello che gira davvero. Il resto viene da progetti open source, fornitori, pacchetti scaricati da repository pubblici.
L’SBOM mette per iscritto quella catena. Nome del componente, versione, fornitore, e la relazione con gli altri: chi dipende da chi.
Detto così sembra documentazione. La differenza è che un SBOM è leggibile da una macchina. Non è un PDF da consultare: è un file strutturato che si può interrogare. Quando esce una vulnerabilità, la domanda “abbiamo quel componente” diventa una ricerca di pochi secondi invece di una settimana di telefonate ai fornitori.
Cosa contiene davvero
Non tutti gli SBOM sono uguali, e la differenza fra uno utile e uno inutile sta in pochi campi.
| Informazione | Perché serve |
|---|---|
| Nome e versione del componente | Senza la versione l’informazione è quasi inutile: le vulnerabilità colpiscono versioni, non nomi |
| Fornitore o progetto di origine | Serve a distinguere componenti con nomi simili e a sapere a chi rivolgersi per gli aggiornamenti |
| Identificatore univoco | Un codice che identifica il componente in modo non ambiguo, così la ricerca automatica funziona |
| Relazioni di dipendenza | Distingue i componenti inclusi direttamente da quelli che arrivano dentro altri componenti |
| Licenza | Non è un tema di sicurezza, ma è il motivo per cui molte aziende hanno cominciato a produrre SBOM |
| Autore e data di generazione | Un SBOM vecchio di due anni descrive un software che non esiste più |
La riga sulle dipendenze è quella che separa un SBOM serio da un elenco. Un componente incluso direttamente lo si conosce; quello che arriva per due o tre livelli di profondità no, ed è lì che Log4j si nascondeva nella maggior parte dei casi.
Molti SBOM in circolazione si fermano al primo livello. Sono meglio di niente, e non rispondono alla domanda per cui esistono.
I formati, e perché non è un dettaglio
Perché un SBOM sia utile deve poter essere letto da uno strumento, quindi il formato conta. Due si sono affermati.
SPDX nasce dalla Linux Foundation ed è diventato uno standard ISO. È il più diffuso nel mondo delle licenze e dei grandi progetti open source. CycloneDX nasce in ambito OWASP ed è pensato fin dall’origine per la sicurezza: gestisce meglio le informazioni su vulnerabilità e provenienza.
Nella pratica capita spesso di trovarsi con entrambi, perché fornitori diversi ne producono uno o l’altro. Esistono strumenti di conversione, e la scelta del formato conta meno della completezza dei dati.
Quello che conta davvero è un’altra cosa: un SBOM in PDF non è un SBOM. È un documento che elenca componenti, e non si può interrogare. Se un fornitore vi manda un PDF, avete ricevuto una dichiarazione, non una distinta base.
Sapere cosa contiene un software è metà dell’informazione. L’altra metà è cosa di quel software è raggiungibile.
Il Vulnerability Assessment rileva le versioni effettivamente in uso sui vostri sistemi e le vulnerabilità note associate, restituendole in ordine di priorità reale.
Chi è obbligato e da quando
Fino a pochi anni fa l’SBOM era una pratica di settori regolamentati, il medicale e l’automotive soprattutto. Poi è entrato nelle norme.
Il primo passaggio è stato statunitense: dal 2021 i fornitori di software alla pubblica amministrazione federale devono produrre un SBOM. Ha spostato il mercato, perché ha costretto i grandi produttori a dotarsi degli strumenti.
In Europa il riferimento è il Cyber Resilience Act, il regolamento che stabilisce requisiti di sicurezza per i prodotti con elementi digitali immessi sul mercato europeo. Fra gli obblighi dei fabbricanti c’è la redazione di un SBOM che copra almeno le dipendenze di primo livello, insieme alla gestione delle vulnerabilità per tutto il ciclo di vita del prodotto.
Gli obblighi entrano in applicazione in modo scaglionato, e le prime scadenze riguardano la segnalazione delle vulnerabilità attivamente sfruttate. Chi produce o distribuisce software in Europa dovrebbe verificare il proprio calendario adesso, non alla scadenza.
Sul fronte della direttiva NIS 2 l’SBOM non compare come obbligo esplicito, ma la sicurezza della catena di fornitura è fra le misure richieste. E per governare il rischio di un fornitore serve sapere cosa quel fornitore vi consegna.
Cosa cambia per chi compra software
La maggior parte delle aziende italiane non produce software: lo compra. E qui l’SBOM cambia una cosa concreta nel rapporto con i fornitori.
Oggi, quando esce una vulnerabilità grave, il percorso è questo: si scrive al fornitore, si aspetta, si riceve una risposta generica, si riscrive. Nel frattempo nessuno sa se il problema riguarda l’azienda oppure no.
Con un SBOM quella catena si accorcia a una ricerca. E soprattutto sposta il momento in cui l’informazione viene raccolta: non durante l’emergenza, ma in fase di acquisto.
Il punto pratico è inserire la richiesta nel contratto. Non come clausola generica sulla sicurezza, ma con tre elementi: che l’SBOM venga fornito in un formato leggibile da una macchina, che copra le dipendenze oltre il primo livello, e che venga aggiornato a ogni rilascio significativo.
È lo stesso ragionamento che si applica alla valutazione della sicurezza dei fornitori: le condizioni si negoziano quando si firma, non quando serve.
E vale la pena aspettarsi resistenze. Molti fornitori italiani di software gestionale non hanno mai prodotto un SBOM e non sanno da dove cominciare. La richiesta però è destinata a diventare standard, e chi la fa adesso si trova avanti.
Cosa farne una volta che ce l’avete
Un SBOM archiviato in una cartella non serve a niente. Le cose da fare sono tre, e nessuna è complicata.
Confrontarlo con le vulnerabilità note. Esistono strumenti che prendono un SBOM e lo incrociano con i database pubblici, restituendo quali componenti hanno vulnerabilità note. È un’operazione automatica e va ripetuta, perché le vulnerabilità escono dopo.
Tenerlo aggiornato. Un SBOM descrive una versione precisa di un software. Al rilascio successivo è già parzialmente falso, e dopo qualche mese descrive qualcosa che non avete più.
Collegarlo all’inventario. L’SBOM dice cosa c’è dentro un prodotto; l’inventario degli asset dice dove quel prodotto è installato e cosa raggiunge. Servono insieme: sapere di avere un componente vulnerabile non dice quanto sia urgente, e quello dipende da dove si trova.
Resta un limite che vale la pena dire chiaramente. L’SBOM elenca quello che il fornitore dichiara di aver incluso, non quello che gira effettivamente sui vostri sistemi. Una modifica applicata a mano, un componente aggiunto da un integratore, una versione diversa da quella prevista: nessuna di queste cose compare.
È il motivo per cui l’SBOM non sostituisce la verifica tecnica. La domanda “cosa c’è dentro” e la domanda “cosa è raggiungibile e sfruttabile” restano due domande diverse, ed è quello che Log4Shell ha insegnato a chi lo ha attraversato: la correzione esisteva, il problema era trovare dove applicarla.
Un componente vulnerabile conta per quanto è raggiungibile, non per quanto è grave.
Il Penetration Test verifica cosa si ottiene davvero partendo da una vulnerabilità presente: quali sistemi diventano accessibili e dove la segmentazione della rete tiene.
- Autore articolo
- Gli ultimi articoli
Responsabile Marketing per due aziende leader nel settore della Sicurezza Informatica: organizzo e progetto iniziative di diffusione della cultura cybersecurity e dei rischi cyber-crime attraverso contenuti web, eventi on e off line e materiale info-grafico. Ho una naturale propensione per far coesistere il lato metodico e preciso del mio carattere con la parte più creativa, visionaria e ambiziosa di me. Sono curiosa, riflessiva e non metto freni alla mia fame di conoscenza.