Trivy Operator alternatives for more than one cluster: aggregate it, put a platform on top, or replace the vulnerability side

Trivy Operator has no multi-cluster mode. Every cluster runs its own copy, and every copy answers only for itself. Past two or three clusters you can either build the missing layer yourself (Prometheus metrics into a central store, or the webhook into a database), add a free aggregator like Policy Reporter, or move vulnerability tracking to something that was built for a fleet: Aqua or ARMO if you want the vendors behind Trivy and Kubescape, Dependency-Track if you are happy to build the SBOM pipeline, StackRadar Cloud if you want one dashboard with history for a fixed monthly price. Most teams keep Trivy Operator in each cluster either way, for the checks nothing else does.

This post is about one specific wall: the team that ran Trivy Operator happily in one cluster and now has five, or thirty. If you are weighing it on its own merits, the general list of Trivy Operator alternatives and the feature-by-feature comparison cover that. If your problem is reports that will not fit in etcd, that has its own post.

What breaks when you add the second cluster

Nothing breaks inside any one cluster. What breaks is every question that spans them.

• "Are we running it anywhere?" becomes a loop. A CVE lands in Slack and the answer is a kubectl get vulnerabilityreports -A per kubeconfig, piped through jq, pasted into a thread. With three clusters that is annoying. With thirty it is somebody's afternoon, every time. The single-cluster version is already four steps.
• There is no history to compare. Reports expire after 24 hours by default (operator.scannerReportTTL) and are regenerated. So "did staging have this before production did" or "what were we exposed to in September" has no answer unless you exported the reports at the time.
• Every cluster pays the scanning cost separately. Each operator runs a scan Job per workload, up to 10 at once by default, and in the default Standalone mode each job fetches the Trivy database. The same nginx digest running in twelve clusters is scanned twelve times, and rescanned in all twelve when the reports expire.
• Alerting fans out. Whatever you wire up for one cluster (a Prometheus rule, a webhook, a Slack message) you now wire up, tune and silence N times, and the same finding arrives N times.
• Triage does not travel. Reports are regenerated, so there is nowhere to record "accepted, not reachable, revisit in Q1" even in one cluster. Across a fleet, the spreadsheet that ends up holding those decisions is the real system of record.

What Trivy Operator still does best

Before replacing anything: the operator does more than vulnerabilities, and most of the alternatives below do not. Config audits against Kubernetes best practice, RBAC assessments, exposed secrets in images, and the CIS and NSA compliance reports all come out of the same install, free, with nothing leaving the cluster. If those matter to you, the realistic plan is not "remove Trivy Operator". It is to keep it in every cluster for posture, move vulnerability tracking somewhere central, and switch its vulnerability scanner off so you stop paying for the scan jobs twice:

operator:
  vulnerabilityScannerEnabled: false

The options, side by side

Keep it, and aggregate the metrics

Trivy Operator exposes a /metrics endpoint by default, and its chart can install a ServiceMonitor. trivy_image_vulnerabilities carries a count per workload, container, image and severity. Turn on operator.metricsVulnIdEnabled and you also get trivy_vulnerability_id, one series per finding with the CVE ID, the package, the installed and fixed versions as labels. If each cluster's Prometheus already remote-writes to Thanos, Mimir or a hosted Prometheus with a cluster external label, you have most of a fleet view for the cost of two flags:

helm upgrade --install trivy-operator \
  oci://ghcr.io/aquasecurity/helm-charts/trivy-operator \
  --namespace trivy-system --create-namespace \
  --set serviceMonitor.enabled=true \
  --set operator.metricsVulnIdEnabled=true

# Critical findings per cluster, right now
sum by (cluster) (trivy_image_vulnerabilities{severity="Critical"})

# Where is CVE-2026-109618 running? (needs metricsVulnIdEnabled)
count by (cluster, namespace, resource_name) (
  trivy_vulnerability_id{vuln_id="CVE-2026-109618"}
)

This is the cheapest real answer and many teams should stop here. It is honest to name what it does not give you. The project's own values file warns that the vulnerability ID metric "significantly" increases cardinality, and a fleet of busy clusters can turn it into the most expensive series in your metrics bill. Prometheus keeps counts over time, not the findings themselves, so trends work but "which exact packages were vulnerable on 3 September" does not. Ranking is still CVSS severity: no EPSS, no KEV. And the data is only as fresh as each workload's last scan; a CVE published this morning shows up when the reports next expire and the jobs run again, not before.

Keep it, and ship the reports out

operator.webhookBroadcastURL makes the operator POST each report as it is produced, VulnerabilityReports and SbomReports included, to an endpoint you choose. Put a small receiver behind it that writes to Postgres or a bucket, and the reports outlive their TTL. Aqua's own suggestion for the receiver is Postee, which routes reports to Slack, ServiceNow and the rest; for storage you write your own.

This is the route to history and a true fleet query, and it is also the route to maintaining a small vulnerability product: a receiver, a schema, deduplication across clusters (the same digest arrives once per cluster per scan cycle), retention, a UI or at least saved queries, and the EPSS and KEV joins if you want them. Our CronJob-and-a-bucket walkthrough is the minimal version of the same idea without the operator.

Keep it, and put Policy Reporter on top

