Open-source vulnerability scanners for Kubernetes: what each one does and does not do

Free tools will tell you exactly which CVEs are in the images running in your cluster. They will not tell you what changed since last week, which of six clusters is worst, or that an advisory published overnight hits an image you scanned yesterday. This post covers the open-source scanners that understand Kubernetes, not just images, and gives equal weight to what each one does and what it leaves for you to build. Our own CLI is in here too, with the same treatment. Project status was checked against each project's releases in September 2026.

The short version:

• One or two clusters, "what is vulnerable right now": Trivy Operator.
• Posture and compliance first, CVEs second: Kubescape.
• You intend to build the continuous pipeline yourself: Syft and Grype, plus Dependency-Track as the store.
• A one-off answer from your laptop: the StackRadar CLI or trivy k8s.
• Still running KubeClarity: plan the move; it and its successor are both unmaintained.

What the open-source tools cover, and the gap they share

Every tool below answers the same question well: for one cluster, at one moment, which images contain which CVEs. Several also generate SBOMs and audit configuration. None of them does the operational part out of the box:

• History. Keeping yesterday's answer so you can see what was fixed, what is new, and how long a finding has been open.
• Continuous re-matching. Noticing that a CVE published overnight applies to an image you already scanned, without waiting for the next rescan.
• Fleet view. Six clusters in one list, with each finding attributed to the workloads that run it.
• Ranking by exploitation over time. Grype now ranks by EPSS and KEV within a scan; keeping that ranking current as the feeds change daily is still yours to do.

These are what turn a scanner into a vulnerability programme, and they are where the hosted products, ours included, earn their money. Decide early whether you will build them yourself, because it changes which scanner you should pick.

Trivy Operator: the most complete in-cluster scanner

Trivy Operator (Aqua Security, Apache-2.0, releasing regularly) watches workloads, scans each with Trivy as it appears, and writes the results as custom resources:

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aqua/trivy-operator -n trivy-system --create-namespace

kubectl get vulnerabilityreports -A
kubectl get sbomreports -A
kubectl get configauditreports -A

• Does: vulnerabilities, SBOMs, config audit, exposed secrets, RBAC assessment and compliance reports (CIS, NSA, Pod Security Standards), all as CRDs, plus Prometheus metrics. Nothing leaves the cluster.
• Does not: keep history (reports carry a 24-hour TTL by default and are regenerated by rescanning), aggregate across clusters, or rank beyond severity. It learns about a new advisory on the next rescan, not when the advisory is published.
• Build yourself: a Grafana dashboard from the metrics (quick), and a CRD-to-database exporter for history and a fleet view (not quick).

If you run one or two clusters and want "what is vulnerable right now", stop here. We say the same on its comparison page and in the long-form post.

Kubescape: posture first, with runtime context

Kubescape (started by ARMO, Apache-2.0, a CNCF incubating project since January 2025) began as a posture scanner against the NSA/CISA hardening guidance. It has since added image vulnerability scanning (Grype is the engine), SBOM generation, and a runtime "relevancy" filter that marks which vulnerable packages the running container actually loads. That filter is genuinely distinctive: it cuts the CVE list down to what the process touches. Version 4.0, released in March 2026, made runtime threat detection generally available.

• Does: misconfiguration scanning against several frameworks, RBAC visualisation, image CVEs, the relevancy filter, runtime threat detection, an in-cluster operator whose results you read with kubectl, and a CLI for CI.
• Does not: keep history or a fleet view without ARMO's hosted platform, which is the commercial product.

Choose it when posture is the bigger problem and vulnerabilities come second. Details are in the head-to-head.

Grype and Syft: the parts for building it yourself

Syft generates the SBOM; Grype matches it. Both are Anchore, Apache-2.0, and release every few weeks. Neither knows what Kubernetes is, and that is exactly why they are on this list: the pair is the right foundation if you intend to build the continuous part yourself. Generate one SBOM per running digest, store it, and run Grype against the stored SBOMs whenever its database updates.

