I maintain the container images for our services, and vulnerability scanning produces hundreds of high and critical findings every week. Most are inherited from base-image packages, and many come from build-stage dependencies that never make it into the runtime image. In one case, I nearly deprioritized a critical vulnerability in a library used by a public API because it was buried among findings in a build tool that was not shipped. A penetration test later showed that the API vulnerability deserved immediate attention. What risk factors, tooling, or workflow are you using to rank findings so exploitable issues in exposed services rise above irrelevant or unreachable vulnerabilities?
5 Answers
Use exploitability data such as EPSS alongside severity and exposure. Sorting by likely exploitation can move a moderately scored but reachable vulnerability above a high-severity issue that is not exploitable in your deployment. For findings you have validated as unreachable or otherwise not applicable, record the relevant VEX status so they stop returning as fresh incidents on every scan.
Reduce the noise before you start triaging. Use multi-stage builds so compilers and build tools never enter the runtime image, keep the runtime base as small as practical, and standardize the images your teams use. Good Dockerfile hygiene and a useful .dockerignore also prevent accidental content from being shipped. Dependency update automation can handle many low-risk upgrades, provided the CI tests are strong enough to catch regressions.
Put compensating controls around issues that cannot be patched immediately: restrict network access, enforce least privilege, prevent unnecessary outbound connections, and make sure the vulnerable component cannot be reached by untrusted input. A vulnerability-management system can track exceptions and remediation owners, but the important part is having an explicit expiration date and reviewing the exception when the image or threat changes.
A leaner or security-focused base image can reduce the number of findings, but switching distributions is not a substitute for prioritization. Treat the base image as a maintained product: pin it, rebuild regularly, scan the final artifact, and verify that updates pass tests. The main goal is to remove packages you do not need and focus attention on code that is actually shipped and reachable.
Prioritize in layers rather than relying on the CVSS score alone: first consider severity, then the importance of the affected asset, and finally whether the vulnerable code is reachable from an attacker-controlled path. An internet-facing service using the vulnerable library should come before a critical package that is present only in an unused build stage. Mapping findings to the owning team and giving each team a manageable dashboard also helps keep issues from sitting unassigned.
We already have severity and asset criticality, but reachability still requires a manual check. The team-owner mapping seems especially useful because unassigned findings tend to disappear into the queue.