Integrate artifact signing and vulnerability scanning into CI/CD

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: NIST SP 800-204D