How would you integrate artifact signing into CI/CD and secure the keys?

WHAT THIS TESTS: Supply chain security architecture and the operational maturity to protect high-value cryptographic material inside automated pipelines. The interviewer cares whether you treat build runners as untrusted ephemeral infrastructure and whether you understand that a signing key is a production secret that demands stronger controls than a database password.

A GOOD ANSWER COVERS four layers. First, isolation: move signing off the build runner entirely by using a remote HSM, cloud KMS, or dedicated signing-as-a-service platform so the private key never touches disk on ephemeral compute. Second, enforcement: make signature verification a hard gate in the deployment phase; the orchestrator or admission controller must reject any artifact that lacks a valid signature or whose certificate has expired. Third, key lifecycle: use short-lived certificates, automate rotation, protect the root of trust in an offline or hardware-backed certificate authority, and maintain a revocation mechanism for compromised keys. Fourth, audit and access control: bind every signing event to an authenticated identity, require multi-party approval for sensitive keys, and stream immutable logs to a SIEM.

COMMON WRONG ANSWERS: Storing the private key in a CI variable or repository secret. Performing signing on the same node that compiles the artifact. Using one long-lived key across every service with no rotation plan. Skipping signature verification at deploy time, which turns signing into theater. Allowing developers to sign artifacts from laptops without oversight.

LIKELY FOLLOW-UPS: How would you handle signing in air-gapped or multi-cloud environments? What is your incident response plan if a signing key is exfiltrated? How do you minimize latency when thousands of artifacts need signing daily? Would you use Sigstore or a traditional PKI, and why?

ONE CONCRETE EXAMPLE: A Kubernetes pipeline builds a container image and produces a digest. A post-build job sends that digest to a cloud KMS or Sigstore Fulcio, obtains a short-lived certificate, and pushes the signature to an OCI registry and a transparency log like Rekor. The cluster admission controller, such as Kyverno or Connaisseur, verifies the signature against a pinned identity before scheduling the pod. The private key never leaves the KMS, developers cannot sign locally, and every operation is logged to a centralized SIEM.

Source: keyfactor.com