Strengthening Software Supply Chains: Harmonizing SLSA Provenance and SPDX SBOM for Better Adoption

## Overview This panel discussion explores how SLSA (Supply Chain Levels for Software Artifacts) and SPDX (Software Package Data Exchange) provide complementary approaches to securing software supply chains. Moderated by David Wheeler of the OpenSSF/Linux Foundation, panelists from Google, Linux Foundation, and Carnegie University's Software Engineering Institute discuss adoption, gaps, and future directions for these standards.

## SLSA Framework SLSA was created to address supply chain attacks like SolarWinds, where compromised build systems generated malicious artifacts that passed signature verification. SLSA defines three tracks: - Build track: Records materials and processes, linking outputs to repositories, build systems, action identities, and triggering individuals; tamper-proof at higher levels - Source track: Controls git commits to prevent malicious alterations; levels range from basic history requirements to fully reviewed, history-protected commits - Dependency track: Manages software dependencies (merging with S2C2F project)

SLSA has multiple maturity levels: Level 1 is documentation only; higher levels provide tamper-proof artifacts and provenance even during the build process.

## SPDX Standard Established in 2009, SPDX has evolved from software-focused documentation to support systems, AI, and datasets through SPDX 3.0 (released approximately one year prior). It enables: - File-level vulnerability analysis (not just component level) - Safety case modeling with requirements and traceability - Full reproducibility in embedded systems (Yocto, Zephyr) - AI-specific metadata (AI Bomb) to track datasets, energy consumption, and model evaluations

## Adoption and Gaps Current adoption: GitHub Actions generates SLSA attestations; SPDX2 has strong industry adoption in scanning tools; SPDX3 tooling is emerging with Java libraries mature and Python/Go still maturing. However, SLSA for ML pipelines and Jupyter notebooks remains unimplemented. The largest barrier is not tooling but organizational mindset—tools exist and can be automatically generated in CI/CD pipelines, but integration remains slow.

## Critical Synergies The panelists emphasize that SLSA (process-focused) and SPDX (output-focused) are complementary and both essential. SLSA alone doesn't show artifact contents; SPDX alone doesn't show how it was built. A Log4j case study illustrated this: one healthcare organization spent 75% of time determining if they had Log4j in their system (SPDX problem) and 50% ensuring correct builds (SLSA problem). Together, both enable incident response and compliance automation. Hassan stressed the analogy: "We look at the menu (SPDX), recipes (SLSA), and authorize every step (pipeline)." Future vision includes AI model provenance tracking fine-tuning, checkpoints, and data lifecycle changes to enable rapid incident investigation and compliance decisions.

## Takeaways Multiple verification points throughout pipelines are necessary (SolarWinds lesson). Artifacts and SBOMs must be paired with matching versions in deployment, not separated. Regulatory landscapes (EU CRA Act, US initiatives) will shift definitions of SBOM, so capturing maximum metadata now provides robustness. Five-year goal: automate continuous compliance for safety-critical systems (automotive, medical, aerospace) by running security and safety analyses within build flows. Final advice: "Trust but verify"—check hashes and components; engage community rather than solving problems in isolation.