# for each running digest:
syft registry.example.com/shop/checkout@sha256:9f2c… -o cyclonedx-json > sboms/9f2c.cdx.json
# nightly, against everything stored:
grype sbom:sboms/9f2c.cdx.json -o json

• Does: thorough SBOM generation and a solid matcher that, by default, sorts findings by a risk score built from EPSS, KEV and CVSS. Scanning a stored SBOM is fast because no image is pulled.
• Does not: discover images, attribute findings to workloads, store anything, or schedule anything. Those are the neutral boxes in the diagram.

This is, at its core, also the StackRadar architecture: Syft is bundled in the in-cluster scanner, and the server keeps the SBOMs and re-matches them against OSV, EPSS and KEV as they update. If you build it yourself, those neutral boxes are the work.

Trivy CLI (trivy k8s): the operator without persistence

The Trivy binary can scan a whole cluster from your kubeconfig and summarise vulnerabilities and misconfigurations across namespaces:

trivy k8s --report summary

It is the laptop version of the operator: same scanner, no persistence. Good for an audit; not a replacement for the operator, because it only knows what was running when you ran it.

OSV-Scanner: the most precise matcher for language packages

OSV-Scanner (Google, Apache-2.0) matches against OSV.dev, the aggregated open vulnerability database. It scans lockfiles, SBOMs and directories, and container images through the scan image command added in v2 (2025). It is the most precise matcher for language ecosystems, because OSV records exact affected ranges rather than inferring them. It is narrower on OS packages, since not every distribution publishes to OSV. It has no Kubernetes mode; its role here is as the engine inside the next tool.

StackRadar CLI: one command, "are we running anything exploited?"

stackradar scan (Apache-2.0) reads the image digests the kubelets report through your kubeconfig, scans each distinct one with the osv-scanner library, attributes findings to namespaces and pods, and flags CISA KEV entries. Output is a table, JSON or a self-contained HTML report. There is no account and no telemetry, and nothing is sent to StackRadar.

brew install lockdep/tap/stackradar
stackradar scan                   # every running image in the current context
stackradar scan --fail-on kev     # exit 2 if an exploited CVE is running

• Does: the fastest honest answer to "are we running anything exploited?" on a cluster you can reach.
• Does not: persist, watch or rank by EPSS. It inherits osv-scanner's distro-coverage limits, and it pulls images with your local registry credentials. With --use-pull-secrets it uses the cluster's own pull secrets instead; if it still cannot pull an image, it says so rather than guessing.

Other install options and signature verification are on the CLI page; the background is in the launch post.

KubeClarity: archived, and so is its successor

KubeClarity was, for a while, the closest open-source thing to a hosted platform: SBOM generation, multi-scanner vulnerability detection and a dashboard, all in-cluster. Its history is a warning about building on a single-vendor project:

• October 2024: deprecated and archived in favour of OpenClarity, which merged it with VMClarity. Old data could not be migrated; moving meant a fresh install.
• May 2026: OpenClarity was archived too, and the whole OpenClarity GitHub organisation is now marked as no longer maintained.

If you still run either, it gets no dependency or security fixes, and pointing an unmaintained tool at your cluster is a finding in itself. Trivy Operator is the closest maintained replacement for the in-cluster part. More alternatives are listed here.

Adjacent tools people ask about

• kube-bench (Aqua) checks nodes against the CIS Kubernetes benchmark and is still maintained. kube-hunter probed for cluster weaknesses but is no longer under active development; Aqua points to Trivy instead. Neither scans images.
• Falco and Tetragon are runtime detection, not vulnerability scanning.
• Dependency-Track (OWASP) is an SBOM store that re-matches uploaded SBOMs continuously. It is the open-source building block for the "keep the SBOM" architecture: pair it with Syft and a small script that uploads one SBOM per running digest. We compare against it directly.

The wider map, from admission policy to network, is in Kubernetes security tools, by what they do; CI and registry scanners are covered in container vulnerability scanning tools.

Side by side

Frequently asked questions