Trivy Operator: Continuous Scanning Inside Kubernetes

What the Trivy Operator does

The Trivy Operator is an open-source Kubernetes operator from Aqua Security, and the successor to the Starboard project. It follows the standard operator pattern: it watches cluster resources, and when it sees a workload it has not scanned — or one whose image has changed — it schedules a scan job, runs Trivy, and writes the result back into the cluster as a custom resource.

The key idea is that security findings become first-class Kubernetes objects. Instead of a report sitting in a CI artifact somewhere, a VulnerabilityReport lives next to the Deployment it describes, queryable with kubectl and consumable by anything that speaks to the Kubernetes API. Because the operator re-reconciles, findings update as the Trivy database learns about new CVEs, even for images that have not been rebuilt.

Installing it with Helm

The supported install path is the official Helm chart. This drops the operator into its own namespace and starts it reconciling immediately:

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update

helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set="trivy.ignoreUnfixed=true" \
  --set="operator.scannerReportTTL=24h"

Two settings worth knowing from the start: trivy.ignoreUnfixed=true hides CVEs with no available fix so reports stay actionable, and operator.scannerReportTTL controls how long reports live before the operator refreshes them. In large clusters you also point the operator at a shared Trivy server so every scan job does not re-download the vulnerability database.

Reading the reports

Once the operator has reconciled, the reports are ordinary Kubernetes objects. List the vulnerability reports across all namespaces and drill into one:

# Every image scanned, with a severity breakdown per report
kubectl get vulnerabilityreports -A \
  -o custom-columns=NS:.metadata.namespace,\
NAME:.metadata.name,\
CRIT:.report.summary.criticalCount,\
HIGH:.report.summary.highCount

# Full detail for a single report
kubectl get vulnerabilityreport -n default \
  replicaset-web-6d4cbf-web -o json | jq '.report.summary'

The other report types work the same way. A quick tour:

Wiring it into Prometheus and Grafana

The operator exposes the report data as Prometheus metrics, which is what makes it useful beyond ad-hoc kubectl checks. With metrics enabled you can alert when a namespace crosses a critical-count threshold or graph vulnerability trends over time:

# Enable the ServiceMonitor for a Prometheus Operator stack
helm upgrade trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --set="serviceMonitor.enabled=true"

# Example PromQL: total critical CVEs across the cluster
sum(trivy_image_vulnerabilities{severity="Critical"})

From there a Grafana dashboard or an Alertmanager rule turns the reports into something a team actually watches, rather than data that only surfaces during an incident review.

What it is good at, and what it is not

The Trivy Operator is a strong fit for one job: continuous, automated, Kubernetes-native visibility into what is already running. It requires almost no glue code, reports refresh as advisories publish, and everything is queryable through the API you already use. If you run Kubernetes and want a standing inventory of workload risk, it earns its place.

Two honest caveats. First, it observes rather than enforces — it will happily report that a running Pod is riddled with critical CVEs, but it does not stop that Pod from being scheduled. Blocking is an admission-control problem, covered in Kubernetes admission control for image scanning. Second, it runs the Trivy engine, so it inherits Trivy's finding depth. In our 2026 benchmark Trivy reported 10 findings on ubuntu:24.04 where multi-source scanning found 1,365. The operator does not change that number — it is the same scanner, run more often.

Where ScanRook fits

The two tools sit at different points in the lifecycle. The Trivy Operator watches what is already deployed; ScanRook scans the artifact before it deploys, in CI or on registry push, and does so with multi-source enrichment — matching every package against OSV, NVD, and Red Hat OVAL and reading the real installed-package state inside the image. A common pattern is to scan deeply pre-deploy with ScanRook so a vulnerable image never ships, and keep the Trivy Operator running in-cluster for continuous drift detection on what is already there. If you are weighing scanners head to head, our Trivy alternatives piece and the ScanRook vs Trivy page lay out the tradeoffs.

Frequently asked questions