TL;DR: Neither extreme survives. Block unacceptable exploitable risk, with fixability guiding remediation and reviewed exceptions. Triage existing deployed risk as well as new builds, rescan running workloads continuously, and manage false positives through time-boxed waivers tied to specific CVE and digest pairs, never blanket ignores.
How to approach it
Reject the binary framing explicitly, then present policy as a matrix over severity, fixability and image age. False-positive handling deserves as much air as severity thresholds, because it is what determines whether the gate survives its second week: a gate that blocks builds for findings nobody can act on gets disabled, and a disabled gate scans nothing.
A strong answer
Both extremes fail predictably. Warn-only turns scanner output into wallpaper: hundreds of findings, nobody reads past page one, criticals ship on Friday afternoon. Immediate hard blocking on an estate carrying existing debt blocks every deploy, engineering pressure kills the gate within weeks, and the organisation learns to route around security tooling generally. Both failure modes need explicit ownership and measurable gate outcomes.
The policy I would use: scan at three points. CI scans every build with Trivy or Grype, the registry rescans on push, and images already running get periodic rescan, because a CVE published after deployment is invisible to build-time scanning. Enforcement then differs by situation. This is an example policy, not a universal SLA; known exploitation, exposure and business impact can require immediate containment regardless of nominal severity. Use CISA KEV and EPSS alongside reachability evidence. CISA KEV.
| Finding | New build | Already deployed |
|---|---|---|
| Critical, fix available | block | emergency rebuild, SLA in days |
| Critical, no fix available | block, waiver path | assess exploitability, mitigate |
| High | block after grace period | scheduled remediation |
| Medium and below | report | track |
False positives decide whether this programme lives or dies, and the discipline is specific. Suppressions attach to one CVE identifier plus one image digest, never to a rule globally. Each carries a written reason, a named owner and an expiry date, after which the finding reappears. Waivers show up in reports instead of vanishing, so anyone can count active exceptions at audit time. For reasoned "not affected" verdicts, VEX statements are becoming the portable machine-readable way to record why.
Base images deserve disproportionate attention: most findings in a typical application image trace to the base layer. Moving to slim or distroless bases and rebuilding weekly fixes entire fleets of downstream images in one change, which beats triaging the same CVE a hundred separate times.
Measure the programme rather than the scanner: mean time to remediate criticals, share of running images past severity or age thresholds, count of active waivers. Those three numbers tell you whether the gate works or is merely installed.
What interviewers probe next
"A release is blocked by a critical with no fix available. Go." Confirm exploitability first: is the vulnerable code path reachable under our configuration? Mitigate around it, WAF rule, config flag, network restriction, then issue a time-boxed waiver with the right sign-off and a ticket tracking upstream. If mitigation cannot bring risk within the approved threshold, keep the affected release or feature blocked until a safe path exists.
"Who owns findings?" Security owns thresholds and policy, platform owns the plumbing, product teams own remediating their images. Centralising ownership of every finding scales worse than the problem it solves.
"Trivy versus Grype versus vendor scanners?" Coverage and noise differ run to run; pick one as the gate for consistency and optionally cross-check periodically. Brand debates waste the meeting.
Common mistakes
Globally ignoring medium severities, which buries the medium that chains with something else into a real attack path.
Waivers without expiry dates, converting the exception process into a permanent hole with paperwork attached.
Scanning only in CI, so long-lived deployments accumulate newly published CVEs invisibly.