StackRadar vs Trivy Operator
Trivy Operator is the free in-cluster scanner most Kubernetes teams start with, and for good reason. This page is for teams already running it: what each tool does inside your cluster, what each costs to operate, what you see afterwards — and how to run both side by side for a week before deciding anything.
Facts last checked . Prices and features change — verify with the vendor before deciding.
The short version
Both tools answer the same first question: which images running in my cluster have known vulnerabilities? They differ in where the work happens. Trivy Operator does everything inside the cluster — it scans, stores and re-scans there, and the results are Kubernetes objects. StackRadar does one small thing inside the cluster — it lists what is in each image, once — and does the rest on a server: matching, ranking, history, and the view across clusters.
That one decision explains almost every difference below. It is why Trivy Operator can promise that nothing leaves your cluster, and why StackRadar can promise that your cluster does no work when a new CVE lands.
What Trivy Operator does well
- Free, open source, and maintained by the company that maintains Trivy itself.
- Nothing leaves the cluster — results are CRDs you read with kubectl.
- Covers more than vulnerabilities: config audit, exposed secrets, RBAC assessment and compliance reports ship in the same operator.
- Prometheus metrics out of the box, so a Grafana dashboard is quick to stand up.
If you run one cluster, want a current snapshot, and already live in Grafana, it is a genuinely good answer and we will not pretend otherwise.
How each one scans
Trivy Operator: a job per workload, on a loop
The operator watches your workloads and creates a Kubernetes Job for each one it needs to scan. The job runs Trivy against the workload's images and writes a VulnerabilityReport into the cluster. Reports carry a time-to-live — 24 hours by default — and when one expires, the workload is scanned again. Up to ten scan jobs run at once by default. In the default Standalone mode each job fetches the Trivy vulnerability database for itself; the alternative is ClientServer mode, where you run a shared Trivy server that the jobs talk to.
StackRadar: one agent, once per image
A single agent watches pods. When it sees an image digest it has not seen before, it asks StackRadar whether this cluster has already indexed that digest. If not, it pulls the image from its registry, generates a CycloneDX SBOM with Syft, uploads it, and remembers the digest. That image is never scanned again — not after a restart, not tomorrow, not when it shows up in five more namespaces. Finding vulnerabilities in that SBOM is the server's job, and it is repeated there whenever the advisory data changes.
What each costs to run
Trivy Operator is free, so its price is paid in operation. StackRadar has an operating cost too — it is a different shape.
| In your cluster | StackRadar | Trivy Operator |
|---|---|---|
| What runs | One agent Deployment, always on | The operator, plus a scan Job per workload (up to 10 at once by default) |
| Memory | One pod: 512Mi requested, 1Gi limit. Scans run one at a time | Per scan job: 100M requested, 500M limit — times the jobs running |
| How often an image is scanned | Once per image digest, then never again | Every time its report expires (24 hours by default) |
| Vulnerability database | None in the cluster; matching is server-side | Downloaded into the cluster — by every scan job in the default Standalone mode |
| Where results are stored | Outside the cluster. Nothing is written to etcd | In etcd, as one custom resource per workload and report type |
| When a new CVE is published | Stored SBOMs are re-matched on the server; the cluster does nothing | Found at the next rescan |
| What leaves the cluster | The SBOM of each image — a dependency list | Nothing |
Read the memory row carefully, because it does not flatter us at small scale: one idle StackRadar agent reserves more memory than one Trivy Operator scan job. The difference shows up with size and time. The agent's footprint is flat — the same pod whether you run twenty images or two thousand, working only when something new is deployed. Trivy Operator's footprint follows your workload count, and repeats daily.
What teams running Trivy Operator tend to run into
These are the themes that come up again and again among people operating it on busy clusters. All of them can be tuned around, and many teams do. The point is that the tuning is yours.
- Scan jobs killed for memory. A large image does not fit in the default 500M job limit. The usual fix is raising the limit to around 1.5G, cutting the number of concurrent jobs, or moving to a shared Trivy server.
- Steady CPU load. Scanning every workload every day is a permanent background task, and it grows with the cluster.
- Reports too large for etcd. An image with thousands of findings produces a report bigger than Kubernetes will store. The report fails to save, and the scan job is left behind.
- Database download failures. Rate limits and registry authentication on the vulnerability database download stop scans. The usual fix is mirroring the database into a registry you run.
- Network cost. Re-pulling images and the database on every cycle is billed traffic behind a cloud NAT gateway.
- Leftovers. Completed jobs and pods that are not cleaned up, and old reports that outlive the workloads they described.
What you see afterwards
The scan is only the start. What matters on a Tuesday morning is what you can do with the results.
- Ranking. Trivy Operator sorts by CVSS severity. StackRadar ranks by the Radar Score, which adds EPSS exploitation probability and the CISA Known Exploited Vulnerabilities catalogue — so a 5.3 that is being exploited today sorts above a 9.8 nobody has ever used.
- History. Trivy Operator's reports are replaced each cycle; there is no record of last month. StackRadar keeps findings over time: when something first appeared, when it was fixed, what you were exposed to in March.
- More than one cluster. Trivy Operator is one island per cluster. StackRadar answers "where are we running this?" once, for all of them.
- Context. StackRadar ties each image to its workload, Helm release and ArgoCD application, so a finding points at the chart to bump or the app to change.
We go deeper on this side of the comparison in StackRadar vs Trivy Operator: managed fleet visibility vs in-cluster CRDs.
What Trivy Operator covers that StackRadar does not
- Configuration audits of your Kubernetes manifests.
- Exposed-secret scanning.
- RBAC assessments.
- Compliance reports such as CIS and the Pod Security Standards.
- Fully offline operation. StackRadar is a hosted service, and SBOMs leave the cluster.
- It is free. StackRadar is free for one cluster, and paid above that.
StackRadar does vulnerabilities and SBOMs, and nothing else. If you rely on the checks above, keep Trivy Operator for them — the two run happily in the same cluster.
Side by side
| Axis | StackRadar | Trivy Operator |
|---|---|---|
| Where it runs | One Helm chart in the cluster; self-hosted (AGPL-3.0) or reporting to the cloud dashboard | Operator in the cluster; results as CRDs in etcd |
| Kubernetes runtime inventory | Yes — every running image, with its workload, Helm release and ArgoCD application | Yes — scans running workloads |
| SBOM | CycloneDX 1.6 per running image (Syft), stored and re-checked as new advisories land | SbomReport CRDs (CycloneDX); rescans rather than re-matches |
| Prioritisation | Radar Score — CVSS, EPSS and CISA KEV combined in a published formula | CVSS severity only |
| History and trends | 1 year (Pro), 2 years (Business); 1 year self-hosted | None — reports expire (24h default) and are regenerated |
| Multi-cluster view | One cloud dashboard across every cluster in the organisation; self-hosted is one cluster | None built in; DIY aggregation |
| Scanner source | Open source: scanner Apache-2.0, server and dashboard AGPL-3.0; releases signed and version-pinned | Open source (Apache-2.0) |
| Pricing | Free to self-host · Cloud: 14-day free trial, then Pro $59/mo · Business $199/mo at beta price ($99 / $299 standard) | Free; operational cost only |
| Data residency | Self-hosted: stays in your cluster. Cloud: EU only, and only the SBOM leaves the cluster | Stays in your cluster |
Pricing
Trivy Operator: Trivy Operator is free and open source. The cost is operational: someone maintains the operator, tunes report TTLs and scan scopes to keep etcd healthy, and builds whatever aggregation, history and alerting the team needs on top of the CRDs. Aqua sells its commercial platform separately, quote-only.
StackRadar: Free to self-host for one cluster (AGPL-3.0). The cloud starts with a 14-day free trial; then Pro at $59 per month for up to five clusters and one year of history; Business at $199 per month for up to fifteen clusters and two years. Those are beta prices, for the first 10 Pro and 5 Business subscriptions; after that Pro is $99 and Business $299 a month. Every plan scans every image you run. Full details on the pricing page.
Run both for a week
You do not have to switch to find out. The StackRadar agent installs next to Trivy Operator and the two ignore each other. Pick one cluster — a staging cluster is fine — follow the quick start, and leave both running for a week. Then compare three things.
# Trivy Operator: the operator plus whatever scan jobs are running
kubectl top pods -n trivy-system
# StackRadar: one pod
kubectl top pods -n stackradar
# How many report objects etcd is holding for you
kubectl get vulnerabilityreports,sbomreports,configauditreports -A --no-headers | wc -l2. Whether they agree. Pick three images you know well and compare the findings. They will not match exactly — the two use different advisory sources — and the differences are worth ten minutes. If StackRadar is wrong about one of your images, we want to hear about it.
3. How long one real question takes. "Which of our workloads are affected by the CVE everyone is talking about this week, and which should we fix first?" Answer it in both.
If you would rather look before installing anything, the live demo is a real cluster's data with no signup.
Which should you choose?
Choose Trivy Operator if
- You run one or two clusters and mainly want to know what is vulnerable right now.
- You have a hard rule that no data may leave the cluster — not even a dependency list.
- You want config, secrets and RBAC checks in the same package.
- Your team already lives in Grafana and the Prometheus metrics are enough.
Choose StackRadar if
- You need one answer across every cluster, not one cluster at a time.
- You need to answer “when did this first appear?” or “what were we exposed to in March?”
- You want findings ranked by real-world exploitability (EPSS, KEV), not CVSS alone.
- You need a dated paper trail for an auditor or an EU regulator (CRA, NIS2).
- You are tired of operating the scanner: tuning scan jobs, report TTLs and database mirrors to keep it and etcd healthy.
Frequently asked questions
Is Trivy Operator good enough on its own?
For a single cluster where you want a current snapshot of vulnerabilities and some config checks, yes — it is a genuinely good free answer. It stops being enough when you need history, a multi-cluster view, exploitability-based ranking or a record you can show an auditor.
Can I run Trivy Operator and StackRadar together?
Yes, and it is the honest way to evaluate. The two do not conflict: install the StackRadar agent next to Trivy Operator on one cluster, leave both for a week, and compare the findings and the resource usage. Some teams then keep Trivy Operator for config, secrets and RBAC checks inside each cluster and use StackRadar as the one place that tracks vulnerabilities across all of them over time.
Why does Trivy Operator use so much CPU and memory?
Because of how it scans. Every workload gets its own scan Job, up to 10 run concurrently by default, each job loads the vulnerability database, and the whole cycle repeats when reports expire after 24 hours. On a large cluster that is a steady background load, and an image too big for the job’s memory limit (500M by default) is OOMKilled. It can be tuned — lower the concurrency, raise the limits, switch to ClientServer mode with a shared Trivy server — but it is tuning you own.
Does StackRadar download a vulnerability database into my cluster?
No. The agent only generates SBOMs; matching against advisories happens on the StackRadar server. The agent does pull each new image digest from its registry once to build the SBOM — Syft can use 300–600 MiB on a large image, so scans are serialised by default — and it never pulls that digest again, even across restarts.
Does Trivy Operator keep vulnerability history?
No. VulnerabilityReport objects have a TTL (24 hours by default), after which they are deleted and the workload is rescanned. Anything historical has to be exported and stored by you.
Does Trivy Operator use EPSS or CISA KEV?
Trivy Operator ranks by CVSS severity. EPSS exploitation probability and the CISA Known Exploited Vulnerabilities catalogue are not part of its reports, so a never-exploited 9.8 sorts above a 5.3 that is being exploited today.