When we run applications in Kubernetes, we use containers. Containers are built from images. But not all images are safe. Some may have known flaws that attackers can use to break in. For example, a vulnerability in our image might let an attacker take control our K8s cluster or read secret data.
So how do we know if our images or containers are affected by any vulnerability ? We scan them. In this post, we will review the Common Vulnerabilities and Exposures and how we can use this database for our images and containers scans. We will also have a look at some best practices when it comes to scanning images in our clusters.
Common Vulnerabilities and Exposures (CVE)
Before we scan container images, we must understand Common Vulnerabilities and Exposures (CVE). When attackers find a new flaw in software, they can use it to break into systems or cause damage. But if we find it first, we can share it with the community. To do that, we need a shared space where these flaws are tracked.That’s what the CVE database is—a public list of known vulnerabilities. Common Vulnerabilities and Exposures (CVE) is a publicly accessible dictionary of common names for publicly known information security vulnerabilities, helping organizations share information, prioritize fixes, and protect their systems. Each CVE has a unique ID, which avoids duplicates and makes it easy to look up details fast.
What kind of problems/issues are considered CVEs and can be part of the CVE database? It’s normally one of two things:
- Something that lets an attacker bypass security and do things they shouldn’t
- Something that lets an attacker damage systems, slow them down, or stop services
Using the CVE in our scans
In a previous post, we talked about keeping our base images small and removing extra software. But for the images we already use—and the containers running in our Kubernetes clusters—how do we know if they’re secure?This is where CVE scanners help.
CVE scanners check for known vulnerabilities inside running containers. They inspect the applications inside those containers. For example, if a container runs an app on Node.js, the scanner detects the version and checks for any known flaws linked to it.
This is powerful. Once we see the list of vulnerabilities in our environment, we can then take some decisions to protect our containers and images:
- Upgrade to a safer version
- Add security controls to reduce the risk
- Remove vulnerable packages that aren’t needed
- Trivy: Easy to use. Fast. Can scan images and running containers.
- Grype: Open-source. Focused on finding vulnerabilities in images.
- Anchore: Provides reports. Can run in CI/CD pipelines.
- Clair: Works well with Kubernetes. Integrates with registries.
Best Practices for Scanning Container Images
To keep our Kubernetes clusters secure, scanning container images isn’t enough—we need a strategy. These best practices help us scan effectively, catch threats early, and reduce risk at every stage.- Rescan Images Regularly
A clean scan today doesn’t guarantee safety tomorrow. New vulnerabilities are discovered all the time. We must scan images on a regular basis to catch new CVEs. - Use Admission Controllers in Kubernetes
We can trigger scans at deployment time using admission controllers. These controllers check each new pod before it runs. This adds a layer of protection in real time. - Maintain a Registry of Pre-Scanned Images
Scanning at deployment time with admission controllers may slow things down. One solution is to keep a registry of pre-scanned, approved images. These images are ready to use. But we must keep this registry up to date by rescanning them on a regular basis. - Scan in the CI/CD Pipeline
We can scan earlier—during development. By adding scanners to our CI/CD pipelines, we catch vulnerabilities as soon as a new image is built. This reduces risk before anything reaches production.