Uncover the CVE shocking truth – image vulnerabilities exposed and prioritized
Jul 6, 2023
Scanning containers’ images is not enough, pinpointing the CVEs that impact your security posture is key.
Public images are a key component of the cloud-native ecosystem. Also known as container images, they are pre-built and publicly available software packages that contain all the necessary dependencies and configurations for an application to run in a containerized environment. They allow developers to quickly and easily deploy applications without having to worry about building and maintaining their own images.
Unfortunately, they typically come with many vulnerabilities. When you incorporate these images, your system becomes susceptible to these vulnerabilities. While top vulnerability scanners can identify and rate these vulnerabilities based on the CVSS (Common Vulnerability Scoring System) score, it’s important to note that this alone does not drive a solution. In fact, the scan result is often a very long list of vulnerabilities and their scores, with no further insights. This can lead to a phenomenon known as “CVE Shock.”
In this blog post we will introduce the concept of relevancy of vulnerabilities to a specific Kubernetes infrastructure. We will show how pinpointing relevant vulnerabilities cuts the number of CVEs that need to be addressed by over 60%.
About the research
ARMO security researchers took ten of the most popular container images and analyzed the results of a regular vulnerability scan vs. one that filters for relevant ones.
The images selected:
Redis | redis:7.0.11-alpine |
Nginx | nginx:1.14.2 |
Elasticsearch | elasticsearch:8.5.1 |
Kafka | wurstmeister/kafka:2.12-2.3.0 |
Zookeeper | zookeeper:3.7.0-debian-10-r70 |
Mysql | mysql:5.7.25 |
Postgres | postgres:9.6.18 |
MongoDB | mongo:4 |
Grafana | grafana:9.5.3 |
ArgoCD | argocd:v2.7.4 |
Environment details: We ran Kubernetes 1.27 on Minikube 1.27
Please note that results may vary, depending on the image version, time of scanning and your specific environment.
Research results
Consider Redis. Redis is an open-source, in-memory data structure store used as a database, cache, and message broker. When running the Redis image noted above, ARMO security researchers found the following results:
Critical | High | Medium | Low | Negligible | Total | % Reduction | |
Regular Scan | 3 | 15 | 4 | 9 | 52 | 83 | 83% |
Relevancy Scan | 2 | 2 | 4 | 3 | 3 | 14 |
We can see that running a vulnerability scan on the Redis image yields 83 vulnerabilities. When looking through the lens of relevancy that number shrinks to 14, which represents an 83% reduction.
For those of you that are more visual, you can see the impressive reduction in the following chart:
The implication of this exercise is that users of the Redis image in question, on the environment in question need to fix only 14 CVEs in order to create a real impact on their security posture.
The scan results of the other images that were checked are summarized in the charts below:
Relevant CVEs | CVEs to deal with later |
Only 4.8% relevant CVEs for Nginx | Less than half relevant CVEs for Elasticsearch | Only 6.7% relevant CVEs for Kafka |
Less than 25% relevant CVEs for Zookeeper | Only 1.9% relevant CVEs for MySQL | Only 17.2% relevant CVEs for MongoDB |
Only 13% relevant CVEs for Postgres | Only 19% relevant CVEs for ArgoCD | Nearly 80% relevant CVEs for Grafana |
For those of you that want to dive deeper into the numbers, you can use the source data as represented in the following table:
CVEs | Critical | High | Medium | Low | Negligible | Total | % Reduction | ||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
container images | all | rel | all | rel | all | rel | all | rel | all | rel | all | rel | |
Nginx | 55 | 3 | 102 | 5 | 85 | 6 | 52 | 2 | 102 | 3 | 396 | 19 | 95% |
Elasticsearch | 4 | 4 | 44 | 42 | 115 | 25 | 43 | 30 | 19 | 2 | 225 | 103 | 54% |
Kafka | 23 | 6 | 76 | 27 | 470 | 25 | 485 | 13 | 15 | 1 | 1069 | 72 | 93% |
Zookeeper | 42 | 8 | 122 | 16 | 902 | 202 | 563 | 202 | 121 | 3 | 1750 | 431 | 75% |
Mysql | 27 | 0 | 59 | 2 | 29 | 0 | 55 | 1 | 90 | 2 | 260 | 5 | 98% |
Postgres | 191 | 34 | 424 | 52 | 340 | 34 | 85 | 10 | 151 | 25 | 1191 | 155 | 87% |
MongoDB | 0 | 0 | 1 | 1 | 3 | 2 | 22 | 2 | 3 | 0 | 29 | 5 | 83% |
ArgoCD | 3 | 2 | 8 | 4 | 16 | 5 | 26 | 0 | 5 | 0 | 58 | 11 | 81% |
Grafana | 3 | 3 | 11 | 5 | 22 | 20 | 2 | 2 | 0 | 0 | 38 | 30 | 21% |
It is important to note the significant number of vulnerabilities that are classified as medium or low based on their CVSS score. Malicious actors are well aware of the common practice among Kubernetes infrastructure security teams to prioritize patching or mitigating vulnerabilities with the highest CVSS score. As a result, lower-scoring but still relevant vulnerabilities can often remain unaddressed for extended periods, ranging from weeks to even months. These overlooked vulnerabilities can serve as potential entry points for attack vectors, posing a significant risk to the overall security of the system.
Conclusion
ARMO’s research on public images proves without a doubt that using them is not risk-free. They introduce vulnerabilities into the software that uses them. That being said, some of the vulnerabilities introduced are not relevant and fixing them can be deprioritized. Thus, avoiding debilitating teams with “CVE Shock”.
To learn more about how to approach this and how ARMO implemented relevancy whilst leveraging eBPF you can read more on this blog post. For implementation and full technical coverage please visit our documentation hub.
If you’d like to try out Relevancy yourself, it is now generally available to all ARMO Platform users. Not an ARMO Platform user yet? Sign-up, it’s free.
Unifying AppSec, CloudSec and DevSec
The only runtime-driven, open-source first, cloud security platform:
Continuously minimizes cloud attack surface
Secures your registries, clusters and images
Protects your on-prem and cloud workloads