SBOM vs SLSA

What is an SBOM?

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of the components that make up a piece of software — direct and transitive dependencies, versions, licenses, and supplier metadata. It is the ingredients label for an artifact, typically expressed in SPDX or CycloneDX and generated at build time.

The problem an SBOM solves is visibility. Modern software is assembled from hundreds of open-source packages, most of them transitive dependencies no engineer chose directly. When a critical vulnerability lands in a widely used library — the Log4Shell pattern — the first question every security team asks is "are we affected, and where?" Without an SBOM, that question takes days of manual grepping across repos and container images. With one, it is a query against a known inventory.

An SBOM lives with the artifact. Its natural home is the release: attached to a container image, a binary, or a deployment manifest, and refreshed on every build. Its output is a queryable answer to "what is inside this thing I am about to run, and which of those components now carry a known CVE?" What an SBOM does not tell you is whether the inventory itself is honest — a bill of materials can be generated after the fact, or on a compromised builder, and still look correct.

What is SLSA?

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework for build integrity. Stewarded by the OpenSSF, it defines graduated levels of assurance about how an artifact was produced — culminating in signed, tamper-evident provenance that ties a released artifact back to the exact source and build process that created it.

The problem SLSA solves is trust in the build chain, not the ingredients. The most damaging supply-chain attacks — SolarWinds, the injected build step — did not tamper with a listed dependency; they tampered with the pipeline that assembled the release. SLSA raises the bar in tiers: producing provenance at all, ensuring that provenance is generated by the build platform rather than a developer’s laptop, and hardening the builder so the attestation cannot be forged. The result is a signed statement — "this artifact was built from this commit, by this pipeline, with no unauthorized steps" — that a consumer can verify before deploying.

SLSA lives in the pipeline. Its natural home is the CI/CD system, the build platform, and the artifact registry. Its output is not an inventory but an attestation of integrity — cryptographic evidence of provenance that makes the build tamper-evident. What SLSA does not tell you is what is actually inside the artifact; a perfectly built release can still ship a vulnerable dependency. That is the SBOM’s job.

Why are SBOM and SLSA complementary, not competing?

SBOM and SLSA answer two different questions — "what is in it?" and "how was it built?" — and each is weak without the other. An SBOM without provenance can be forged on a compromised builder; SLSA provenance without an SBOM cannot answer "am I affected by this CVE?" Together they give you a trustworthy inventory: an honest list of components, plus tamper-evident evidence that the list — and the artifact — came from where it claims.

The reason you need both is that a supply-chain claim has two independent failure modes. The first is a bad ingredient: a component in the artifact carries a known vulnerability. The SBOM catches that. The second is a lying label: the artifact was tampered with during the build, so whatever inventory it ships is untrustworthy. SLSA catches that. A high SLSA level makes the SBOM believable — the provenance vouches that the inventory was generated by the real pipeline and not swapped in afterward. In practice the strongest posture is a SLSA-attested build that emits a signed SBOM as part of its provenance.

What neither an SBOM nor a SLSA attestation does — by design — is act. Both are description and detection layers. The SBOM tells you a shipped image contains a newly-disclosed vulnerable package; SLSA tells you which builds are below the provenance bar you require. Neither one bumps the dependency, rebuilds the artifact, rotates the exposed image in production, or hardens the pipeline. That remediation work still lands on an already-stretched platform or security team.

Where does autonomous remediation fit on top of both?

CloudThinker treats SBOM and SLSA output as input. Whatever generates your inventory and your provenance, its findings feed an autonomous remediation loop — DARV: Detect, Analyze, Remediate, Verify — that carries the fix through to a reversible, approved change under team policy. The supply-chain tooling describes and attests; the agent fixes and verifies.

The DARV loop is how the last mile gets closed. Detect: consume the signal — an SBOM component that just matched a new CVE, or a released artifact whose SLSA provenance falls below your required level. Analyze: trace which running workloads deploy the affected artifact and which pull request and pipeline introduced it. Remediate: generate the fix — a bumped dependency, a rebuilt and re-attested image, a hardened build step, a rotated deployment — and execute it inside a sandboxed environment. Verify: confirm the new artifact carries a clean SBOM and valid provenance and that the vulnerable version is gone from production, then write the receipt.

This only stays safe with production-side controls: brokered per-task identity, scoped credentials issued at task time, sandboxed execution where the credential lives in the environment (not the prompt), deterministic data tokenization at egress, tamper-evident audit, and per-environment approval gates. Autonomy is graduated L1–L4 — a new remediation Skill starts by proposing a diff for human approval and is promoted to autonomous action only once it has earned trust. Engineers stay on the loop, reviewing outcomes rather than triaging every SBOM diff and provenance gap by hand.

SBOM vs SLSA at a glance

Two answers to two different supply-chain questions. An SBOM inventories what is inside the artifact; SLSA attests how it was built and whether that build is tamper-evident. An autonomous remediation layer sits on top of both.

How to layer autonomous remediation on SBOM and SLSA

You do not replace your supply-chain tooling. You compose an autonomous remediation layer on top of the inventory and provenance you already produce.

1. Step 1

   Keep generating SBOMs and SLSA provenance

   Whatever emits your SBOM at build time and whatever attests your provenance in CI stays. The inventory and the signed provenance become the input the remediation agent reasons over. Do not duplicate the generation or attestation layer.

2. Step 2

   Encode the fix each finding class needs

   For every recurring finding type — an SBOM component matching a new CVE, an artifact below your required SLSA level, an unsigned build — write a remediation Skill that captures the team’s playbook: the dependency bump or pipeline change to generate, the guardrails, the rollback step, and the verification query. The Skill is the unit the agent executes. Start with your three most-repeated findings.

3. Step 3

   Graduate one Skill at a time from L1 to L4

   New Skills start at L1 — the agent proposes a scoped diff, such as a rebuilt and re-attested image, and a human approves each one. As a Skill earns trust, promote it to act-with-approval (a merge request) and then to autonomous within a defined guardrail. Time-to-remediate comes down per finding class, not per dashboard, with engineers staying on the loop.

Frequently asked questions

What is the main difference between an SBOM and SLSA?

An SBOM answers "what is inside this artifact?" — it is a machine-readable inventory of components and dependencies. SLSA answers "how was this artifact built, and can I trust it?" — it is a framework that produces tamper-evident provenance about the build process. The SBOM describes the contents; SLSA attests the integrity of how those contents were assembled.

Do I need both an SBOM and SLSA?

Yes — they cover independent failure modes and are weak alone. An SBOM without build provenance can be forged on a compromised builder, so you cannot fully trust the inventory. SLSA provenance without an SBOM proves the build was clean but cannot answer "am I affected by this new CVE?" The strongest posture is a SLSA-attested build that emits a signed SBOM as part of its provenance.

Does a high SLSA level replace scanning the SBOM?

No. A high SLSA level proves the artifact was built by a trusted, tamper-evident pipeline — but a perfectly built release can still contain a dependency with a known vulnerability. SLSA vouches for the build chain; the SBOM (scanned against vulnerability data) tells you whether the ingredients themselves are safe. You still scan the inventory.

Does CloudThinker replace my SBOM or SLSA tooling?

No — CloudThinker composes on top of them. Your existing tooling remains the inventory and attestation layer; its findings — a component matching a new CVE, an artifact below your required SLSA level — become the input CloudThinker’s autonomous remediation loop reasons over. The layers are complementary, not competitive. Teams keep their supply-chain stack and add the remediation layer above it.

How does autonomous supply-chain remediation stay safe in production?

Through production-side controls and graduated autonomy. Every remediation runs under brokered per-task identity, scoped credentials issued at task time, sandboxed execution, deterministic data tokenization at egress, tamper-evident audit, and per-environment approval gates. Autonomy is graduated L1–L4: a Skill begins by proposing a diff — say, a bumped dependency and a re-attested rebuild — for human approval, and only becomes autonomous once it has earned trust. Engineers stay on the loop, reviewing outcomes.