Uncover the CVE shocking truth – image vulnerabilities exposed and prioritized

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.