Your container scanner reports 200+ vulnerabilities in a base image you didn't choose and can't easily replace. How do you triage this into something actionable?

Filter aggressively before triaging individually: most reported vulnerabilities are in OS packages that are never actually invoked by your application at runtime, so start by narrowing to vulnerabilities in packages your application actually uses or exposes, then prioritize what's left by real exploitability (is there a known exploit, is the vulnerable code path reachable) rather than the scanner's raw severity label — this typically shrinks 200 "findings" down to a small, genuinely actionable list.

A raw vulnerability count from a base image scan is almost always dominated by noise: OS-level packages included in the base image for completeness that your application never calls, vulnerabilities in code paths that aren't reachable in how you actually use the image, and low-severity findings that don't represent real risk in your specific context. Treating all 200 as equally urgent either paralyzes the team (an impossible remediation backlog) or trains everyone to ignore scan results entirely — neither is the goal.

Filter to what your application actually uses: many base image vulnerabilities are in packages present for general-purpose completeness (documentation tools, unrelated utilities) that your specific application image never invokes — filtering to packages actually exercised by your application's runtime dependencies removes a large fraction of irrelevant findings immediately.

Prioritize remaining findings by real exploitability, not just severity label: a "critical" CVE requiring local access and a specific misconfiguration is a different real-world risk than a "high" CVE remotely exploitable with no authentication — cross-referencing against known-exploited-vulnerability lists (like CISA's KEV catalog) and considering your actual exposure (is this service internet-facing, does it process untrusted input) gives a much more accurate priority order than the raw label.

Distinguish "needs a base image upgrade" from "needs an emergency response": most of what remains after filtering is legitimately addressed by upgrading to a newer base image version on your normal release cadence, not an emergency — reserve urgent, out-of-cycle action for the genuinely exploitable, reachable, high-impact findings.

Consider a minimal or distroless base image as the actual long-term fix: a large fraction of base image vulnerability noise exists because general-purpose base images include far more than any specific application needs — migrating to a minimal or distroless image (containing only your application's actual runtime dependencies) structurally reduces the attack surface and the future noise, rather than repeatedly triaging a bloated base image's vulnerabilities release after release.

• Filter to vulnerabilities in packages your application actually uses before doing anything else — this removes most of the noise in a typical base image scan.
• Prioritize what remains by real exploitability (known-exploited status, reachability, exposure) rather than the scanner's raw severity label.
• Most remaining findings are addressed by a routine base image upgrade, not an emergency response — reserve urgency for genuinely high-risk, reachable findings.
• Migrating to a minimal or distroless base image is the structural long-term fix, reducing future scan noise rather than repeatedly triaging a bloated image.

• CISA: Known Exploited Vulnerabilities Catalog
• Google: Distroless Container Images