One tells you what's in your software. The other proves how it was built.
| SBOM | SLSA | |
|---|---|---|
| Full name | Software Bill of Materials | Supply-chain Levels for Software Artifacts |
| What it is | An inventory of all components | A framework for build integrity and provenance |
| Analogy | Nutrition label on a food product | Food safety handling guidelines |
| Answers the question | What's in this software? | Was this software built securely? |
| Formats | CycloneDX, SPDX | Provenance attestations (in-toto/SLSA format) |
| Levels/tiers | No levels — you have one or you don't | 4 levels of increasing assurance |
| Tooling | Syft, Trivy, cdxgen | SLSA GitHub Generator, Sigstore, Witness |
| When it helps | Incident response — "are we affected by CVE-X?" | Tamper detection — "was our build pipeline compromised?" |
When Log4Shell hit in December 2021, organizations with SBOMs could answer "do we use Log4j?" in minutes. Everyone else spent days or weeks auditing. That's the SBOM value proposition — you know what's in your software.
SLSA solves a different problem: how do you know the binary you're running was actually built from the source code you reviewed? Without build provenance, an attacker who compromises your CI/CD pipeline can inject malicious code that never appears in your repository.
SBOM tells you the ingredients. SLSA tells you the ingredients weren't tampered with during preparation. Neither is sufficient alone. An SBOM generated from a compromised build is useless. SLSA provenance without knowing what dependencies were included doesn't help with vulnerability response.
SBOM first — it's simpler and the payoff is immediate. Generate one with Syft or Trivy, feed it into a vulnerability scanner, and you have dependency visibility. Then layer on SLSA for your most critical build pipelines. You can reach SLSA Level 2 in an afternoon with GitHub Actions.