Most "Kubernetes vulnerability scanning" is registry scanning wearing a Kubernetes badge: it scans the images your pipeline built and hopes those are the ones running. StackRadar starts from the other end. A small scanner inside the cluster watches the pods the kubelet is actually running, generates an SBOM for each distinct image, and sends only that dependency list out — never the image, never your code. The matching then happens continuously against a mirror of 900K+ advisories, so a CVE published tonight shows up as a finding on the workloads it affects without anyone triggering a scan.
What "running" means, and why it matters
The unit of a StackRadar scan is an image digest as seen by one cluster — the sha256 the kubelet reports in containerStatuses[].imageID, not the tag in the manifest. That distinction is the whole difference between the two kinds of scanning:
| Registry / CI scanning | Running-cluster scanning | |
|---|---|---|
| Question answered | Is this image clean before it ships? | Which running workloads does this CVE affect? |
| What gets scanned | Whatever was pushed or built | Every digest the kubelet is running, including sidecars, init containers, and images nobody built |
| Knows the namespace, Helm release, ArgoCD app | No | Yes — the scanner reports where each image runs and what deployed it |
| Catches a `:latest` that moved | No | Yes — a new digest is a new image |
| Catches a new CVE in an old image | Only if you rescan | Yes, if the SBOM is re-matched in place |
In practice a cluster runs far more images than anyone built: ingress controllers, cert-manager, monitoring agents, service-mesh sidecars, the CSI drivers, the cloud-provider add-ons. Those are where a large share of real findings live, and a pipeline scanner never sees them.
Continuous in both directions
"Continuous" usually means "we rescan every N hours". That covers new images, but a rescan is also the only way most tools learn about new advisories, so the answer to "are we affected by the CVE that dropped an hour ago?" is "wait for the next cycle". StackRadar separates the two:
- New images are found by a pod informer, so a deploy is scanned within minutes of the pod starting. A full sweep every six hours (configurable) catches anything the informer missed. Each distinct digest is pulled and inventoried once per cluster, however many pods run it.
- New advisories are matched against the SBOMs already stored. The scanner does nothing; the matching runs on the StackRadar side as the mirror of OSV.dev updates. The finding appears with the workloads, namespaces and releases it affects already attached.
The same mechanism updates the ranking. EPSS scores and the CISA KEV catalogue are re-synced daily, and every finding's Radar Score contribution is a generated column over those fields — when a CVE lands in KEV, its position in your list moves the same day.
What leaves the cluster
Exactly two things: the SBOM for each image (package names, versions and licences — no code, no file contents, no secrets) and an inventory of what is running where (namespace and workload names, image references, Helm chart versions, ArgoCD application names, from a short fixed list of well-known labels). The architecture page lists every field. The scanner source is published and every release is signed, so you can check that claim rather than take it.
Ranked by what is being exploited
A cluster of moderate size carries thousands of findings, and roughly 5% of CVEs are ever exploited. Sorting by CVSS puts the loud ones first, not the dangerous ones. Every finding in StackRadar carries its EPSS probability and whether it is in the CISA KEV catalogue, and the Radar Score combines them with CVSS in a published formula — a CVSS 7.5 that is being exploited outranks a CVSS 9.8 that is not. Findings without a severity score are shown as unscored rather than silently binned as "low".
Install with one Helm command
One Helm chart, one API key, read-only RBAC. The scanner works on any conformant cluster — EKS, GKE, AKS, DigitalOcean, k3s, kind, OpenShift, self-managed.
helm install stackradar-scanner oci://ghcr.io/lockdep/charts/stackradar-scannerThe quick-start guide covers creating the key and pinning the chart version; the private registries guide covers ECR, Artifact Registry and ACR credentials, and restricted networks covers filtered egress. Self-hosting is free (AGPL-3.0), and every cloud plan starts with a 14-day free trial — see pricing.
If you want the free in-cluster tool instead
You may not need a server behind the scanner at all. For one or two clusters, no history requirement and no multi-cluster question, Trivy Operator or Kubescape are good free answers, and we say so on their comparison pages. The open-source scanner roundup lays out what each one does and does not do; the head-to-head pages cover the paid platforms.
Frequently asked questions
What is Kubernetes vulnerability scanning?
Kubernetes vulnerability scanning is the process of finding known vulnerabilities (CVEs) in the container images that are actually running in a cluster — as opposed to scanning images in a registry or a CI pipeline, which tells you about images that might run. A Kubernetes scanner discovers the running pods, reads each container image, lists its OS and language packages, and matches those packages against vulnerability databases such as OSV, the distro security trackers and GitHub advisories.
What is the difference between registry scanning and cluster scanning?
Registry and CI scanners look at images at rest and answer "is this image clean before it ships?". Cluster scanning looks at what the kubelet is running and answers "which of our running workloads are affected right now?". Both are useful; only the second can tell you the blast radius of a new CVE, because only it knows which images are deployed, in which namespaces, by which Helm release or ArgoCD application.
What does "continuous" vulnerability scanning mean?
Two different things, and most tools only do the first. Continuously discovering new images — a watcher in the cluster notices a new pod and scans its image — and continuously re-checking already-scanned images as new advisories are published. StackRadar does the second by keeping the SBOM of every image and matching it in place when the vulnerability database changes, so a CVE published tonight is a finding tomorrow morning without any image being pulled or rescanned.
Does the scanner need cluster-admin?
No. The StackRadar scanner needs read-only access: list and watch pods, plus optional read-only lookups of workload controllers (Deployments, StatefulSets, DaemonSets, Jobs) and ArgoCD Applications for attribution. It never creates, modifies or deletes anything, and it reuses the pods’ own imagePullSecrets to read private images.
Is there a free Kubernetes vulnerability scanner?
Yes, several. Trivy Operator and Kubescape are free and open source and run entirely in-cluster. The StackRadar CLI is a free, Apache-2.0 command that scans a cluster from your laptop with no account. StackRadar itself is open source (AGPL-3.0) and free to self-host in your own cluster, one cluster per install; the cloud starts with a 14-day free trial, and its plans add more clusters, longer history and hosted alerts.
How is StackRadar different from Trivy Operator?
Trivy Operator stores scan results as Kubernetes custom resources inside each cluster, with a 24-hour TTL by default, and rescans to refresh them; each cluster is its own silo and there is no history. StackRadar stores the SBOM in its own database rather than in etcd, re-matches it as advisories land, shows every cluster in one dashboard, keeps a dated history, and ranks findings with EPSS and the CISA KEV catalog rather than CVSS alone. Trivy Operator also checks configuration and RBAC, which StackRadar does not.