#Quick Answer: What do SBOMs and SLSA do for software supply chain security?
An SBOM (software bill of materials) is a machine-readable inventory of every component in your software — dependencies, versions, licenses, suppliers. SLSA (Supply-chain Levels for Software Artifacts) is an OpenSSF specification proving how software was built, via signed build provenance. SBOM answers what is inside; SLSA answers whether the build can be trusted. Together they form the baseline of software supply chain security, now expected by regulated buyers.
#Why Software Supply Chain Attacks Keep Succeeding
Software supply chain security fails not because teams ignore it, but because they defend the wrong layer. Most AppSec programs scan application code for vulnerabilities while the actual attack arrives through the pipeline: a compromised maintainer account, a malicious dependency update, or a build server that quietly injects code after review. The pattern repeats in every major incident of the last decade. Attackers realized that compromising one widely-used component — a build tool, a logging library, a CI plugin — yields thousands of downstream victims for the effort of one breach.
The economics favor the attacker. A typical enterprise application pulls in hundreds or thousands of open-source packages, most of them transitive dependencies the development team has never heard of. Each package is a trust decision delegated to a stranger. Maintainers burn out, accounts get phished, and typosquatting packages sit one character away from the library you meant to install. Meanwhile the build pipeline itself — CI runners, artifact registries, signing keys — is often the least hardened part of the infrastructure, despite having write access to everything shipped.
Regulators noticed before most engineering teams did. Software sold to the US federal government must now ship with SBOMs under Office of Management and Budget memoranda, and CISA's Secure by Design guidance pushes vendors to take responsibility for the security of the software they deliver. The message is consistent: you cannot secure what you cannot inventory, and you cannot trust artifacts whose production you cannot verify. That is exactly the gap SBOMs and SLSA are designed to close.
#SBOMs: What's Inside Your Software
An SBOM is a formal, machine-readable record listing the components in a piece of software: package names, exact versions, licenses, suppliers, and the relationships between them. The two dominant formats are SPDX (an ISO/IEC standard, ISO/IEC 5962:2021) and CycloneDX (an OWASP flagship project standardized through Ecma International). Both are supported by broad tooling, and both can express the NTIA's minimum elements for an SBOM: supplier, component name, version, other unique identifiers, dependency relationship, author, and timestamp.
The single most important property of a useful SBOM is completeness of the dependency graph. An SBOM that lists only direct dependencies is a partial inventory — in most modern ecosystems, transitive dependencies outnumber direct ones by an order of magnitude, and a vulnerability in a transitive dependency is exactly as exploitable as one in a direct one. Tools like Syft (Anchore), cdxgen, and Trivy (Aqua Security) resolve the full graph, and each component should carry a package URL (purl) so it can be identified unambiguously across ecosystems.
Generate the SBOM in CI, at the same step that produces the artifact. An SBOM generated on a developer's laptop a week after release is archaeology, not security. Store the SBOM alongside the artifact — in the container registry, the release assets, or a dedicated SBOM repository — so that consumers, auditors, and your own incident responders can find it when a new CVE drops. The operational payoff arrives on disclosure day: when the next critical vulnerability in a ubiquitous library is announced, the team with complete SBOMs answers "are we affected?" in minutes with a query, while everyone else starts a week of manual triage.
SBOMs also change the vendor conversation. Requesting SBOMs from your suppliers — and publishing them for your customers — turns supply chain security into a contractual, checkable property instead of a questionnaire answer. This pairs naturally with broader application security discipline, including hardening SaaS APIs against BOLA and mass assignment, because the dependencies you ship determine the attack surface your APIs expose.
#SLSA: Proving How Your Software Was Built
If SBOMs answer "what is inside," SLSA answers "can I trust how it was made." SLSA (Supply-chain Levels for Software Artifacts) is an OpenSSF specification defining a ladder of build-integrity levels. The build track is the most developed: SLSA 1.0, published in April 2023, defines Build L0 through L3, with version 1.1 (April 2025) adding clarifications to the threat and attestation models, and version 1.2 (late 2025) introducing a Source Track covering threats in code authoring and review.
The levels are cumulative and practical. Build L1 means provenance exists: the build emits a machine-readable description of the platform, process, and top-level inputs. It catches honest mistakes but is unsigned and forgeable. Build L2 moves the build onto hosted infrastructure and has the platform sign the provenance — GitHub Actions, Google Cloud Build, or GitLab shared runners instead of a developer's laptop — so tampering after the build is detectable. Build L3 hardens the platform itself: isolated build environments, and signing keys inaccessible to user-defined build steps, so forging provenance requires exploiting the build platform. GitHub's Artifact Attestations, built on Sigstore's keyless signing, gets a well-shaped workflow to L3 with minimal ceremony.
The threat model is what makes SLSA worth the effort. SLSA explicitly assumes the adversary may control source dependencies, may attempt to tamper during the build, or may substitute artifacts after the build. Each level closes one of those doors. This matters because the most damaging supply chain incidents — from the SolarWinds compromise to the XZ Utils backdoor — targeted the build process and the developer toolchain rather than introducing known-vulnerable components. An SBOM is blind to that class of attack; the component list is accurate, and the code is still malicious. Provenance verification is the control that catches it: the artifact must provably come from the claimed source, built by the claimed pipeline.
Note that SLSA is not only for traditional software. The same ladder maps cleanly onto ML pipelines: training provenance that records datasets, hyperparameters, code versions, and environment is the model-supply-chain equivalent of Build L1, and the discipline only gets more valuable as AI models become dependencies themselves — a risk OWASP tracks as LLM03 in its Top 10 for LLM applications.
#Putting SBOM and SLSA Together in Your CI Pipeline
The combination works because the two controls cover complementary questions at complementary times. In practice, a solid pipeline looks like this: on every release build, the CI job generates a full-graph SBOM with Syft or cdxgen, runs a vulnerability scan against it with Trivy or Grype, and fails the build on critical vulnerabilities without an approved exception. The same job produces SLSA provenance — via the slsa-github-generator or native artifact attestations — and signs both the artifact and the SBOM with Sigstore, so verification needs no long-lived keys to manage.
Verification is the part most teams skip, and it is the part that makes the rest meaningful. Publishing provenance nobody checks is theater. At minimum, verify provenance at deploy time: the deployment pipeline should refuse artifacts whose provenance does not match the expected builder and source repository. For container workloads, admission controllers can enforce this policy in the cluster. For libraries consumed by other teams, publish the SBOM and attestation where downstream consumers can verify them automatically.
Store everything in queryable form. The OpenSSF's GUAC project (Graph for Understanding Artifact Composition), which reached 1.0 in mid-2025, ingests SBOMs, SLSA provenance, and vulnerability data into a knowledge graph that answers supply-chain-wide questions: which of our services transitively depend on this library, which builds lack provenance, where is the blast radius of a compromised maintainer. Even without GUAC, keeping SBOMs in a central store with an index turns incident response from archaeology into a database query.
Start where the risk is highest. You do not need L3 everywhere on day one. A realistic rollout: SBOMs for every shipped artifact first, then SLSA L2 via hosted builders and signed provenance, then L3 for the handful of critical components where a build compromise would be existential — your authentication service, your signing infrastructure, your base images. Measure progress by the percentage of production artifacts with complete SBOMs and verified provenance, not by the number of tools purchased.
#Field Lessons: Mistakes That Waste the Effort
The most common failure is generating SBOMs and never consuming them. Teams wire Syft into CI, upload the JSON to a release asset, and declare victory — then, when a CVE drops, still grep through Dockerfiles by hand because nobody built the index or the query workflow. An SBOM is only as useful as the system that can search it under time pressure. Build the query path before you need it, and drill it: pick a past CVE and time how long it takes your team to answer "where are we exposed."
The second failure is trusting the SBOM of a component you did not build while ignoring its provenance. A dependency's SBOM tells you its declared ingredients, but if the build was compromised, the SBOM describes software that was never actually shipped. Verify provenance for the dependencies that matter most — the ones with network access, the ones that handle credentials, the ones everything else depends on — and prefer suppliers who publish both.
Third: frontend dependency sprawl gets a pass it should not get. Node projects routinely ship thousands of transitive packages, and teams treat npm as a trusted utility rather than the largest unvetted code-import surface in the company. Lockfiles, scoped registries, and install-time auditing belong in the same program as your container SBOMs. A zero-trust approach to frontend architecture — assuming every dependency is hostile until verified — is the right mental model, and SBOMs give it teeth.
Finally, do not confuse compliance with security. Shipping an SBOM because a customer contract requires one, generated by a tool nobody configured correctly, produces a document that is wrong in ways that matter: missing transitive dependencies, stale versions, components that are not actually in the artifact. An inaccurate SBOM is worse than none, because it creates false confidence. Validate generated SBOMs against the actual artifact contents, and treat SBOM accuracy as a quality gate, not a checkbox.
#Frequently Asked Questions
Do small teams really need SBOMs and SLSA, or is this enterprise-only overhead?
The tooling cost is near zero — Syft, cdxgen, Trivy, and Sigstore are free, and GitHub Artifact Attestations requires only workflow configuration. The real cost is operational discipline: storing, indexing, and querying the data. Small teams actually benefit disproportionately, because the first time a critical CVE drops, a five-person team with searchable SBOMs triages in an afternoon instead of losing a week. Start with SBOM generation in CI; add provenance when you have the bandwidth.
What is the difference between an SBOM and a lockfile?
A lockfile pins the exact dependency versions your build resolved, and it is a build input. An SBOM is a standardized, shareable inventory of what ended up in the shipped artifact, including licenses, suppliers, and dependency relationships, expressed in SPDX or CycloneDX. Lockfiles are for reproducibility; SBOMs are for transparency and incident response. You should have both, and generating the SBOM from the locked build keeps them consistent.
Can SLSA prevent a malicious maintainer from shipping a backdoor?
Not by itself, and this is an important boundary to understand. SLSA proves the artifact was built from the claimed source by the claimed pipeline — it defeats build-time tampering and artifact substitution. It does not judge whether the source code itself is benign. A malicious commit by a legitimate maintainer, like the XZ Utils backdoor, passes SLSA verification because the build is faithful to a compromised source. That threat is addressed by the SLSA Source Track, code review requirements, and maintainer-trust controls — provenance tells you the build is honest, not that the code is safe.
Which SBOM format should we choose, SPDX or CycloneDX?
Choose based on your ecosystem and consumers, not on format ideology. Both are open standards with broad tooling, and converters exist between them. CycloneDX has strong momentum in vulnerability-management tooling and tends to be simpler to adopt for application teams. SPDX is an ISO standard with deep roots in license compliance, which matters if legal teams consume your SBOMs. The worst choice is generating neither while debating which is better.
#Sources and Further Reading
- SLSA specification v1.0 and levels — slsa.dev/spec/v1.0/levels
- OpenSSF GUAC 1.0 announcement — guac.sh/blog/2025/06/guac-v1.0
- NTIA minimum elements for an SBOM — ntia.gov/page/software-bill-materials
- CISA Secure by Design guidance — cisa.gov/securebydesign
- OWASP CycloneDX project — owasp.org/www-project-cyclonedx
- SPDX specification (ISO/IEC 5962:2021) — spdx.dev/specifications
- Sigstore keyless signing — sigstore.dev
- GitHub Artifact Attestations documentation — docs.github.com/actions/security-guides/using-artifact-attestations