StackRadar vs Trivy Operator: managed fleet visibility vs in-cluster CRDs
Trivy Operator is excellent at what it does — in-cluster scanning with results as Kubernetes CRDs. An honest look at where that model works, where it runs out of road, and how StackRadar differs.
StackRadar Team
· 7 min read
If you ask r/kubernetes how to scan your cluster for vulnerabilities, the most common answer — deservedly — is Trivy Operator. It's free, Apache-2.0 licensed, maintained by Aqua Security, and built on Trivy, one of the best scanners in the ecosystem. We're not going to pretend otherwise. This post is about the architectural choice at its core — storing scan results as Kubernetes CRDs inside each cluster — and what that choice means once you run more than one cluster or need to answer questions about last month, not just right now.
What Trivy Operator does well
Trivy Operator watches your workloads and automatically scans them as they change. The results land in your cluster as custom resources: VulnerabilityReport, SbomReport, ConfigAuditReport, ExposedSecretReport, RbacAssessmentReport, ClusterComplianceReport, and more. That design has real advantages:
- Everything stays in the cluster. No agent phones home, no data leaves your network. For air-gapped or high-compliance environments this can be the deciding factor on its own.
- Results are Kubernetes-native.
kubectl get vulnerabilityreports -Ajust works, and so does anything built on the Kubernetes API — RBAC on reports, GitOps-style consumers, custom controllers. - It covers more than vulnerabilities. Config audit, exposed secrets, and RBAC assessment come in the same package.
- Prometheus integration is built in. If you already live in Grafana, you can get severity counts on a dashboard quickly.
If you run one or two clusters, have Grafana muscle memory, and mainly want a current snapshot of what's vulnerable, Trivy Operator is a genuinely good answer and you may not need anything else.
Where the CRD model runs out of road
Each cluster is a silo
Reports live in the cluster that produced them. With five clusters, "are we exposed to this CVE?" means five kubeconfigs, five kubectl queries, and a spreadsheet — or building and maintaining your own aggregation layer (metrics federation, report exporters, a central store). The operator deliberately doesn't solve fleet visibility; every multi-cluster team ends up building some version of it themselves.
Reports are snapshots, not history
Trivy Operator keeps results fresh with a TTL: by default a VulnerabilityReport expires after 24 hours (OPERATOR_SCANNER_REPORT_TTL), gets deleted, and the workload is rescanned with an updated vulnerability database. That's a sensible freshness mechanism, but it also means the old report is gone. There is no answer to "when did this CVE first appear in our environment?", "what was our exposure on the day of the audit?", or "is our critical count trending down?" unless you export and store reports yourself.
Your security data lives in etcd
CRDs are stored in etcd alongside everything else that keeps your cluster alive. A large cluster produces a lot of report objects — one per container per workload — and etcd is not a database you want to grow unboundedly; it's the control plane's memory. Teams running Trivy Operator at scale end up tuning TTLs and scan scopes partly to manage report volume, which trades observability for cluster health.
No triage state
Reports are regenerated on every scan cycle, so they can't carry workflow: there is no "accepted risk", no "false positive, suppressed with justification", no assignment. Suppression happens via .trivyignore-style configuration, which silences a finding everywhere without recording who decided that or why — exactly the paper trail an auditor asks for.
The StackRadar model
StackRadar splits the problem differently: a lightweight open-source agent in the cluster, and everything stateful outside it.
- The agent only generates SBOMs. It watches workloads and uploads a CycloneDX SBOM per image — the dependency inventory, not your source, not your secrets. What leaves the cluster is documented precisely in the architecture reference.
- Matching happens server-side, continuously. SBOMs are matched against a local mirror of OSV.dev (300K+ advisories) that updates from OSV's change feed. When a new advisory lands, it's applied to SBOMs you uploaded last month — no rescan, no waiting for the next TTL cycle, and no scan CPU burned in your cluster to re-discover the same dependency list.
- Fleet-first dashboard. "Which workloads in any cluster are affected by this CVE?" is one query, because all clusters report into one place.
- History and triage are first-class. Findings persist, so trend lines, audit-day snapshots, and suppressions with a recorded justification all exist without you exporting anything.
- EU data residency. Your SBOM data is stored in the EU — relevant if the Cyber Resilience Act or NIS2 is on your roadmap (we wrote about what the CRA means for Kubernetes SBOMs).
The honest trade-off in the other direction: SBOMs do leave your cluster, and the dashboard is a managed service, not something you self-host. If "no data egress, ever" is a hard requirement, Trivy Operator's model fits better.
When to choose which
| Your situation | Better fit |
|---|---|
| 1–2 clusters, Grafana-centric team, current-state visibility is enough | Trivy Operator |
| Hard requirement that no data leaves the cluster | Trivy Operator |
| You also want in-cluster config audit / RBAC assessment | Trivy Operator (or run both) |
| Multiple clusters, one place to answer "are we exposed?" | StackRadar |
| Audit trail: history, trends, suppressions with justification | StackRadar |
| EU data residency / CRA & NIS2 compliance posture | StackRadar |
Seeing the difference takes one Helm install
The quickest way to evaluate the model is side by side with what you run today: install the scanner in a dev cluster and compare answering "what's affected by the next big CVE?" in both tools.
# Trivy Operator, per cluster:
kubectl get vulnerabilityreports -A -o json | jq '..' # then repeat per kubeconfig
# StackRadar: search the CVE once, see every affected workload in every cluster