As you read this, I'd like you to keep in mind that CVSS was never intended to be that end-all software vulnerability scoring system.
Doesn't reflect actual risk - CVSS provides a base score that represents the inherent severity of a vulnerability in isolation.
A vulnerability with a high CVSS score might not pose a significant risk to your organization if it doesn't affect any critical systems or data.
Ignores temporal factors - The base score assumes the vulnerability is actively exploited, which may not be the case.
Lacks context specificity - CVSS doesn't consider the specific assets and systems affected by a vulnerability.
A vulnerability affecting a critical system has a much higher impact than one affecting a non-essential service.
CVSS depends on accurate and timely vulnerability data, which can be a challenge to maintain.
EPSS gives each vulnerability a probability score from 0 to 1 to show how likely it is to be exploited in the next 30 days.
Overreliance on Exploitability - EPSS places a lot of importance on how likely a vulnerability is to be exploited.
Limited Attack Surface Focus: EPSS primarily focuses on vulnerabilities exploitable directly through the Kubernetes attack surface.
KEV. KEV is a vulnerability catalog created by CISA. It provides the cybersecurity community with an authoritative source of vulnerabilities that have been exploited in the wild.
The public database serves as an indicator, signaling whether a vulnerability is currently being exploited in real-world scenarios.
The KEV catalog should be used as an input to their vulnerability management prioritization framework.
To show how these vulnerability metrics can perform in practice, let's look at real-world examples.
In the chart below you can see the breakdown of P0 and P1 vulnerabilities of different ARMO customers in relation to the total number of vulnerabilities identified by the Kubescape Vulnerability scanner.
Let's consider a scenario where an attacker gained code execution on the container from a web vulnerability and now he is running as the www-data user, which is a common user used in web servers, now, the attack wants to elevate his privileges to root and he spots the sudoedit binary in a vulnerable version present on the machine, allowing him to escalate his privileges to root.
Let's say you could cross-reference the vulnerability with configuration.
ApiVersion: v1 kind: Pod metadata: name: my-pod spec: securityContext: runAsNonRoot: true allowPrivilegeEscalation: false containers: - name: my-container image: my-image securityContext: runAsUser: 1000 # Specify a non-root user ID. In this case, the configuration has mitigated the vulnerability and in this specific case, there is no need to patch the vulnerability immediately.
Vulnerability metrics play a crucial role in assessing and prioritizing security risks in Kubernetes and cloud-native environments.
If you would like to increase the efficiency and speed of your vulnerability scanning, try ARMO Platform today.
This Cyber News was published on securityboulevard.com. Publication date: Thu, 04 Jan 2024 11:43:06 +0000