# Scan for Security Vulnerabilities

Source: https://docs.ops0.com/docs/how-to/scan-security-vulnerabilities

Run cloud infrastructure security scans with Discovery and container image scans on Kubernetes clusters — all in one place, without running separate tools.

---

## Scenario

Your security team needs a monthly vulnerability report covering both your cloud infrastructure (open security groups, public S3 buckets, unencrypted RDS instances) and your Kubernetes container images (known CVEs). You want this in one place without running separate tools.

---

## Two Scanning Surfaces

| Surface | Tool | What It Finds |
|---------|------|---------------|
| Cloud infrastructure | Nuclei (via Discovery) | Misconfigurations, open ports, public access, unencrypted resources |
| Kubernetes images | Trivy (via K8s integration) | CVEs in OS packages and app dependencies |

---

## Part 1: Cloud Infrastructure Security Scan

### Prerequisites

- Cloud integration configured with read permissions

- At least one completed discovery session (or ready to run a new one)

### Run the Scan

1. Go to **Discovery** → **New Scan** (or open a recent completed session)

2. Run the scan for your target environment

3. When the scan completes, click on the session → **Security** tab

4. The security scan runs automatically — wait 2–3 minutes for results

5. The Security tab shows: Risk Grade (A–F), finding counts by severity, and the full findings list

### Reading the Risk Grade

| Grade | Meaning | Action |
|-------|---------|--------|
| **A / B** | Low risk, minor issues only | Monitor; no urgent action needed |
| **C / D** | Significant findings present | Schedule remediation this sprint |
| **F** | Critical issues found | Remediate immediately |

### Example Finding Details

| Finding | Resource | Severity | Remediation |
|---------|----------|----------|-------------|
| SSH open to 0.0.0.0/0 | sg-0abc123 (web-sg) | Critical | Restrict CIDR to known IPs |
| S3 bucket public read | my-app-assets | High | Enable Block Public Access |
| RDS not encrypted | prod-db | High | Enable encryption (requires snapshot restore) |
| ALB HTTP not redirecting to HTTPS | prod-alb | Medium | Add HTTPS redirect rule |
| Missing resource tags | 12 resources | Low | Add Environment and Owner tags |

### Remediate a Finding

1. Click the finding → read the description and recommended fix

2. If managed by IaC: update your Terraform code, run Plan, verify the change, then Apply

3. If unmanaged: fix in the cloud console directly

4. Run a new scan and compare with the previous — the finding should be gone from the Security tab

**Fixing in the console doesn't update automatically**

The Security tab reads from the latest scan data. After fixing a resource in the cloud console, you must run a new discovery scan to confirm the finding is resolved.

---

## Part 2: Kubernetes Image Vulnerability Scan

### Prerequisites

- Kubernetes cluster connected to ops0

- Cluster deploy permissions (for Trivy Operator installation)

### Install Trivy and Run the First Scan

1. Go to **Kubernetes** → [your cluster] → **Security** tab

2. Click **Install Trivy** — ops0 deploys Trivy Operator to the `trivy-system` namespace

3. The first scan starts automatically and takes 5–10 minutes

4. The Security tab shows: total CVEs by severity, images scanned count, and risk grade

### Viewing Image Vulnerabilities

- Click **Images view** → shows each running image with CVE counts by severity
- Click any image → see the full CVE list with CVE ID, affected package, installed version, and fixed version

### Remediate a CVE

1. Note the affected package and the fixed version shown in the report

2. Update your Dockerfile or base image — e.g. `FROM node:20-alpine` instead of `FROM node:18-alpine`

3. Rebuild and push the image to your container registry

4. Redeploy the workload: **Kubernetes** → [cluster] → **Deployments** → trigger rollout

5. Trivy re-scans the new image automatically — the CVE disappears from the report

---

## Part 3: Create a Monthly Security Report

For a regular security posture review across both surfaces:

1. Schedule a monthly discovery scan: **Discovery** → **Schedules** → **New** → 1st of each month → Save

2. After each scheduled scan: session → **Security** tab → **Export** → CSV

3. For Kubernetes: **Kubernetes** → [cluster] → **Security** → **Export Report** → CSV

4. Combine both CSVs into your monthly security posture report

---

## Verification

Confirm both scanning surfaces are working correctly:

- Discovery session Security tab shows Risk Grade and finding counts by severity
- Kubernetes Security tab shows images scanned count and CVE totals
- After remediation: re-scan shows the finding resolved or the CVE gone from the report

---

## Troubleshooting

Security tab shows "Scan pending"

The security scan takes 2–5 minutes after discovery completes. Refresh the page and wait for the status to update.

Trivy shows 0 images scanned

Verify the Trivy Operator pod is running: **Kubernetes** → [cluster] → **Workloads** → filter namespace `trivy-system`. If the pod is in CrashLoopBackOff, check that the cluster has sufficient CPU and memory resources.

Critical finding still showing after fix

The Security tab reads from the latest scan data — fixing in the cloud console does not update automatically. Run a new discovery scan to confirm the finding is resolved.

---

## Next Steps

[Enforce Security Policies → Block non-compliant deployments automatically with OPA policies](https://docs.ops0.com/docs/how-to/enforce-security-policies)
[Detect Infrastructure Drift → Get alerted when resources change outside of ops0](https://docs.ops0.com/docs/how-to/detect-drift)