ARMO named in Gartner® Cool Vendors™ report
We are excited and honored to announce that we were selected as Gartner Cool Vendor...
Jan 4, 2024
This is not a beginner’s blog post. As such, we will not tell you about the importance of securing your Kubernetes infrastructure (it’s important). However, if you are here to learn about increasing the efficiency of your security work and the blind spots you may have, you have come to the right place.
You may have heard of and are already using CVSS as your gold standard for vulnerability prioritization. This is probably the result of how open-source and commercial scanners provide results to you. However, 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. The following graphic tells this story well.
In this post, we will talk about two additional scoring systems: EPSS and KEV. Together with CVSS, these systems are all available and complement each other. Every scoring system has limitations. Looking at all of them together gives a more complete and less noisy result from scanners.
We will conclude the post by analyzing real data from ARMO customers. We will show that layering different scoring systems and adding runtime context, optimizes the scanner signal to noise ratio. This will ensure that the security work you do actually makes a difference in your security posture, while avoiding false positives (noise) and preventing alert fatigue (or CVE Shock).
CVSS is a commonly used vulnerability metric. It helps convey the severity of vulnerabilities. CVSS allows organizations to assess vulnerabilities in a standardized way. This helps them compare and prioritize vulnerabilities based on severity scores.
Limitations and blind spots
EPSS is a data-driven, community-led initiative. It estimates the probability of a software vulnerability being exploited in the wild. EPSS gives each vulnerability a probability score from 0 to 1 (or 0-100%) to show how likely it is to be exploited in the next 30 days. This system helps security practitioners prioritize fixing vulnerabilities.
Limitations and blind spots
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. This helps all organizations in effectively handling vulnerabilities and staying updated on threat activity. 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.
Limitations and blind spots
As you can see, every metric has its strengths and its blind spots. As a result, no metric can be the single one to rule them all.
By applying all of these metrics, you can reduce the number of vulnerabilities you must fix immediately by up to 95%
But enough with the background and academic conclusions. Let’s look at the results of the ARMO research team when studying the volume of vulnerabilities for a select subset of customers.
To show how these vulnerability metrics can perform in practice, let’s look at real-world examples. The data set is based on anonymized production data of ARMO customers gathered in the last 12 months. This allowed our researchers to use both a large and a current data set. Additional assumptions used here:
P0 – anything that can be found in the KEV database.
P1 – anything with a combined score of EPSS >=0.1 & CVSS >= 7.0
These are the fires that security practitioners need to run to. The rest of the vulnerabilities can be classified as fires they can walk to.
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.
The analysis included testing the total vulnerabilities against KEV to identify P0 vulnerabilities. P1 vulnerabilities were identified by crossing those with an EPSS score of 0.1 or larger and a CVSS score of 7.0 or larger (i.e. Critical and High).
When visualizing these vulnerabilities the number of P0 and P1 vulnerabilities (signal) is minuscule in relation to the total number of vulnerabilities (noise). With a signal to noise ratio of between 0.16% and 1.86%.
You can also clearly see the disparity between KEV and the EPSS/CVSS combo. This gives us an idea of the (in)completeness of the KEV database at the time of writing.
Having said that, everything discussed to this point lacks a critical component and that is context. Specifically runtime context. The point is that the prioritization of security work that security practitioners need to decide on is heavily dependent on what’s really happening in their unique environment. If a vulnerable package is not used in runtime, or in a production environment, this could also have an impact on the priority of fixing it.
At ARMO we strive to give you all of this in a single place. Users of ARMO Platform can get the results of naive scanning (i.e. all scan results, which as we see above, are in the thousands). They can then filter for criticality, reachability and access to the internet. ARMO Platform’s roadmap involves integrating EPSS and KEV to provide users with a clear indication of the most critical vulnerabilities. This enables users to swiftly address these issues, saving time that would otherwise be spent researching and prioritizing vulnerabilities.
Additional context can come from crossing vulnerabilities and configuration. For example, 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 (CVE-2023-22809) present on the machine, allowing him to escalate his privileges to root.
That’s a critical exploitable vulnerability! We must run to fix it!
However, let’s say you could cross-reference the vulnerability with configuration. In this example the configuration only allows the container to run as NonRoot and bars privilege escalation. As you can see in the YAML below:
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. By considering factors such as exploitability, prevalence, severity, scope, and impact, organizations can effectively prioritize their remediation efforts and safeguard their systems against evolving threats. However, since today, no single metric is comprehensive enough to cover everything, it is necessary to consider vulnerabilities based on multiple frameworks.
In addition, ALL security metrics lack the context of your Kubernetes infrastructure and runtime information of your application. These are crucial to whittling down the number of vulnerabilities and getting to the positives that should really concern you.
If you would like to increase the efficiency and speed of your vulnerability scanning, try ARMO Platform today.
From code to cluster, helm to node, we’ve got your Kubernetes covered:
Cut the CVE noise by significantly reducing CVE-related work by over 90%
Automatic Kubernetes compliance for CIS, NSA, Mitre, SOC2, PCI, and more
Manage Kubernetes role-based-access control (RBAC) visually
We are excited and honored to announce that we were selected as Gartner Cool Vendor...
Transparency in vulnerability disclosure plays a crucial role in effective risk management, regardless of software...
Learn about Kubernetes compliance challenges, consequences of non-compliance, and get guidance on maintaining a secure...