Quando un elenco di componenti non è una prova: la nuova battaglia per la fiducia nel software

Le supply chain del software hanno un problema di fiducia che i soli inventari non possono risolvere. Un elenco di componenti può essere utile, ma non risponde alla domanda più difficile: c’era qualcosa all’interno di quel pacchetto che sia stato effettivamente verificato prima del rilascio, del deployment o del riutilizzo?

È questo divario il motivo per cui il Trusted Bill of Materials, o TBOM, è importante. Nel contesto del progetto RESCALE, viene presentato come un complemento dell’ormai familiare SBOM, capace di fornire prove concrete e di spostare l’attenzione da "cosa è presente" a "cosa è stato convalidato".

Perché questa distinzione è importante

Nello sviluppo moderno, le catene di dipendenze sono dense, rapide e spesso opache. Per questo gli SBOM sono diventati uno strumento centrale di trasparenza: aiutano le organizzazioni a vedere quali librerie, pacchetti o elementi firmware sono presenti. Ma visibilità non significa garanzia. Un inventario pulito non dice a un team di sicurezza se un componente è stato scansionato, testato, approvato o verificato rispetto a una soglia di policy.

È questa l’apertura tecnica che il TBOM vuole affrontare. I materiali pubblici di RESCALE lo descrivono come un artefatto che può contenere i risultati della valutazione di sicurezza e le prove di verifica insieme al record del componente. L’avvertenza importante è che i dettagli esatti di implementazione restano aperti nel materiale esaminato. In altre parole, il TBOM va inteso meglio come una direzione di sviluppo, non ancora come uno standard universalmente consolidato.

Dal punto di vista difensivo, questa distinzione è tutt’altro che accademica. Gli attaccanti della supply chain spesso traggono vantaggio dalla fiducia cieca negli artefatti upstream. Se i team downstream non possono capire se una dipendenza è stata verificata, possono scambiare la completezza per sicurezza. È questo il rischio più ampio che il TBOM cerca di ridurre.

Anche la guida tecnica esterna rafforza questo punto. NIST considera gli SBOM come record leggibili dalle macchine della composizione che supportano trasparenza e gestione del rischio, ma non come sostituti della provenienza, della convalida o dei controlli sul ciclo di vita. La lezione è semplice: un elenco di materiali è un punto di partenza, non il traguardo.

Al momento della stesura, le informazioni pubbliche non chiariscono pienamente il flusso di lavoro esatto del TBOM, la solidità della sua catena di evidenze o se un prodotto specifico sia stato certificato tramite esso. Il materiale disponibile supporta un’analisi del rischio, non una dichiarazione di adozione universale matura.

Conclusione

Il vero cambiamento qui è tanto filosofico quanto tecnico. I difensori informatici stanno passando dal chiedersi solo "cosa distribuiamo?" al chiedersi "cosa possiamo dimostrare di ciò che distribuiamo?" In un’epoca in cui la fiducia viene regolarmente esternalizzata tra gli ecosistemi software, le prove potrebbero diventare importanti quanto l’inventario. La conclusione di Netcrook: la trasparenza è necessaria, ma senza verifica resta comunque solo una difesa parziale.

WIKICROOK

• SBOM: Software Bill of Materials, un elenco leggibile dalle macchine dei componenti inclusi in un prodotto software.
• TBOM: Trusted Bill of Materials, un record proposto e basato su evidenze che mira a mostrare sia la composizione sia la verifica.
• Provenance: Informazioni su dove proviene il software e su come è stato costruito o gestito.
• Attestazione: Una dichiarazione o un record che qualcosa è stato controllato o convalidato in condizioni definite.
• Sicurezza della supply chain: La pratica di ridurre il rischio nelle dipendenze software e hardware, nei fornitori e nei processi di rilascio.