SBOM e SLSA: la supply chain security del software diventa disciplina

CyberScan

Vulnerability assessment e pentest automatizzato. Asset discovery continuo, AI risk prioritization, NIS2 compliance manager integrato.

Scopri CyberScan →

DataGovern

Piattaforma di compliance integrata GDPR + NIS2 + EU AI Act. Cross-Regulation Gap analysis, dashboard board-ready, on-premise.

Scopri DataGovern →

Cyber Security

Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.

Scopri →

Dopo Log4Shell, l’industria reagisce

Dicembre 2021 — Log4Shell rende visibile a tutti il problema che tecnici di sicurezza segnalavano da anni: le applicazioni moderne dipendono da centinaia o migliaia di librerie open source di cui non si conosce l’inventario, le origini, i maintainer, la superficie di attacco. La domanda base — “usiamo Log4j? in quali versioni?” — ha portato migliaia di CISO a scoprire di non poter rispondere in tempi ragionevoli.

Nei mesi successivi l’industria reagisce con una serie di iniziative coordinate che consolidano Supply Chain Security come disciplina. Al luglio 2022 il quadro operativo è consistente, con framework, strumenti e prima regolamentazione.

SBOM — Software Bill of Materials

Un SBOM è un inventario strutturato dei componenti software, analogo a una distinta base di materiali in produzione industriale. Per ogni componente: nome, versione, licenza, hash crittografico, upstream source, dipendenze transitive, eventuali CVE note.

Due formati standard coesistono:

SPDX

Software Package Data Exchange, iniziativa della Linux Foundation avviata nel 2010. Standardizzato come ISO/IEC 5962:2021 a ottobre 2021. Orientato inizialmente al tracking licenze, ha evoluto il supporto per vulnerability information in SPDX 2.3 (2022). Formato: JSON, YAML, tag-value, RDF/XML.

CycloneDX

OWASP initiative, rilasciato nel 2017. Orientato nativamente a vulnerability management e supply chain security. Formato: JSON, XML, Protobuf. La versione 1.4 (gennaio 2022) introduce supporto a Vulnerability Exploitability eXchange (VEX) — dichiarazioni su quali CVE affettano un artefatto.

I due formati sono complementari: spesso un’organizzazione produce entrambi per soddisfare diversi utilizzi.

Tool per generare SBOM

• syft (Anchore) — generatore multipiattaforma, output SPDX/CycloneDX
• Trivy (Aqua Security) — scanner + SBOM generator
• SPDX Tools — Java/Python per parsing
• cdxgen (CycloneDX team) — Node.js
• Microsoft SBOM Tool
• Language-specific tools: cargo-sbom, syft/pipsbom per Python, license-maven-plugin

SLSA — Supply-chain Levels for Software Artifacts

SLSA (pronounciato salsa) è un framework lanciato da Google nel giugno 2021 come risposta a incidenti di supply chain (SolarWinds 2020, Codecov 2021). La prima versione pubblica 1.0 è rilasciata in aprile 2023; al luglio 2022 la 0.1 è in uso e i draft evolvono.

SLSA definisce quattro livelli di maturità (0-4, poi semplificati) per la catena di build di un artefatto software:

• SLSA 0 — nessun requisito
• SLSA 1 — build con generazione di provenance (chi, cosa, come, dove è stato costruito)
• SLSA 2 — provenance firmata e hosted in modo verificabile
• SLSA 3 — build in ambiente isolato (ephemeral, hermetic), source tracked
• SLSA 4 — two-party review di ogni modifica, reproducibility verificata

Ogni livello aggiunge requisiti concreti su: source, build, dependencies, provenance. Il framework è usabile come target di maturity: un’organizzazione dichiara a quale livello opera per ciascun artefatto.

Sigstore

Sigstore è un progetto Linux Foundation (con Red Hat, Google, Purdue, Chainguard) lanciato nel marzo 2021 per standardizzare la firma di artefatti software con infrastruttura semplice e gratuita:

• cosign — CLI per firmare/verificare container image, SBOM, artifact generici
• Fulcio — CA short-lived (certificati validi minuti) basata su OIDC — firmare senza gestire chiavi private a lungo termine
• Rekor — transparency log (append-only ledger) per tutte le firme Sigstore
• Gitsign — firma di commit Git tramite Sigstore

Il modello elimina il problema storico del “chi gestisce la chiave privata”: ogni firma viene fatta con una chiave effimera derivata dall’identità OIDC (Google, GitHub, Azure), registrata in transparency log, verificabile senza necessità di key management pubblica.

