trivy-operator: turning Trivy scans into Kubernetes custom resources

A watch loop that scans on state change

The Trivy Operator leverages Trivy as a resident component inside a cluster. It registers as a Kubernetes controller, watches the API for state changes, and triggers a scan when something relevant happens. The README's own example is the clearest statement of the model: a vulnerability scan is initiated when a new Pod is created.

Output goes back the same way. Findings are summarised into security reports expressed as Custom Resource Definitions, which means they are readable through the Kubernetes API like any other object. That is the design decision that distinguishes this project from a nightly cron job that pipes scan output into a SIEM.

The operator does not reimplement scanning. It drives Trivy, which the module manifest pins at `github.com/aquasecurity/trivy v0.75.0`, alongside `trivy-checks`, `trivy-db`, and `trivy-kubernetes` as separate dependencies. Each is versioned independently, so an operator upgrade can pull a new scanner without a code change, and a scanner fix can arrive without an operator upgrade.

Seven report kinds, from secrets to infrastructure

The report list is broader than vulnerability scanning, and the differences matter when you decide whether this replaces another tool in your stack.

Vulnerability scans cover Kubernetes workloads plus control plane and node components, with api-server, controller-manager, and kubelet named explicitly. ConfigAudit scans audit Kubernetes resources against predefined rules or custom Open Policy Agent policies. Exposed Secret scans find and detail the location of exposed Secrets in the cluster. RBAC scans report the access rights of the different resources installed, which answers the question of who can do what in a form an auditor can read.

Then there is infra assessment of core components, covering etcd, apiserver, scheduler, and controller-manager settings and configuration. A separate check validates whether a resource's API is deprecated and planned for removal, surfacing the problem during a ConfigAudit rather than when an upgrade breaks. Compliance reports are produced against NSA and CISA Kubernetes Hardening Guidance v1.1, the CIS Kubernetes Benchmark v1.23, and both the Pod Security Standards baseline and restricted levels. SBOM generation for workloads is also included, built on `github.com/CycloneDX/cyclonedx-go`.

Read together, that list covers most of what a cluster security review asks for in one installation. The cost of breadth is that you inherit all of it, whether or not you wanted every report type on day one.

Installing with Helm, and the version gap between chart and tag

Two install paths are given. The first adds Aqua's chart repository and installs from it:

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 \
  --version 0.37.0

The second skips the repo entirely and pulls the chart from an OCI registry, which the README marks as supported in Helm v3.8.0 and later:

helm install trivy-operator oci://ghcr.io/aquasecurity/helm-charts/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --version 0.37.0

Both install into the `trivy-system` namespace with `--create-namespace`, and the README states that this starts triggering the scans. That word triggers is worth pausing on: the operator is event driven, so findings arrive when resources change, not as a one-time sweep you wait for.

There is a discrepancy to resolve before you pin anything. The install commands specify chart version `0.37.0`, while the most recent listed release tag is `v0.35.0`, dated 2026-10-05. Chart versions and application tags are not always the same scheme, and the chart repository is a separate repository from this one. If you need to tie a running deployment to a source tag for an audit, resolve that mapping yourself rather than assuming the numbers match. Static YAML manifests are also offered as an alternative to Helm for clusters where a chart is not wanted.

The project says outright that its APIs may change

The Status section is short and unusually direct. The maintainers write that while they try to keep new releases backward compatible, the project is still incubating and some APIs and Custom Resource Definitions may change.

That sentence defines the adoption risk more precisely than any feature list. A consumer of these reports is a piece of software: a policy engine, a dashboard, a CI check, or an alert rule with a field selector in it. If the CRD schema changes, that consumer breaks, and the compatibility promise is explicitly best effort. The mitigation is not technical, it is operational. Treat anything you build on top of the CRDs as versioned against the operator version, and expect to revisit selectors and field names when you upgrade.

The rest of the Status section reinforces the framing, describing this as an early stage and inviting feedback on the overall concept, with contributions aimed at integrating other security tools so information is reachable in standard Kubernetes-native ways. That is an invitation to plug in adjacent scanners, and it is a reasonable way to think about the project's longer-term shape: Trivy is the first engine, not the only one.

What it depends on underneath

The Go module file pins `go 1.27.0` and lines up against the Kubernetes libraries at `k8s.io/api v0.37.0`, `k8s.io/apimachinery v0.37.0`, `k8s.io/client-go v0.37.0`, and `k8s.io/cli-runtime v0.37.0`, with `sigs.k8s.io/controller-runtime v0.24.1` for the controller machinery. Anyone tracking the Kubernetes client libraries across their estate will see this operator move with them.

Other dependencies include `github.com/gorhill/cronexpr`, `github.com/google/go-containerregistry`, `github.com/aws/aws-sdk-go-v2`, `github.com/caarlos0/env/v6`, the Prometheus client libraries, and `go.uber.org/automaxprocs`.

The repository layout is conventional for a Go operator: `cmd/`, `pkg/`, `deploy/`, `tests/`, `hack/`, and both `magefile.go` and `mage.go` for build orchestration. There is a `RELEASING.md` and a `.goreleaser.yaml`, and both `goreleaser-e2e.yaml` and a `zizmor.yml` config are present. The test stack is Ginkgo with Gomega, run alongside testify.

Where this fits against the alternatives

The obvious alternative is running Trivy yourself against a registry or a cluster on a schedule and exporting results to a dashboard. The difference in approach is precise: that arrangement produces log output or API calls at intervals, while this produces API objects tied to the lifecycle of the resources being described. Any tooling that already speaks Kubernetes, such as RBAC-scoped service accounts, label selectors, or a policy engine, reaches the findings directly.

A second alternative is a cloud security posture management product.

The honest counterpoint is that event-driven does not mean exhaustive. A finding appears when a resource changes, so a cluster where nothing changes produces no new reports, and the first reports appear as changes occur rather than as a complete census at install time. If your process requires a periodic full sweep with a signed record, you still need that separately. The compliance report types help, since CIS and the Pod Security Standards give a named target, but the scan trigger remains the watch event.

Licence, pace, and the cost of upgrading

The licence is Apache-2.0, an Aqua Security open source project. That is the permissive end of the scale, and running the operator in your own cluster raises no licensing question for the operator itself. The Trivy and Kubernetes dependencies it pulls in carry their own terms, which is a routine part of any Go dependency review.

The repository is not archived and the last push was on 2026-10-13. Releases moved from v0.33.0 on 2026-08-05 to v0.34.0 on 2026-08-24 and v0.35.0 on 2026-10-05, so roughly one release a month over that window, on a project whose own version number is still below one. That cadence matters for planning: expect to consume minor releases often, and expect each one to be a chance for the CRDs to shift.

Given that, the sensible first deployment is a namespace you can afford to rebuild. Install the chart, let it watch a non-critical workload, inspect the CRDs the operator writes, and build your integration against what you actually find there rather than against the report names in the README.

Editorial conclusion

Adopt trivy-operator if you run Kubernetes and want scan findings to live in the same API as the workloads they describe, since reports arrive as CRDs that RBAC, kubectl, and policy tooling can address directly. Do not adopt it if you need a stable contract, because the project describes itself as incubating and warns that APIs and CRDs may change. Verify first which chart version you install and which release tag it corresponds to, since the README's Helm examples pin chart version 0.37.0 while the latest listed release is v0.35.0.

Frequently asked questions

Official sources

1. aquasecurity/trivy-operator on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases