Our container images are scanned on every build, and the results often contain hundreds of high and critical findings, many of them inherited from base-image packages. In the last review, about half the critical findings came from dependencies used only during the build and never included in the runtime image. Meanwhile, a critical vulnerability in a library used by an internet-facing API was buried among the less relevant findings and was only caught later during a penetration test. What risk-based process are you using to rank findings and focus remediation on vulnerabilities that are actually exploitable and important?
4 Answers
Reduce the noise before triage. Use multi-stage builds so compiler and build-tool dependencies never enter the runtime image, and choose smaller or minimal base images where they are practical. Standardize a small set of approved base images, keep them updated, and use dependency update automation in CI. You cannot eliminate every finding, but you can avoid shipping a large collection of packages the service never needs.
A practical model is to score findings across several dimensions: severity, internet exposure, asset importance, runtime reachability, exploit availability, and whether the vulnerable code is loaded. Put the highest combined-risk items into a short remediation queue and let service teams own the fixes. A security champion or designated contact for each team, backed by a dashboard and regular review of blockers, helps keep the queue moving without making security a purely central-team exercise.
Start with exposure and reachability, not just the CVSS number. A vulnerable library loaded by an internet-facing service should outrank a critical package that exists only in a build stage or is never reachable at runtime. Add asset criticality, whether the vulnerable code is actually present and loaded, exploit availability, and an EPSS-style likelihood score. Then assign each finding to the owning service team so it does not sit in an unowned queue.
That matches what we are missing. We have CVSS and asset criticality, but still manually check whether the vulnerable component is reachable. Automating ownership and reachability would remove a lot of noise.
Use an exploitability signal such as EPSS as another sorting field, and set a policy for low-probability findings instead of treating every alert equally. For vulnerabilities that are present but not exploitable in your deployment, record a VEX statement or equivalent justification so they stop returning as brand-new urgent work. Exceptions should have an owner, rationale, and review date rather than being silently dismissed.
The team-owner model sounds useful. Right now findings often arrive without a clear owner, so they just accumulate. Mapping images and deployments to teams is probably one of the highest-value improvements we can make.