Sigstore diventa GA nell’ottobre 2022.

In-toto

in-toto è un framework per attestare che un artefatto è stato costruito seguendo una supply chain definita. Fornisce:

• Definizione di layout — passi della supply chain (check-out, build, test, package)
• Metadata firmate per ogni passo
• Verification che l’artefatto finale sia il risultato del layout atteso

in-toto è lo strato di attestazione sotto SLSA/Sigstore: permette di esprimere formalmente “questo binario è derivato da questo commit Git, compilato da questo builder, testato da questa CI, firmato da questa identity”.

OpenSSF — Open Source Security Foundation

L’OpenSSF, fondata ad agosto 2020 e rilanciata post-Log4Shell, è il cuore organizzativo di queste iniziative. Al luglio 2022:

• OpenSSF Scorecard — tool automatico che valuta pratiche di sicurezza di un repo OSS (branch protection, code review, dependency update, CI tests, fuzzing, SAST, …)
• Alpha-Omega Project — programma di finanziamento diretto dei maintainer di librerie open source critiche (alpha) e di miglioramento sistematico (omega)
• CII Best Practices Badge — ereditato da Core Infrastructure Initiative, badge che indica aderenza a best practice
• OpenSSF Day — eventi pubblici per divulgazione

Regolamentazione

L’attività è trainata anche da normativa:

USA

• Executive Order 14028 (maggio 2021) — “Improving the Nation’s Cybersecurity”: richiede SBOM per software venduto al governo federale
• NIST SP 800-161 (2022) — Supply Chain Risk Management for Systems and Organizations
• CISA Secure Software Development Framework (SSDF) — NIST SP 800-218

EU

• NIS2 Directive (dicembre 2022) — include obblighi di supply chain security per entità essenziali e importanti
• Cyber Resilience Act (proposta 2022, in negoziato) — richiederà vulnerability handling strutturato e SBOM-like per prodotti con elementi digitali
• EU Cybersecurity Act (2019) già impone baseline

Italia

• ACN — agenzia nazionale operativa dall’agosto 2021, integra best practice supply chain nei propri framework
• Recepimento NIS2 con D.lgs. 138/2024

Adozione pratica

Al luglio 2022 la adozione di SBOM/SLSA è in fase iniziale ma in rapida crescita:

• Progetti OSS top-tier — Kubernetes, Istio, Envoy generano SBOM e attestations
• CI/CD platforms — GitHub Actions con GitHub Advanced Security, GitLab con CI-native security, CircleCI — supportano SBOM
• Container ecosystem — Docker Desktop include SBOM, Buildpacks, Chainguard Images
• Vendor commerciali — Snyk, Synopsys Black Duck, Veracode, Checkmarx integrano SBOM
• Cloud — AWS Inspector SBOM, GCP Software Delivery Shield, Azure con Microsoft SBOM Tool

Nel contesto italiano

Per le aziende italiane al 2022:

• Infrastrutture critiche (banche, telco, energia, sanità) sotto NIS1, e preparazione per NIS2 — inizio SBOM policy
• PA centrale — ACN coordina linee guida, obblighi per fornitori
• Sviluppatori di software commerciale — inizio integrazione SBOM nelle pipeline, specialmente per export verso USA (EO 14028) o gare NIS2-compliant
• PMI software — adozione graduale tramite strumenti open source (syft, Trivy, Dependabot) con costi contenuti

Cosa significa per chi sviluppa

Per un team di sviluppo enterprise al 2022:

1. Generare SBOM per ogni release (SPDX o CycloneDX)
2. Firmare artefatti con Sigstore o equivalenti
3. Integrare SCA nelle pipeline CI/CD (Dependabot, Renovate, Snyk, Trivy)
4. Monitorare CVE contro la baseline SBOM
5. Policy di disclosure allineata a NIS2 e framework nazionali
6. Documentazione della supply chain per audit

La pratica non è più opzionale: è compliance e requisito contrattuale in crescita.

Riferimenti: SPDX (Linux Foundation, ISO/IEC 5962:2021). CycloneDX (OWASP). SLSA (Google, 2021; 1.0 aprile 2023). Sigstore (Linux Foundation, 2021; GA ottobre 2022). in-toto. OpenSSF (2020-). US Executive Order 14028 (maggio 2021). NIS2 Directive (dicembre 2022). EU Cyber Resilience Act (proposta 2022).