SBOM and SLSA: software supply chain security becomes a discipline

CyberScan

Vulnerability assessment and automated pentest. Continuous asset discovery, AI risk prioritisation, integrated NIS2 compliance manager.

Discover CyberScan →

DataGovern

Integrated compliance platform GDPR + NIS2 + EU AI Act. Cross-Regulation Gap analysis, board-ready dashboard, on-premise.

Discover DataGovern →

Cybersecurity

CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.

Discover →

After Log4Shell, the industry reacts

December 2021 — Log4Shell makes visible to all the problem security engineers had flagged for years: modern applications depend on hundreds or thousands of Open Source libraries whose inventory, origins, maintainers, attack surface are unknown. The basic question — “do we use Log4j? in which versions?” — led thousands of CISOs to discover they could not answer in reasonable time.

In the following months the industry reacts with a series of coordinated initiatives consolidating Supply Chain Security as a discipline. By July 2022 the operational picture is consistent, with frameworks, tools and early regulation.

SBOM — Software Bill of Materials

An SBOM is a structured inventory of software components, analogous to a bill of materials in industrial manufacturing. For each component: name, version, licence, cryptographic hash, upstream source, transitive dependencies, any known CVEs.

Two standard formats coexist:

SPDX

Software Package Data Exchange, Linux Foundation initiative started in 2010. Standardised as ISO/IEC 5962:2021 in October 2021. Initially oriented to licence tracking, it evolved support for vulnerability information in SPDX 2.3 (2022). Formats: JSON, YAML, tag-value, RDF/XML.

CycloneDX

OWASP initiative, released in 2017. Natively oriented to vulnerability management and supply chain security. Formats: JSON, XML, Protobuf. Version 1.4 (January 2022) introduces support for Vulnerability Exploitability eXchange (VEX) — declarations on which CVEs affect an artefact.

The two formats are complementary: organisations often produce both to satisfy different uses.

Tools to generate SBOM

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

SLSA — Supply-chain Levels for Software Artifacts

SLSA (pronounced salsa) is a framework launched by Google in June 2021 in response to supply chain incidents (SolarWinds 2020, Codecov 2021). In July 2022 0.1 is in use and drafts evolve toward the first public version 1.0, expected in the following months.

SLSA defines four maturity levels (0-4, later simplified) for the build chain of a software artefact:

• SLSA 0 — no requirements
• SLSA 1 — build with provenance generation (who, what, how, where it was built)
• SLSA 2 — signed and verifiably-hosted provenance
• SLSA 3 — build in isolated environment (ephemeral, hermetic), source tracked
• SLSA 4 — two-party review of every change, verified reproducibility

Each level adds concrete requirements on: source, build, dependencies, provenance. The framework is usable as maturity target: an organisation declares at which level it operates for each artefact.

Sigstore

Sigstore is a Linux Foundation project (with Red Hat, Google, Purdue, Chainguard) launched in March 2021 to standardise software artefact signing with simple, free infrastructure:

• cosign — CLI to sign/verify container images, SBOMs, generic artefacts
• Fulcio — short-lived CA (certificates valid for minutes) based on OIDC — sign without long-term private key management
• Rekor — transparency log (append-only ledger) for all Sigstore signatures
• Gitsign — Git commit signing via Sigstore

The model eliminates the historical “who manages the private key” problem: each signature uses an ephemeral key derived from OIDC identity (Google, GitHub, Azure), logged in transparency log, verifiable without needing public key management.

Sigstore’s general availability is expected by the end of 2022.

In-toto

in-toto is a framework to attest that an artefact was built following a defined supply chain. It provides:

• Layout definition — supply chain steps (check-out, build, test, package)
• Signed metadata for each step
• Verification that the final artefact is the result of the expected layout

in-toto is the attestation layer under SLSA/Sigstore: it lets one formally express “this binary is derived from this Git commit, compiled by this builder, tested by this CI, signed by this identity”.

OpenSSF — Open Source Security Foundation

OpenSSF, founded in August 2020 and relaunched post-Log4Shell, is the organisational heart of these initiatives. As of July 2022:

• OpenSSF Scorecard — automatic tool evaluating OSS repo security practices (branch protection, code review, dependency update, CI tests, fuzzing, SAST, …)
• Alpha-Omega Project — direct funding programme for maintainers of critical Open Source libraries (alpha) and systematic improvement (omega)
• CII Best Practices Badge — inherited from Core Infrastructure Initiative, badge indicating adherence to best practices
• OpenSSF Day — public events for outreach

Regulation

Activity is also driven by regulation:

USA

• Executive Order 14028 (May 2021) — “Improving the Nation’s Cybersecurity”: requires SBOM for software sold to the federal government
• 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 — expected to be adopted by the end of 2022, will include supply chain security obligations for essential and important entities
• Cyber Resilience Act (2022 proposal, in negotiation) — will require structured vulnerability handling and SBOM-like for products with digital elements
• EU Cybersecurity Act (2019) already imposes baseline

Italy

• ACN — national agency operational since August 2021, integrating supply chain best practice into its frameworks

Practical adoption

As of July 2022 SBOM/SLSA adoption is in initial phase but rapidly growing:

• Top-tier OSS projects — Kubernetes, Istio, Envoy generate SBOM and attestations
• CI/CD platforms — GitHub Actions with GitHub Advanced Security, GitLab with CI-native security, CircleCI — support SBOM
• Container ecosystem — Docker Desktop includes SBOM, Buildpacks, Chainguard Images
• Commercial vendors — Snyk, Synopsys Black Duck, Veracode, Checkmarx integrate SBOM
• Cloud — AWS Inspector SBOM, GCP Software Delivery Shield, Azure with Microsoft SBOM Tool

In the Italian context

For Italian companies in 2022:

• Critical infrastructures (banks, telco, energy, healthcare) under NIS1, and preparing for NIS2 — starting SBOM policy
• Central PA — ACN coordinates guidance, supplier obligations
• Commercial software developers — starting SBOM integration in pipelines, especially for US export (EO 14028) or NIS2-compliant tenders
• SME software — gradual adoption via Open Source tools (syft, Trivy, Dependabot) at contained cost

What it means for developers

For an enterprise development team in 2022:

1. Generate SBOM per release (SPDX or CycloneDX)
2. Sign artefacts with Sigstore or equivalents
3. Integrate SCA in CI/CD pipelines (Dependabot, Renovate, Snyk, Trivy)
4. Monitor CVEs against the SBOM baseline
5. Disclosure policy aligned with NIS2 and national frameworks
6. Document the supply chain for audits

The practice is no longer optional: it is compliance and a growing contractual requirement.

References: SPDX (Linux Foundation, ISO/IEC 5962:2021). CycloneDX (OWASP). SLSA (Google, 2021). Sigstore (Linux Foundation, 2021). in-toto. OpenSSF (2020-). US Executive Order 14028 (May 2021). EU Cyber Resilience Act (2022 proposal).