# Vulnerability Scanning

Source: https://docs.ops0.com/docs/kubernetes/security

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.

- **Image Scanning**: Scan every container image running in the cluster for known CVEs.

- **Misconfiguration Detection**: Identify RBAC over-permissions, missing network policies, and insecure pod specs.

- **Secret Detection**: Surface secrets exposed in environment variables and ConfigMaps.

---

## What Gets Scanned

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.

---

## Installing Trivy

ops0 deploys the Trivy Operator into your cluster with one click. The operator runs continuously and re-scans workloads as they change.

### Open the Security Tab
Navigate to your cluster in ops0 and click the **Security** tab.

### Click Install Trivy
ops0 deploys the Trivy Operator into the `trivy-system` namespace. This requires deploy permissions on the cluster.

### Wait for the First Scan
Trivy automatically begins scanning all running images. First scan results appear within **5–10 minutes** depending on the number of images in the cluster.

### Review Results
The Security tab populates with a risk grade, total vulnerability counts by severity, and a per-image breakdown.

---

## Running a Manual Scan

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.

---

## Vulnerability Severity

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 |

---

## Viewing Results

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 |

---

## Remediation

For each CVE in the report, the **Fixed Version** column shows which package version resolves the issue. The general remediation workflow is:

1. Identify the CVE and affected package in the Report view
2. Update the relevant `FROM` base image or package version in your Dockerfile
3. Rebuild and push the updated image
4. Redeploy the workload — ops0 will trigger a new Trivy scan automatically

For 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.

---

## Filtering

Use the filter bar in the Security tab to narrow the view:

- **Severity** — Show only Critical, High, Medium, or Low findings
- **Namespace** — Limit to a specific namespace
- **Workload** — Filter to images used by a specific Deployment or StatefulSet
- **Image Name** — Search for a specific image or registry

---

## Exporting Results

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.

**Scan Coverage Limits**

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.

---

---

## Kyverno Policy Enforcement

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.

### Installing Kyverno

ops0 can install Kyverno into your cluster from the Security tab:

### Open Security tab
Navigate to your cluster and click **Security**.

### Click Install Kyverno
ops0 deploys the Kyverno controller into your cluster using Helm.

### Wait for installation
Status moves from **Installing** → **Installed**. This typically takes 1–2 minutes.

### Creating and Deploying Policies

Kyverno policies are created in **Policies → Kubernetes Policies** and then mapped to specific clusters. See [Creating Policies](https://docs.ops0.com/docs/policies/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.

### Enforcement Modes

| 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`:
```yaml
spec:
  validationFailureAction: Enforce  # or Audit
```

### Policy Status

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 |

### Diagnostics

The **Policy Diagnostics** panel shows Kyverno health on the cluster:
- Kyverno controller pod status
- Webhook registration status
- Per-policy status and any deployment errors

---

## Troubleshooting

**No results after installing Trivy**

Confirm the Trivy Operator pods are running in the `trivy-system` namespace:

```bash
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:

```bash
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.

---

## Related

- [Clusters](https://docs.ops0.com/docs/kubernetes/clusters): Connect and manage your Kubernetes clusters.

- [Workloads](https://docs.ops0.com/docs/kubernetes/workloads): Monitor Deployments, StatefulSets, and DaemonSets.

- [Cost Analysis](https://docs.ops0.com/docs/kubernetes/cost-analysis): Break down Kubernetes spending by namespace and workload.