We run the same scanner it does.

What Trivy Operator is

Aqua's operator runs Trivy continuously inside the cluster and writes what it finds back into the cluster as custom resources: a VulnerabilityReport per workload, plus configuration audits, RBAC assessments, exposed-secret checks and SBOMs. It is free, Apache-2.0, widely deployed, and in several respects it looks wider than we do — we do not audit RBAC, we do not hunt for secrets in manifests, and we do not benchmark your nodes.

If your question is "what is wrong in this cluster", it is an excellent answer, and it costs nothing to find out.

Reports do not stop pods

A VulnerabilityReport is a record, not a gate. The operator does not register an admission webhook and does not refuse a deployment, by design: the documented way to enforce anything is to put a second tool in front — a policy engine reading those reports, or a webhook you write — and to accept the race that comes with it. The report describes a pod that is already running.

Attestkeep starts at the other end. Admission looks up a verdict that already exists for that image digest and answers in the same request; it never waits for a scan, and a pod whose image has never been scanned is a case the policy decides rather than a gap. The scan then keeps running behind it: the vulnerability database refreshes every six hours, every image is rescanned daily, and a new critical finding on something already admitted raises a notification and can open a ticket in your own GitHub, GitLab or Jira.

The second difference is what survives. Reports live as cluster resources and change as the cluster changes; when the pod goes, its report goes. Attestkeep writes verdicts to a PostgreSQL you control, under the hash of the policy they were evaluated against, and that history is what a period report is later built from.

Two different compliance reports

Both products have something called a compliance report and they answer different questions. Trivy Operator's ClusterComplianceReport covers the CIS Kubernetes Benchmark, the NSA hardening guidance and the Pod Security Standards: is this cluster configured the way a hardening guide says it should be.

Ours is not about configuration. It is a report over a period — what admission saw, what it admitted, what it refused and why — mapped onto thirteen regulations and control sets with 293 clauses, each quoted by citation, each marked met, partial, gap or outside scope. The fourth status is the point: a container operator can evidence perhaps a third of NIS2 Article 21, and a report that quietly maps the other two thirds onto its own feature list is worse than no report. The package is signed inside your cluster and your auditor can verify it without us.

Which one you need

Trivy Operator alone is enough when you want visibility and you are content to act on it by hand, or when hardening the cluster's own configuration is the work in front of you. It is free and it is good at that.

Attestkeep is for when a finding has to change what the cluster does — and when someone will later ask you to prove that it did. If both matter, the two are not mutually exclusive: keep the operator for RBAC and node benchmarks, and let admission be the thing that holds the line. Community Edition is free forever, so the comparison can happen on your cluster rather than on this page.