How would you modify CI/CD to generate and sign SLSA provenance?

WHAT THIS TESTS: Deep familiarity with the SLSA Build Track specification and the ability to map its requirements onto a real CI/CD architecture. The interviewer wants to see that you understand the difference between provenance (how an artifact was built) and SBOMs or image signatures, that you know why runner isolation matters for L2 and L3, and that you can reason about trust boundaries between the pipeline orchestrator, the build executor, and the artifact consumer.

A GOOD ANSWER COVERS: Four layers in order. First, pipeline instrumentation: the pipeline must generate an in-toto attestation containing the builder ID, the source repository and commit SHA, the build definition digest, the resolved dependencies, and the output artifact digest. This should be produced automatically by the build service, not by user-defined steps. Second, runner hardening: for SLSA Build Level 2 the runner must be hosted and ephemeral, and for Level 3 it must be isolated from user control so that build steps cannot tamper with the provenance generation. Third, signing infrastructure: sign the attestation using DSSE and either Sigstore or HSM-backed keys. The signing identity should belong to the build platform, not an individual engineer. Fourth, artifact repository integration: store the signed provenance attestation alongside the artifact or in an attestation store linked by digest, expose verification APIs, and enforce policy checks at deploy time.

COMMON WRONG ANSWERS: Confusing an SBOM or a container image signature with SLSA provenance. Provenance describes the build process, not the contents. Another red flag is proposing manual signing steps inside the pipeline or using long-lived self-hosted runners that lack isolation guarantees. Suggesting that the CI YAML itself is sufficient provenance is also incorrect because it does not capture the resolved dependencies or the builder identity.

LIKELY FOLLOW-UPS: How would you achieve Build Level 3 if you currently use self-hosted runners? How do you prevent a compromised dependency from tampering with the provenance? What is your revocation strategy if the build platform signing key is leaked? How do you verify provenance at deployment time in a Kubernetes cluster?

ONE CONCRETE EXAMPLE: A GitHub Actions workflow reaches SLSA Build Level 3 by using GitHub-hosted runners with an OIDC-issued identity token. The workflow calls a reusable builder that generates an in-toto provenance attestation including the repository, commit, workflow filename, and artifact SHA256. The attestation is signed with Sigstore cosign using the runner's OIDC token. The resulting .intoto.jsonl file is uploaded to GitHub Releases next to the artifact. A consumer policy in Kyverno rejects any container image that lacks a valid attestation signed by that builder identity.