TL;DR: An SBOM says what is inside the artifact. SLSA says how trustworthy the process that built it was. Sigstore verifies the signing identity and artifact integrity; builder identity requires trusted provenance. Ingredients, process integrity, and identity. None of them is useful until something refuses to deploy an artifact that fails the check.
How to approach it
Give each one as the question it answers, in one line. Then explain enforcement, because a supply chain story with no admission gate is documentation rather than security.
A strong answer
SBOM answers "what is in this?" A machine-readable inventory of identified components and versions in the artifact, whose completeness depends on the generator and inputs, in SPDX or CycloneDX format, generated at build time when the dependency tree is known rather than reconstructed later by scanning. Its value is measured in one number: how long it takes to answer "are we affected" when a vulnerability is disclosed. With SBOMs it is a query in minutes; without them it is days of grepping repositories, and you will be doing it under pressure.
SLSA answers "how was this built, and could it have been tampered with?" A framework of levels describing build integrity: that the build is scripted rather than run by hand, that it happens on a hosted service rather than a laptop, that provenance is generated automatically describing the source commit and the builder, and at higher levels that builds are isolated and non-falsifiable. The point is that a signed artifact from a compromised build process is still compromised, so signing alone is insufficient. Provenance is the attestation that links the artifact back to a specific commit and a specific builder.
Sigstore answers "who signed this and has it changed?" Keyless signing: Cosign requests a short-lived certificate from Fulcio using an OIDC identity, signs the artifact, and records it in Rekor, a public transparency log. The keyless part is the innovation, because the hardest problem in signing was always key management, and here there is no long-lived key to store or rotate. The transparency log means a signature cannot be created retroactively without evidence.
Together they answer a full question: this image was built from that commit, by that pipeline, contains these components, and was signed by that identity.
Enforcement is what makes it real. All of the above is metadata until an admission controller refuses workloads that lack it. In Kubernetes that is Kyverno or Gatekeeper integrated with a verifier such as Ratify, checking signature and provenance before pod creation. This is a Kyverno verifyImages rule fragment:
verifyImages:
- imageReferences: ["registry.example.com/*"]
attestors:
- entries:
- keyless:
subject: "https://github.com/myorg/myrepo/.github/workflows/build.yaml@refs/heads/main"
issuer: "https://token.actions.githubusercontent.com"
The subject condition is the security boundary, exactly as with OIDC federation: verifying that something is signed without verifying who signed it accepts any valid signature from anyone.
The rollout order that works: generate first and observe, then warn, then enforce on new workloads, then enforce everywhere. Enforcing on day one blocks every existing deployment and the policy gets disabled within the hour.
What interviewers probe next
"What attack does this prevent that scanning does not?" A compromised build system injecting code that is not in the source. Trusted build provenance can bind the artifact to expected source and builder policy, but a compromised authorized builder may issue malicious artifacts with valid attestations. Builder isolation and trust assumptions still matter. Sigstore verification.
"Where does the SBOM live?" Attached to the image as an attestation in the registry, so it travels with the artifact rather than sitting in a system that can drift out of sync.
"Is a private transparency log worth it?" If you cannot publish that an artifact exists, yes. Rekor can be self-hosted, at the cost of the public verifiability that makes the log valuable.
Common mistakes
Treating the three as interchangeable, or as three tools that all do signing.
Stopping at generation. Producing attestations nothing verifies is theatre.
Verifying signature validity without pinning the signer identity, which accepts a genuine signature from an attacker.