Policy Reporter, from the Kyverno project, is a dashboard and notifier for the PolicyReport CRD. The trivy-operator-polr-adapter converts Trivy Operator's reports into PolicyReports, and the Policy Reporter UI can be pointed at the Policy Reporter API of several clusters at once. You get a free web UI with a cluster switcher, filters, and notifications to Slack, Teams or Loki without writing a receiver. It shows current state, the same as the CRDs it reads, so it solves the "which kubeconfig" problem and none of the history or ranking ones. It suits teams that already run Kyverno and want security findings next to their policy results.

Move up to the vendor behind the scanner: Aqua or ARMO

Aqua maintains Trivy and sells the platform Trivy Operator is the free edge of: multi-cluster inventory, history, prioritisation with EPSS and runtime context, admission control and runtime protection. It is the least disruptive move if you trust Trivy's results and want them in a product. It is sold through sales and does not publish prices; the one public figure, a reseller's marketplace listing, starts at $50,000 a year. The Aqua comparison has the details.

ARMO does the same for Kubescape. The open-source operator is a strong product on its own (posture scanning, Grype-based image scanning, and an eBPF signal for which vulnerable packages are actually loaded), and the ARMO Platform adds the multi-cluster view, history, EPSS and KEV. ARMO's AWS Marketplace listing is $49 per worker node a month, free up to 10 nodes. Per-node pricing is worth modelling before you commit: a fleet of many small clusters is cheap, a few large ones are not. Kubescape compared.

Move the scan to the shared registry: Harbor

If every cluster pulls through one Harbor, the registry is already the one place all your images pass. Harbor scans each artefact on push and on a schedule with Trivy, keeps the result per artefact, and can block pulls above a severity. That turns N scanners into one. What it cannot tell you is where an image runs, or whether it runs at all: an image pushed in March and never deployed is scanned as carefully as the one in production, and a pod that pulls straight from Docker Hub is invisible to it. Harbor answers "is anything bad in our supply", and pairs well with any of the in-cluster options for "is anything bad running".

Feed every cluster into Dependency-Track

OWASP Dependency-Track keeps SBOMs and re-evaluates them as advisories change, which is exactly the fix for expiring reports, and it handles EPSS and, since v5.1, KEV in policies. Feeding it from a fleet means a pipeline per cluster: the Trivy Operator webhook can carry SbomReports to a receiver that uploads them, or a CronJob can build the SBOMs itself. You then model each cluster, namespace and workload as Dependency-Track projects and keep that mapping current as pods move to new digests. Teams with SBOMs from CI and vendors already in Dependency-Track get the most from this; the comparison covers the overlap with StackRadar, which is large.

One dashboard for the fleet: StackRadar Cloud

StackRadar was built for the question at the top of this post. You install the scanner chart once per cluster, each with its own API key and cluster ID from the dashboard:

helm install stackradar-scanner \
    oci://ghcr.io/lockdep/charts/stackradar-scanner \
    --version <latest-version> \
    --namespace stackradar --create-namespace \
    --set stackradar.apiKey=$STACKRADAR_API_KEY \
    --set stackradar.clusterId=$STACKRADAR_CLUSTER_ID

The scanner is one read-only Deployment that builds one SBOM per running image digest and never scans that digest again; there are no scan Jobs and no vulnerability database in the cluster, and only the SBOM leaves it. The server keeps every SBOM, re-matches all of them against its OSV mirror when an advisory lands, so a new CVE shows up without a rescan, and scores each finding with CVSS, EPSS and KEV. Every finding carries its cluster, namespace, workload and Helm release, so "where are we running it" is one search across the fleet, with history behind it and one set of critical and KEV alerts to email and Slack instead of N.

Prices are on the pricing page: Pro is $59 a month at the beta price ($99 standard) for up to 5 clusters, Business $199 ($299 standard) for up to 15 clusters, both after a 14-day trial. The data is hosted in the EU.

If you are buying a platform anyway: Sysdig or Wiz

If the multi-cluster problem arrived alongside a mandate for runtime threat detection or cloud posture, a CNAPP covers vulnerability tracking as one module among many. Sysdig Secure's AWS Marketplace listing is $72 per host a month with a 20-host minimum, and it is the strongest on runtime. Wiz lists $24,000 a year per 100 workloads for its Essential tier and is strongest on cloud context. Neither is a sensible purchase for vulnerability tracking alone; both are reasonable if that is the smallest of the things you need. Sysdig and Wiz have their own comparisons.

Choosing

• Two to five clusters, central Prometheus already in place: turn on the metrics, build the Grafana board, and revisit when someone asks for history.
• You run Kyverno and want a free UI: Policy Reporter with the Trivy adapter.
• Every image comes through your registry: Harbor for the supply side, plus one of the others for what runs.
• SBOMs already flow into Dependency-Track from CI: feed the clusters into it too, and budget for the pipeline.
• You want one dashboard with history, EPSS and KEV, and a price you can read before a sales call: StackRadar Cloud, with Trivy Operator kept for posture.
• You need runtime protection or posture across clouds as well: Aqua, ARMO, Sysdig or Wiz, and take vulnerability tracking as part of the bundle.

Frequently asked questions