Most teams we talk to sort the vulnerability backlog by CVSS and start at the top. The score was never designed for that. It describes how bad a vulnerability is if it can be exploited in your environment; it doesn't know your environment.
This week’s article, in three lines
- CVSS should set severity, not the order you fix things in.
- Runtime evidence (was the package loaded, did the vulnerable code run) closes the gap between scanner output and real exploit risk.
- Roll it out incrementally: start with the findings you're about to patch anyway, and check whether they were ever exercised.
One thing to check in your own cluster
Pick one pod with a "critical" finding in a shared library and see whether that library is even mapped into the main process right now:
Shell
kubectl exec <pod> -- sh -c 'cat /proc/1/maps' \
| awk '{print $6}' | grep '\.so' | sort -uIf the vulnerable .so isn't in that list, PID 1 isn't using it at this moment. That isn't proof of safety (other processes, other times, other code paths), but it is a better first question than "what's the CVSS?". Distroless images won't have sh; run the same cat /proc/<pid>/maps from the node instead.
Why CVSS Scores Fail Platform Teams and What Runtime Reachability Fixes