Integrate artifact signing and vulnerability scanning into CI/CD
Designing CI/CD gating with non-repudiable artifacts and automated trust.
Build SBOMs, sign with ephemeral keys, scan registries, and enforce policy before deploy.
Signing after deploy or long-lived keys in CI.
What's really being asked
This question evaluates whether you can design a defense-in-depth software supply chain where trust is cryptographic and enforcement is automated. The interviewer wants to see that you understand the difference between detecting vulnerabilities and proving artifact integrity, and that you know how to sequence these controls so they actually block bad artifacts before they reach production.
The full answer
First, build-time generation of an SBOM and provenance attestation so every artifact carries its own bill of materials and build metadata. Second, artifact signing immediately after build completion using either a keyless approach like Sigstore Fulcio and Rekor or short-lived keys from a KMS or HSM, ensuring non-repudiation without long-lived secrets in CI. Third, vulnerability scanning of the packaged artifact in the registry using scanners that consume the SBOM, with severity thresholds such as CVSS 7.0 or higher that fail the pipeline. Fourth, a release approval gate that combines scan results, signature verification, and policy rules such as SLSA Level 3 requirements before the artifact is promoted to a production repository. Fifth, deploy-time verification where the orchestrator or admission controller checks signatures and SBOM policy again so the runtime environment never pulls an unapproved artifact.
The mistakes people make
Signing the artifact only after it has been deployed to staging or production, which leaves earlier environments untrusted. Storing a persistent private key in a CI environment variable or secret store where any compromised build job can exfiltrate it. Scanning source code but not the final packaged artifact or base image, missing supply chain dependencies introduced at build time. Relying on manual security team approval for every release instead of automated policy gates, which creates a bottleneck and inconsistent enforcement.
What usually comes next
How would you rotate signing keys without invalidating previously signed artifacts? What would you do if a critical CVE is found in an already-signed artifact that passed all earlier gates? How do you prevent a malicious insider from tampering with the SBOM or attestation stored alongside the artifact? Can you explain how SLSA provenance maps to the stages you just described?
A concrete example
Imagine a container image built in GitHub Actions. The workflow uses buildkit to generate an SBOM in SPDX format and signs the image with cosign and Fulcio, producing a certificate bound to the workflow identity. The image is pushed to a registry where Trivy or Grype scans it against NVD; any critical CVE fails the workflow. A separate release pipeline runs on a hardened controller that verifies the cosign signature, checks the SBOM against an allow-list of approved base images, and only then copies the image to a production registry protected by an admission webhook. The Kubernetes cluster running the workload uses a policy engine like Kyverno to reject any pod whose image lacks a valid signature and recent scan attestation.
Interview question
Which sequencing of supply chain controls in CI/CD achieves non-repudiable artifacts and automated gating before production deployment?
- a.Build the container image, scan only the base image for CVEs before build, sign the artifact after pushing to the registry, promote to production following successful staging tests, and block unapproved images using registry RBAC policies.
- b.Scan source code for vulnerabilities before building, push the artifact to a staging registry, sign it after integration tests pass, require manual security approval for every production release, and store the signing key in the CI environment variables.
- c.Generate an SBOM and provenance attestation at build time, sign the artifact immediately after build with ephemeral keyless credentials, scan the packaged image in the registry against severity thresholds, enforce automated policy gates combining signature and scan results before production promotion, and validate signatures at deploy time via an admission controller.Correct
- d.Generate an SBOM during build, sign the artifact with a persistent private key stored in the CI secret store, scan the packaged image in the registry and fail on CVSS 7.0+, promote approved images to production, and skip runtime verification since the registry is trusted.
Why? this is the answer
Option C is correct because it sequences SBOM generation, immediate ephemeral signing, registry scanning, automated policy gating, and deploy-time admission control as required for defense-in-depth. Option D is tempting because it includes SBOMs and registry scanning, but storing a persistent private key in CI and skipping runtime verification breaks non-repudiation and leaves production exposed to registry compromise.
Just read this? Test yourself on what you have been reading.
Read the original → csrc.nist.gov
- #ci/cd
- #supply chain security
- #devsecops
- #artifact signing
- #vulnerability scanning
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles