Prioritizing a Critical CVE When the Vulnerable Service Is Not Exposed

Treat the Falco alert as an active security incident, not a scanner finding. A cryptominer executing in an approved-image pod means runtime compromise, possibly through a writable volume, a vulnerable application, or excessive capabilities. The matching image digest does not clear the pod because the image could be unchanged while the runtime is compromised. Start by isolating the pod with a deny-all egress NetworkPolicy, cordoning the node if you suspect node compromise, and preserving pod logs, process listings, and network connection data. Do not delete the pod before capturing evidence.

Review Kubernetes audit logs for who created the pod, what service account it used, and whether secrets or tokens were accessed. Check for lateral movement, persistence through CronJobs or DaemonSets, and abuse of CAP_NET_RAW. Rotate credentials available to that workload and scan the node for host-level compromise. Only after containment should you return to the CVE backlog. Record the incident timeline separately from vulnerability management so that the audit trail distinguishes an active compromise from a known unpatched package.

Do not rank by CVSS alone. Use an SBOM to confirm whether the vulnerable OpenSSL package is actually present and loaded by the running process; a statically linked Go binary may not use the image's OpenSSL at all. For each affected image and node, score exposure, exploitability, and business impact. Internet-facing services behind the reverse proxy are highest priority, followed by internal services that accept untrusted input or have broad lateral access. Use EPSS or vendor exploit intelligence to distinguish a theoretical critical from an actively exploited one.

PCI DSS still requires timely patching for in-scope systems, so 'not internet-facing' is a risk modifier, not an automatic exemption. Rebuild container images from updated base images and redeploy; patch or livepatch nodes in maintenance windows. Where patching must wait, apply compensating controls such as restricting network access, adding WAF rules, disabling the vulnerable feature, or isolating the workload. Track each Critical with an owner, decision, and expiry so the audit can see a reasoned risk decision rather than an ignored scan result.

A defensible exception has a named risk owner, a specific affected asset list, the technical reason patching is delayed, the compensating controls in place, a residual-risk statement, an approval from the accountable security or compliance authority, and a hard expiry date. It should reference the vulnerability identifier, the scanner evidence, and the validation that the control actually works. For example, an internal OpenSSL finding might be excepted for 14 days with network isolation, WAF coverage, and daily exploit monitoring, but not with a vague statement that the service is internal.

Operationally, put exceptions in a risk register and review them at the patch window. Re-scan after the compensating control is applied and again before expiry. If the expiry passes without a patch, the exception should escalate rather than silently renew. Keep the Falco incident and the CVE exception in separate records, because mixing an active compromise with a patch deferral obscures both. At audit, show the decision history, the control evidence, and the remediation date.