Che cos'è un SBOM (Software Bill of Materials)?

Un SBOM moderno va ben oltre un listing package.json. Come minimo cattura gli NTIA minimum elements:

• Supplier di ogni componente (chi l'ha prodotto).
• Nome componente e versione.
• Identificatore unico — tipicamente un PURL (Package URL) o CPE, più hash crittografico dove applicabile.
• Dependency relationship — diretta vs transitiva, e il path dall'artefatto spedito in giù.
• Autore dell'SBOM (spesso il build system).
• Timestamp di generazione.

Gli SBOM production-grade aggiungono: metadata di licenza, cross-reference a vulnerabilità (statement VEX), provenance del build environment (attestazioni SLSA), e la firma crittografica sul documento SBOM stesso.

CycloneDX (mantenuto da OWASP) è JSON-first, ottimizzato per security tooling e pipeline CI/CD. È il formato che la maggior parte degli scanner e delle integrazioni CI emette nativamente. SPDX (Linux Foundation, ISO/IEC 5962:2021) è più verboso, license-focused, e il formato che i contratti federali specificano più spesso per nome. La maggior parte delle toolchain moderne può convertire tra i due; entrambi sono accettabili al CRA UE e ai requisiti federali US.

Il modello di produzione affidabile è la *generazione build-time*. La pipeline CI/CD che produce l'artefatto emette l'SBOM nello stesso step, firma entrambi con la stessa chiave, e li conserva insieme. Tool che lo fanno bene includono Syft (Anchore), CycloneDX CLI, Microsoft sbom-tool, la generazione SBOM di GitHub, e la maggior parte dei tool di build container moderni (BuildKit, ko, Buildah).

I failure mode che emergono all'audit:

• SBOM manuali assemblati in foglio elettronico al momento dell'audit — sono sbagliati al giorno zero e marciscono ogni giorno. Gli auditor controllano timestamp e divergenza dai lockfile correnti; questo approccio fallisce.
• SBOM solo dipendenze dirette — mancano i pacchetti transitivi che quasi ogni incidente supply-chain sfrutta. Log4Shell non sarebbe stato scopribile in un SBOM solo-diretto per la vasta maggioranza dei prodotti affetti.
• SBOM di container image che si fermano al layer applicativo — mancano le librerie di sistema della base image (glibc, OpenSSL) che sono il vero attack surface in produzione containerizzata.
• Nessuna copertura di tool build-time — il pacchetto compromesso nell'incidente Tanstack di maggio 2026 era una dev dependency *build-time*, non runtime. Gli SBOM solo-build-time l'hanno mancato completamente.
• Nessuna firma sull'SBOM — un SBOM manomesso è peggio di nessun SBOM. I regolatori chiedono sempre più la catena di firme insieme al documento.

Il valore difensivo degli SBOM diventa ovvio durante un incidente supply-chain. La domanda "quale dei miei prodotti contiene la versione X del pacchetto Y" passa da una riconciliazione cross-team di giorni a una singola query SBOM.

Incidenti reali nel periodo 2024-2026:

• Log4Shell (CVE-2021-44228) — le organizzazioni con copertura SBOM matura di ogni artefatto spedito hanno risposto alla domanda di blast radius in ore. Quelle senza ci hanno messo settimane.
• Backdoor xz-utils (CVE-2024-3094) — colpiva un branch pre-release Debian/Fedora ristretto. Le query SBOM contro gli SBOM di base image hanno identificato lo scope in minuti; l'enumerazione manuale ci ha messo giorni.
• Shai-Hulud / Mini Shai-Hulud (2024-2025) — supply-chain compromise worm-style npm. Le organizzazioni con SBOM aggiornati su ogni artefatto CI hanno identificato le pipeline affette in singole query. Quelle senza sono state forzate a rotazione credenziali ampia per precauzione.
• Incidente Tanstack, maggio 2026 — colpiva una dev dependency solo build-time. Le organizzazioni i cui SBOM includevano tool build-time hanno risposto alla domanda di impatto lo stesso giorno; quelle i cui SBOM si fermavano alle dipendenze runtime hanno mancato il vettore.

Il requisito operativo è quindi un SBOM che sia (a) per artefatto spedito, (b) copra dipendenze transitive e build-time, (c) sia generato e firmato al build time, (d) sia conservato dove i tool di incident response possono interrogarlo in secondi. I Trust Center / piattaforme continuous-evidence con ingestion SBOM integrata lo soddisfano per costruzione.

Cyber Resilience Act UE (Reg. 2024/2847) — i produttori devono "identificare e documentare vulnerabilità e componenti contenuti nel prodotto, anche redigendo una distinta base software in un formato di uso comune e machine-readable che copre almeno le dipendenze top-level del prodotto" (Allegato I, Parte 2(1)). L'SBOM dev'essere fornito alle autorità di sorveglianza del mercato su richiesta. Obbligo pieno dall'11 dicembre 2027.

NIS2 UE (Direttiva 2022/2555 + trasposizioni nazionali) — le misure dell'art. 21 includono "sicurezza supply chain, inclusi aspetti security relativi alle relazioni tra ciascuna entità e i suoi fornitori diretti o provider di servizi". Le autorità nazionali (ACN in Italia, BSI in Germania, ANSSI in Francia) richiedono di routine SBOM durante le ispezioni, anche se la Direttiva non nomina il termine esplicitamente.

DORA UE (Reg. 2022/2554) — l'ICT-third-party risk management (artt. 28+) richiede registri di accordi contrattuali con informazioni ICT-supplier dettagliate. Gli SBOM alimentano direttamente questo registro per i prodotti ICT spediti.

Executive Order 14028 US — il procurement federale richiede SBOM auto-attestati. NIST SP 800-218 (SSDF) e SP 800-204D lo operazionalizzano.

FAR US supply-chain rules — il rule-making incrementale lungo il 2025-2026 richiede sempre più l'ingestion SBOM nei programmi vendor risk management.

In aggregato: un'organizzazione che spedisce prodotti software in una delle due giurisdizioni nel 2026-2027 senza un processo SBOM automatizzato e firmato al build time è ora un outlier nel proprio peer set, e sarà svantaggiata in procurement e audit rispetto a vendor che lo spediscono di default.