SBOM: la distinta dei componenti del tuo software.

A cosa serve davvero

L’obbligo normativo è arrivato dopo. Le ragioni pratiche c’erano già.

• Rispondere in minuti invece che in giorni quando esce una vulnerabilità su una libreria diffusa.
• Sapere quali licenze open source hai ereditato, prima che lo scopra l’ufficio legale del cliente.
• Rispondere ai questionari fornitori senza ricostruire tutto a mano ogni volta.
• Adempiere a quanto chiede il Cyber Resilience Act, che la prevede esplicitamente fra gli obblighi.

Cosa contiene

Componenti e versioni

Ogni libreria con la versione esatta. Senza versione precisa la SBOM non risponde alla domanda per cui esiste.

Identificatori

PURL o CPE, cioè nomi che una macchina può confrontare con i database di vulnerabilità. È ciò che rende l’elenco utilizzabile.

Licenze

La licenza dichiarata di ciascun componente, che è il lato meno tecnico e più insidioso della catena di fornitura.

Relazioni

Chi dipende da chi. Serve a distinguere una dipendenza diretta, che controlli, da una transitiva, che ti sei portato dietro.

Origine

Chi ha generato la distinta, quando e a partire da quale build. Una SBOM senza contesto invecchia senza che nessuno se ne accorga.

CycloneDX o SPDX

Due formati standard, entrambi accettati. La scelta pesa meno di quanto si teme.

• CycloneDX nasce in ambito sicurezza ed è il più diretto da usare con i dati di vulnerabilità.
• SPDX nasce in ambito licenze e ha una tradizione più lunga sul versante legale.
• Esistono conversioni fra i due: la scelta non è una porta che si chiude.
• Conta molto di più che la SBOM sia generata a ogni build, invece che scritta una volta a mano.

Come si produce

La regola sola che conta: generata dalla build, non compilata a mano.

1. Genera la SBOM come parte della pipeline, alla stessa stregua di un artefatto di rilascio.
2. Prendi le dipendenze dal gestore di pacchetti del progetto, non da un elenco tenuto a parte: il secondo diverge sempre.
3. Includi le dipendenze transitive: sono la maggioranza dei componenti e la maggioranza delle vulnerabilità.
4. Conservala accanto alla versione rilasciata: serve saper dire cosa c’era dentro la release di due anni fa, non solo dentro quella di oggi.
5. Confrontala periodicamente con i database di vulnerabilità, altrimenti è una fotografia che non ti avvisa di niente.

Tre convinzioni sbagliate