Low and medium CVSS findings can still matter because attackers often target the issues defenders delay. In container environments, a vulnerability that is reachable in the running workload can become an entry point even if its score looks modest. The real question is exposure and exploitability in context, not whether the CVSS number appears alarming on its own.
Why CVSS Understates Risk in Container Scanning
CVSS is useful for triage, but it is not a complete measure of operational exposure. In Kubernetes, a low or medium score can still become meaningful if the vulnerable code is reachable in a running pod, exposed through an API path, or paired with weak image hygiene such as embedded secrets or stale dependencies. The risk comes from exploitability in context, not the label.
That matters because image scanning often creates a false sense of distance from the workload itself. A finding can look minor when viewed as a static package issue, yet become part of an attack path once the image is deployed, networked, and granted service access inside the cluster.
One practical reason is that attackers do not need the highest-scoring issue to get traction. They often prefer weaknesses defenders defer, especially when those weaknesses are widespread, reachable, and easy to chain with misconfiguration or credential exposure. In a container platform, even a modest vulnerability can support initial foothold, lateral movement, or secret discovery if it sits in the right place.
A useful reference point is NIST SP 800-190 Container Security, which treats image, registry, orchestrator, and runtime risk as a connected problem rather than a scan-result problem. For scoring context, the NIST National Vulnerability Database and FIRST CVSS are helpful, but they need to be interpreted alongside runtime exposure and workload reachability.
What Makes a “Low” Finding Operationally Dangerous
The main issue is not the score, it is the path from package weakness to workload compromise. A medium-severity flaw in a component that processes untrusted input, handles authentication, or sits on a privileged execution path can matter more than a higher-scoring issue buried in dead code or an unused binary.
In Kubernetes, several conditions amplify this effect: the image may be deployed many times, the same vulnerable layer may exist across multiple services, and the pod may run with permissions that make compromise valuable. If the container can reach cloud metadata, internal APIs, mounted volumes, or secrets, then the practical blast radius grows well beyond the CVSS label.
Image scanning also misses the context that determines whether the finding is reachable. A scanner can identify a CVE, but it cannot by itself tell you whether the affected function is called in production, whether the container is isolated, or whether compensating controls already narrow the exploit path. That is why container security guidance and vulnerability records are necessary, but not sufficient, for decision-making.
One useful internal read on this problem is Ultimate Guide to NHIs, which highlights how overprivilege, stale credentials, and poor visibility turn otherwise ordinary exposures into broader compromise. For image-specific evidence, see Massive Docker Hub Secrets Leak and Docker Hub Auth Secrets in Container Images, both of which show how image content can turn a normal scan finding into real exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 — Data-at-rest protection | Container images and mounted data can expose sensitive material if a flaw is reachable. |
| PR.AC-4 — Access permissions and least privilege | Reachable vulnerabilities matter more when the pod has broad access inside the cluster. | |
| Recommendation — Protect sensitive data in workloads with layered controls and minimize exposed content. Restrict workload access so compromise of one container cannot open broad internal paths. | ||
| CIS Controls v8 | 5.2 — Establish and Maintain a Secure Configuration Process | Image scanning must be tied to secure baselines and deployment context, not only CVSS. |
| Recommendation — Baseline container image and deployment settings so scanner findings are assessed against known-safe builds. | ||
| MITRE ATT&CK | T1611 — Escape to Host | Container weaknesses become more serious when they can support breakout or broader compromise. |
| T1552 — Unsecured Credentials | Images may contain secrets, turning a modest flaw into credential exposure. | |
| Recommendation — Hunt for container exploitation paths that could enable host-level compromise or lateral movement. Search images and runtime artifacts for exposed credentials that can be abused after exploitation. | ||
Practitioner Guidance
What to verify: Treat severity as a starting point, then verify whether the vulnerable code is actually present in the running image, whether the affected path is reachable, and whether the container has access to sensitive data or internal services. If the answer is yes to any of those, raise the finding ahead of “higher” scores that are not reachable.
Decision rule: Prioritise reachable vulnerabilities in deployed images over abstract high-severity findings in unused components. A low or medium CVSS item that sits inside an exposed workload is a live risk candidate, especially when the same image is reused broadly across namespaces or environments.
What good looks like: Scanning output should be joined to runtime context, ownership, and deployment scope, so teams can distinguish cosmetic defects from issues that can become an entry point. The goal is not to chase every score equally, but to reduce the set of vulnerabilities that are both exploitable and operationally placed to matter.
Practitioner takeaway: In Kubernetes, the useful question is not “How severe is the CVE?” but “Can this flaw be reached, chained, or abused in the running workload?” When that answer is yes, low and medium findings deserve real prioritisation.
Related resources from NHI Mgmt Group
- Why do low severity vulnerabilities sometimes create high severity risk in real environments?
- Why do encoded Kubernetes secrets still create real compromise risk in public repositories?
- Why do Kubernetes secrets still create risk after teams move to Vault or Key Vault?
- Why do low-privilege credentials still create serious lateral movement risk in Windows domains?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
