Vulnerability scanning as a deploy gate

WHAT THIS TESTS This checks whether you can build an enforcing security gate across CI and admission, balancing strictness against developer flow.

A GOOD ANSWER COVERS Shift scanning left: after the image is built in CI, run a scanner such as Trivy, Clair, or Grype against it, configured to exit non-zero when it finds vulnerabilities at or above a chosen severity, for example HIGH and CRITICAL with fixes available. A non-zero exit fails the pipeline and blocks promotion. Push only passing images to the registry, and add a second line of defense at deploy time: sign images with cosign and use an admission controller or policy engine to reject unsigned or policy-violating images, or rely on a registry that enforces a scan policy before pull. Maintain a reviewed ignore file for CVEs that are unfixable or not exploitable in your context, with expiry, so the gate stays meaningful rather than universally bypassed.

COMMON WRONG ANSWERS Scanning only in production or as a non-blocking report. Treating every CVE as equal regardless of fix availability or reachability. Blanket-ignoring findings to keep builds green. Relying on a single gate with no admission-time enforcement.

LIKELY FOLLOW-UPS How do you handle CVEs with no upstream fix? Where do you cache the vulnerability database? How does signing complement scanning? How do you avoid blocking on noisy false positives?

ONE CONCRETE EXAMPLE A pipeline stage runs trivy image --severity HIGH,CRITICAL --exit-code 1 --ignore-unfixed on the freshly built tag. If it finds a fixable critical CVE, the job fails and the image never reaches the registry. Passing images are signed with cosign and pushed. In the cluster, a policy controller admits only cosign-verified images, so even a manually pushed unscanned image cannot be deployed. A dated ignore file documents accepted exceptions for review.