Open-source Kubernetes vulnerability scanning you can verify.
StackRadar is an open-source (AGPL-3.0) Kubernetes vulnerability scanner that keeps an SBOM of every running image and rechecks it the moment a new advisory lands. No rescan, no black-box score. Run it in your cluster, or in ours.
14-day free trial · card required · nothing charged until it ends
Dashboard
Live posture across every cluster in this organization.
critical
38
23high
318
84medium
574
37low
211
15New vulnerabilities on running images· last 30 days
| Expand | Image | New findings | Open |
|---|---|---|---|
| jenkins/jenkins:2.555.3-jdk21prod-eu-1 · ci · Just now | +1+5 | See fix | |
| argoproj/argocd:v3.4.3prod-us-1 · argocd · 5h ago | +2+3 | See fix | |
| grafana/grafana:12.3.1prod-eu-1 · monitoring · 1d ago | +1+2 | Open image | |
| dexidp/dex:v2.45.1prod-us-1 · argocd · 2d ago | +1 | See fix | |
| prometheus/prometheus:v3.12.0staging-eu-1 · monitoring · 3d ago | +1+1 | Open image |
Nothing you have to take on trust. Every moving part is a public project you can look up, and every finding links back to its source.
Know what is actually running, not what you pushed.
CI scans the image you built. The cluster runs whatever is left: old tags, hotfixes, the sidecar someone added by hand. StackRadar watches the cluster itself and lists every namespace, workload and container, with the Helm release or Argo app that put it there. Nothing to register, nothing to forget to scan.
How the scanner worksAnswer “are we affected?” before the rescan would have started.
When a CVE makes the news, the question arrives before the fix does, and the usual answer is a full rescan of every cluster. StackRadar already holds the package list for every image, so a new advisory is checked against all of them the moment it lands. You read the answer. Nothing is scanned again.
How matching worksSee only the findings that are yours to fix.
A scanner's list is mostly other people's software: the base image's OS packages, and the Prometheus and Grafana images a Helm chart brought in. Two filters, Organization images and Application findings, cut it to what a dependency bump fixes. The rest is folded, never hidden: it is still counted, and anything being exploited in a base image stays on the list.
How the split is worked outFind every copy of the next Log4Shell in one search.
A headline CVE names a library, and the scramble is finding every image that ships it. Type the package name and see every image and workload running it, across every cluster, with the versions in play and the ones that are already clean.
What an SBOM recordsOne Helm command. Nothing else to wire up.
No CI plugin, no registry credentials to hand over, no rescan schedule to babysit.
- 1
Install once
One Helm command, on EKS, GKE, AKS or anything else that runs Kubernetes — self-hosted, or with the scanner pointed at our cloud. It runs inside your cluster, so there is nothing to grant from outside.
- 2
The inventory writes itself
The scanner finds every container image and writes down what is inside it: package names and versions, nothing else. That list is all that leaves your cluster, and self-hosted it does not even do that.
- 3
The answer is already waiting
Each new advisory is checked against your package lists as it lands. The affected workloads are already listed and ranked, and anything critical or exploited is on its way to Slack or your inbox.
A CVE just dropped. Are we running it?
Three guides that answer it from what the kubelets report, and one command that answers it from your laptop.
Which running images are affected?
A CVE ID lands in Slack. Four steps answer it from what the kubelets report: the running digests, one SBOM each, the ID and its aliases, then the pods.
Which pods run the vulnerable package?
Given a package name, list every pod that runs it with its Deployment or DaemonSet and Helm release: one SBOM per digest, a jq query, and a join on the digest.
Which of the findings matter this week?
Four tiers built from EPSS and the CISA KEV catalogue, with the thresholds behind each. On a real nginx image, 497 CVEs became 12 for this week.
Nothing installed in the cluster yet? The free, Apache-2.0 StackRadar CLI scans every running image through your kubeconfig and puts the CISA KEV entries first. No account, and nothing is sent to StackRadar.
brew install lockdep/tap/stackradar
stackradar scan # every running image in the current kubeconfig context, deduplicated by digestLet us host it, or self-host it.
Same code, same images; the cloud is the parts worth paying someone else to run.
StackRadar Cloud
14-day free trialthen Pro from $59/month
- Every cluster in one dashboard, across clouds and accounts
- Critical & KEV alerts to email and Slack, and a weekly digest
- We run the database, the vulnerability mirror, the upgrades and the backups
Card required at checkout; nothing charged until the trial ends.
StackRadar Open Source
FreeAGPL-3.0, in your own cluster
helm install stackradar \
oci://ghcr.io/lockdep/helm-charts/stackradar \
--namespace stackradar --create-namespace- One cluster: the one it runs in
- Local login or any OpenID Connect provider; alerts to a Slack webhook
- You run Postgres, upgrades and backups; help in GitHub Discussions
Works with what you already run.
Every name is the guide for it.
Fix what attackers actually use first.
Sorted by CVSS, a 9.8 nobody exploits outranks a 5.3 under attack today.
A critical on paper
- Severity
- Critical (9.8)
- Chance of exploit
- Almost none
- Exploited right now
- No
A medium under attack
- Severity
- Medium (5.3)
- Chance of exploit
- Certain
- Exploited right now
- Yes, on the CISA list
Three public inputs, shown next to every score: CVSS for severity, EPSS for the chance of exploitation, and the CISA KEV catalogue for exploitation right now. Your cluster’s Radar Score is the sum, and it falls as you fix.
How the Radar Score worksThe three reasons not to install this, answered.
Already running Trivy Operator?
Keep it if you have one or two clusters and only need to know what is vulnerable today. Add StackRadar when you want every cluster in one place, a dated history you can show an auditor, and new advisories checked without a rescan. Both are open source, and the two run side by side without conflict.
Where does my data go?
Self-hosted: nowhere. The package lists, findings and history sit in a Postgres in your cluster, and the only outbound traffic is the server fetching advisories. On the cloud: no images, no source code, no secrets. Only package names, versions and workload names leave your cluster, over one outbound connection, to servers in the EU.
Can I check any of this?
Yes. The scanner, the server and the dashboard are all on GitHub under an open-source licence, and the cloud runs the same images as a self-hosted install. Every finding links to its public advisory on osv.dev, so you can verify it against a database we do not own. And the prices are on this page, not behind a sales call.
Full detail, including how to report a vulnerability, is on the security page.
What people check before installing.
Why not just use Trivy Operator? It is free.
Often you should — for one or two clusters where you only need to know what is vulnerable right now, it is a genuinely good answer. The difference: Trivy Operator stores scan results inside each cluster as custom resources that expire after a day, so it has to rescan and each cluster stands alone. StackRadar keeps the dependency list itself, in its own database rather than in etcd, so new advisories are checked against it without a rescan, across every cluster at once, with a dated history. Both are open source. See the Trivy Operator card above for when to stay.
Is StackRadar open source?
Yes. The server, the dashboard and the Helm chart are AGPL-3.0; the scanner agent and the CLI are Apache-2.0. The cloud at app.stackradar.io runs the same images with the cloud edition switched on. The cloud-only code — billing, email alerting, enterprise single sign-on — sits in the same repository under its own directory and a source-available licence that allows everything except offering it as a hosted service. All of it is on GitHub.
Should I self-host it or use the cloud?
Self-host if you have one cluster, want nothing to leave it, and are happy to run a Postgres: one Helm command installs the server, the dashboard, a bundled database and the scanner, already scanning the cluster it lands in. Use the cloud if you have several clusters in different networks or accounts and want them in one dashboard, want alerts by email and Slack, or would rather not operate the database and the vulnerability mirror. Both run the same images. Every cloud plan starts with a 14-day free trial: a card at checkout, nothing charged until the trial ends, and nothing charged at all if you cancel before then.
Does my image data leave the cluster?
Self-hosted, nothing does: the dependency lists, the findings and the history stay in a database in your cluster, and the only outbound traffic is the server downloading advisories from OSV.dev, EPSS and CISA. On the cloud, the scanner sends exactly two things to StackRadar: the dependency lists (package names, versions, and licenses — none of your own code) and a list 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, never anything else). Your actual container images, source code, secrets, and environment variables never leave your network either way. Everything you upload to the cloud is stored and processed only on servers in the EU.
Can I cancel anytime?
Yes. No contracts, no commitments. Cancel from your dashboard with one click. Cancel during the trial and you are never charged; cancel later and you keep access until the end of the period you paid for. If you self-host, there is nothing to cancel in the first place.
How do I get in touch?
Email contact@stackradar.io for anything — questions, feedback, enterprise pricing, or help with an install. A person reads it and replies. Questions about a self-hosted install are welcome in GitHub Discussions too, where the answer helps the next person. Security reports go to security@stackradar.io; see the security page for disclosure details.
The next CVE lands whether or not you are ready.
Since 11 September 2026 the EU Cyber Resilience Act gives manufacturers 24 hours to report an actively exploited vulnerability. Knowing which pod runs it is step one, and one Helm install keeps that answer current.
14-day free trial · card required · nothing charged until it ends