ops0 integrates with Trivy to scan container images running in your cluster for known vulnerabilities (CVEs), misconfigurations, and exposed secrets. Get a continuous security posture view without leaving the ops0 dashboard.
Scan every container image running in the cluster for known CVEs.
Identify RBAC over-permissions, missing network policies, and insecure pod specs.
Surface secrets exposed in environment variables and ConfigMaps.
Trivy covers three categories of risk in your cluster:
Container Images — Every image currently running across all namespaces is scanned against the OSS vulnerability database. Both OS packages (Alpine, Debian, Ubuntu, etc.) and language-level packages (npm, pip, Maven, Go modules) are checked.
Kubernetes Resource Configurations — Resource manifests are checked for common misconfigurations: overly permissive RBAC roles, pods running as root, missing resource limits, absent network policies, and pod security context issues.
Exposed Secrets — Environment variables, ConfigMaps, and pod specs are scanned for hard-coded credentials, API tokens, and private keys.
ops0 deploys the Trivy Operator into your cluster with one click. The operator runs continuously and re-scans workloads as they change.
Navigate to your cluster in ops0 and click the Security tab.
ops0 deploys the Trivy Operator into the trivy-system namespace. This requires deploy permissions on the cluster.
Trivy automatically begins scanning all running images. First scan results appear within 5–10 minutes depending on the number of images in the cluster.
The Security tab populates with a risk grade, total vulnerability counts by severity, and a per-image breakdown.
Click Scan Now on the Security tab to trigger an immediate re-scan of all images and configurations. This is useful after deploying updated images or applying configuration changes that you want reflected immediately.
Scans also run automatically whenever new workloads are deployed to the cluster.
CVEs are classified by CVSS score into five severity levels:
| Severity | CVSS Score | Action Required |
|---|---|---|
| Critical | 9.0–10.0 | Fix immediately — these represent exploitable, high-impact vulnerabilities |
| High | 7.0–8.9 | Fix within 7 days |
| Medium | 4.0–6.9 | Fix in the next sprint |
| Low | 0.1–3.9 | Fix when possible |
| Unknown | — | Investigate — severity data is not available for this CVE |
The Security tab surfaces three levels of detail:
Summary — Total vulnerability count broken down by severity, an overall risk grade (A through F), and the number of images scanned. Use this to track security posture over time.
Images View — A per-image table showing the image name, tag, registry, and CVE counts by severity. Sort by any column to prioritize the most vulnerable images.
| Column | Description |
|---|---|
| Image | Full image name including registry and tag |
| Critical | Number of critical CVEs in this image |
| High | Number of high CVEs in this image |
| Medium / Low | Combined count of medium and low CVEs |
| Last Scanned | Timestamp of the most recent scan |
Report View — A sortable, filterable table of every individual CVE found across all images.
| Column | Description |
|---|---|
| CVE ID | The CVE identifier — links to the NVD entry |
| Package | Affected OS or language package |
| Installed Version | Version currently in the image |
| Fixed Version | Version that resolves the CVE (if available) |
| Severity | Critical / High / Medium / Low / Unknown |
| Image | Which image contains this CVE |
For each CVE in the report, the Fixed Version column shows which package version resolves the issue. The general remediation workflow is:
FROM base image or package version in your DockerfileFor base image CVEs, upgrading to a newer minor or patch release of the base image (e.g. node:20.15 → node:20.16) typically resolves a large number of OS-level findings in one change.
Use the filter bar in the Security tab to narrow the view:
Download the full vulnerability report as CSV or JSON from the Export button in the top-right corner of the Report view. The export includes all CVEs matching the current filters.
Trivy scans images at the OS and application package layer. It does not scan running processes or network traffic at runtime. For runtime threat detection — such as unexpected syscalls or lateral movement — consider a dedicated runtime security tool alongside Trivy.
In addition to Trivy vulnerability scanning, ops0 supports deploying Kyverno policies to your clusters for admission-time enforcement. Kyverno runs inside the cluster and validates or mutates resources as they are applied.
ops0 can install Kyverno into your cluster from the Security tab:
Navigate to your cluster and click Security.
ops0 deploys the Kyverno controller into your cluster using Helm.
Status moves from Installing → Installed. This typically takes 1–2 minutes.
Kyverno policies are created in Policies → Kubernetes Policies and then mapped to specific clusters. See Creating Policies for YAML examples and the policy editor workflow.
Once a Kyverno policy is mapped to a cluster, ops0 deploys it to the cluster's kyverno namespace automatically. Kyverno then enforces or audits the policy at Kubernetes admission time.
| Mode | Behavior |
|---|---|
| Enforce | Kubernetes rejects resources that violate the policy |
| Audit | Violations are recorded but resources are not blocked |
Set the mode in the Kyverno policy YAML via spec.validationFailureAction:
spec:
validationFailureAction: Enforce # or Audit
Navigate to Security → Kyverno Policies on a cluster to see all deployed policies and their status:
| Column | Description |
|---|---|
| Name | Policy name |
| Mode | Enforce or Audit |
| Status | Ready / Not Ready |
| Rules | Number of rules in the policy |
| Version | Kyverno policy version |
The Policy Diagnostics panel shows Kyverno health on the cluster:
No results after installing Trivy
Confirm the Trivy Operator pods are running in the trivy-system namespace:
kubectl get pods -n trivy-system
If pods are not running, check for image pull errors or resource quota issues with kubectl describe pod -n trivy-system <pod-name>.
Scan is stuck in progress
Large images or registries with rate limits can slow scan completion. Check the VulnerabilityReport custom resources in the target namespace:
kubectl get vulnerabilityreports -n <namespace>
Private registry images are not scanned
The Trivy Operator needs image pull credentials to access private registries. Create an imagePullSecret in the trivy-system namespace with credentials for your registry.