Container images are a maintenance surface
Teams tend to write a Dockerfile once and treat it as finished. The image it produces, however, keeps aging after the last commit, and the vulnerability count grows without anyone changing a line of code.
The cheapest intervention is reducing what is in the image at all. A large share of reported findings in the images I have remediated came from packages the running application never touched: build toolchains, editors, package managers left in the runtime layer. Multi-stage builds and a deliberately small runtime remove those findings permanently rather than patching them.
The second is ownership with a date. Every image should have someone responsible for it and a known rebuild cadence. Rebuilding on a schedule picks up upstream fixes as a matter of routine, which is far less disruptive than a remediation project once the count reaches the hundreds.
The third is a gate rather than a report. Scanning that produces a dashboard nobody blocks on will document the drift precisely while doing nothing to stop it.
Reduce the surface before you patch it. Most of a vulnerability count is often software the application never runs.
Remediating a set of images from several hundred known vulnerabilities to zero is achievable without touching application behaviour — but keeping them there is a process question, not an engineering one.