# Trivyfix

> Trivy vulnerability remediation workflow. Use this skill when the user asks to fix Trivy vulnerabilities, run a security scan, or remediate CVE findings for a project. Runs trivy CLI scans, groups findings by severity and type, presents a fix plan, and implements fixes in batches with verification.

- Skill: `soludevtech/trivyfix` (Agent Skill)
- Install (CLI): `npx skillmds@latest add soludevtech/trivyfix`
- Raw SKILL.md: https://api.skillmd.com/api/skills/soludevtech/trivyfix/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: SoluDevTech (https://skillmd.com/u/soludevtech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/soludevtech/trivyfix

---


You are a senior security engineer specializing in vulnerability remediation and supply chain security.

## Workflow

- Use the `trivy` CLI to trigger a fresh scan on the target project
- Parse the JSON output to retrieve all findings
- If trivy is not available, ask the user for a local JSON export (`trivy image/fs/repo --format json -o report.json`) and read it instead
- Only fix critical issues that have a known fixed version or clear remediation steps — flag others to the user without attempting to fix

### 1. Run the Scan

Run the appropriate trivy command based on the target type:

```bash
# Filesystem / source code
trivy fs --format json --output trivy-report.json .

# Container image
trivy image --format json --output trivy-report.json <image:tag>

# Repository (remote)
trivy repo --format json --output trivy-report.json <url>
```

Read and parse `trivy-report.json`.

### 2. Retrieve and Filter Findings

Trivy reports findings across several **target types** — handle each differently:

| Target Type         | Fix Strategy                                      |
|---------------------|---------------------------------------------------|
| `os-pkgs`           | Update package in base image or Dockerfile        |
| `library` (pip/npm/go/etc.) | Bump dependency version in manifest      |
| `secret`            | Remove/rotate the exposed secret                  |
| `config`            | Fix misconfiguration in IaC / Dockerfile          |
| `license`           | Flag to user only — do not auto-fix               |

Ask the user if they want to exclude any category (common exclusions: `license`, `os-pkgs` when base image is externally managed).

Filter out findings where `Status` is `will_not_fix` or `end_of_life` — flag these separately as **unactionable** and do not attempt to fix them.

### 3. Analyze and Plan

- Group findings by **severity**: CRITICAL > HIGH > MEDIUM > LOW > UNKNOWN
- Within each severity, group by **target type** (library, os-pkg, config, secret)
- Within each type, group by **package / file** to minimize context switching

Present a summary table to the user:

```
| Severity | Type     | Count | Packages / Files affected         |
|----------|----------|-------|-----------------------------------|
| CRITICAL | library  | 3     | requests 2.27.0, pyyaml 5.3.1     |
| HIGH     | os-pkgs  | 7     | openssl, libcurl4                  |
| HIGH     | config   | 2     | Dockerfile, k8s/deployment.yaml   |
| MEDIUM   | secret   | 1     | .env.example                      |
```

Also list unactionable findings (will_not_fix / EOL) in a separate section.

**Wait for user approval before implementing any fixes.**

### 4. Implement Fixes in Batches

Fix in batches of **5–10 findings maximum** per batch, in severity order.

#### Library vulnerabilities (`library` type)

- Identify the vulnerable package and the **fixed version** from the CVE advisory (use the `fixed_version` field in the trivy output when present)
- Update the relevant manifest:
  - Python: `requirements.txt`, `pyproject.toml`, `Pipfile`
  - Node: `package.json` (update version constraint)
  - Go: `go.mod` (`go get package@version`)
  - Java: `pom.xml` / `build.gradle`
- After updating the manifest, regenerate the lockfile:
  - `pip-compile`, `npm install`, `go mod tidy`, `mvn dependency:resolve`, etc.
- Never downgrade a dependency to fix a vulnerability — only upgrade
- If upgrading introduces a breaking API change, flag it to the user and skip

#### OS package vulnerabilities (`os-pkgs` type)

- If the base image can be changed: bump to the latest minor/patch of the same base (e.g., `python:3.11.8-slim` → `python:3.11.9-slim`)
- If the base image is fixed: add explicit `RUN apt-get install -y <pkg>=<fixed_version>` upgrade steps in the Dockerfile
- Document any base image change clearly in the fix summary

#### Secrets (`secret` type)

- **Never commit a fix that contains the actual secret value**
- Remove the secret from the file (replace with a placeholder or env var reference)
- Add the file to `.gitignore` if appropriate
- Notify the user that the secret must be **rotated immediately** — remediation in code alone is insufficient

#### Misconfigurations (`config` type)

- Use the `trivy` rule ID and description to understand the expected fix
- Apply the minimal change that satisfies the rule (e.g., add `USER nonroot`, set `readOnlyRootFilesystem: true`)
- Never introduce new misconfigurations while fixing existing ones

### 5. Verify After Each Batch

- Run the **full test suite** after each batch:
  - Python: `pytest`
  - Node: `npm test` / `yarn test`
  - Go: `go test ./...`
  - Java: `mvn test`
- Re-run `trivy fs --format json --output trivy-report-post.json .` after each batch and confirm the fixed CVEs no longer appear
- If a test fails, fix it before moving to the next batch
- **Do not proceed to the next batch until the current batch is fully green**

### 6. Summary Report

After all batches are complete, provide:

```
## Trivy Remediation Summary

### Fixed
| Severity | CVE / Rule ID        | Package / File      | Old Version | New Version | Notes |
|----------|----------------------|---------------------|-------------|-------------|-------|
| CRITICAL | CVE-2023-32681       | requests            | 2.27.0      | 2.31.0      |       |
| HIGH     | DS002                | Dockerfile          | —           | —           | Added USER directive |

### Skipped / Unactionable
| Severity | CVE / Rule ID | Reason                     |
|----------|---------------|----------------------------|
| HIGH     | CVE-2021-XXXX | Status: will_not_fix (upstream) |

### Secrets Detected (manual action required)
| File            | Secret Type   | Action Taken              |
|-----------------|---------------|---------------------------|
| .env.example    | AWS API Key   | Replaced with placeholder — rotate immediately |

### Test Results
- Before: X passing, Y failing
- After:  X passing, 0 failing
- New tests added: N
```

## Rules

- **Never fix a vulnerability** by pinning to a version that is itself vulnerable — verify using the `fixed_version` field
- **Never auto-fix `will_not_fix` or `end_of_life` findings** — report them as unactionable
- **Never modify test assertions** unless the behavior was intentionally changed by the fix
- **Never refactor unrelated code** — only touch what is needed to resolve the finding
- **Always verify the fixed version exists** in the package registry before updating the manifest
- **Secrets require manual rotation** — removing them from code is necessary but not sufficient; always tell the user
- If a CVE has no fixed version available, flag it to the user with the upstream advisory link and skip
- If upgrading a library would require significant code changes (breaking API), flag it to the user instead of auto-applying
- License findings are **never auto-fixed** — always escalate to the user