cve-remediation

name: cve-remediation description: Remediate specific CVEs across the fleet — given a cve-report.py or CVE ID, determine which hosts need what fixes and execute them without re-scanning anything. triggers: - user provides a CVE ID for remediation - user provides cve-report.py output (--gemini mode) and says "fix these" - user says "fix CVE-XXXX" or "remediate" - task involves upgrading packages, rebuilding container images, or updating Go toolchains related_skills: - cve-inventory-pipeline

CVE Remediation

This skill covers fixing known CVEs across the fleet. The scanning pipeline (cve-inventory-pipeline skill) already handles detection — never re-scan, re-SBOM, or re-run grype/syft. The findings are ground truth.

The Fleet

Input Formats

The user will provide remediation context in one of these forms:

1. CVE ID only

"fix CVE-2026-27143" — Run cve-report.py first to get the full picture:

cd <cve_inventory_repo> && python3 scripts/cve-report.py CVE-2026-27143 --gemini

2. cve-report.py output (--gemini mode preferred)

The structured report tells you exactly which hosts, which packages, current → fix versions, and whether fixes are available. This is the canonical input format.

3. --list or --top N output

Use to pick which CVE to tackle first. Action priority score = severity × host count × fixable bonus.

Fix Patterns by Finding Type

🏠 Host-level packages (apt)

These show image: "" or (host packages) in the report. Fix on the VM directly.

# Fix a specific package
ssh <host> "sudo apt update && sudo apt install --only-upgrade -y <package>=<version>"

# Fix without pinning version (let apt figure it out)
ssh <host> "sudo apt update && sudo apt upgrade -y <package>"

# If the package name includes version info (e.g. "libssl1.1"),
# just the base package name usually works: "sudo apt install libssl"

Pitfall — version pinning: Some CVEs show multiple fix versions (e.g. 1.23.8, 1.24.2). Pick the highest. If apt can't find that exact version, try apt list --upgradable <package> to see what's available.

Pitfall — Go stdlib on hosts: Go stdlib CVEs show as stdlib goX.Y.Z on host SBOMs. These come from installed Go toolchains. Fix by removing old Go versions or upgrading the Go package.

📦 Container images

These show a container image name in the report. Fix by updating the image tag.

# For MicroK8s clusters — edit the deployment image tag and let k8s roll it out
microk8s kubectl set image deployment/<name> <container>=<new-image>:<tag> -n <namespace>
# or edit the manifest and kubectl apply

# For containers managed outside k8s (docker-compose, etc.)
# Update the tag in the compose file and docker compose up -d

Pitfall — image tag pinning: Most images use pinned tags (:v1.2.3) not :latest. You need to know the new tag. Check the image registry or update to a patch version.

🦫 Go stdlib (special case)

Go stdlib CVEs (CVE-2026-27143, CVE-2025-22871, CVE-2026-39820, etc.) are the most common Critical CVEs in the fleet. The finding shows stdlib goX.Y.Z → 1.25.10, 1.26.3.

On VMs: The Go toolchain package needs upgrading:

ssh <host> "sudo apt update && sudo apt install --only-upgrade -y golang-go"
# Or for specific Go version packages
ssh <host> "sudo snap install go --classic"  # if installed via snap
ssh <host> "sudo rm -rf /usr/local/go && wget https://go.dev/dl/go1.26.3.linux-amd64.tar.gz && sudo tar -C /usr/local -xzf go1.26.3.linux-amd64.tar.gz"

In container images: The Go version used during the image build is baked in. Rebuild the image with a newer Go toolchain and redeploy.

In Go projects (go binaries): Any Go binary compiled with an old Go version embeds the old stdlib. Recompile with newer Go.

📚 Go modules (google.golang.org/grpc, etc.)

Go library CVEs like GHSA-p77j-4mvh-x3m3 (grpc) need the go.mod updated and the project rebuilt:

# In the project directory
go get google.golang.org/grpc@v1.79.3
go mod tidy
go build ./...

What NOT To Do (Guardrails)

🚫 Do NOT run syft, grype, or osv-scanner. The pipeline already does this. The findings.json is the source of truth.

🚫 Do NOT generate new SBOMs. The SBOMs in the inventory directory are the pipeline's input — don't touch them.

🚫 Do NOT modify findings.json. It's managed by the pipeline's merge/diff logic.

🚫 Do NOT re-invent the pipeline. If you need fresh data, ask the user to trigger a pipeline run, or use cve-report.py from the existing findings.

Workflow

1. User provides CVE ID or report output
2. If CVE ID only → run python3 cve-report.py CVE-XXXX --gemini to get the full picture
3. Parse the report:
   - Identify which hosts have findings
   - Check if findings are host-level (apt) or container images
   - Note Go stdlib vs Go module vs regular packages
4. For each host:
   a. SSH in (or use k8s context for containers)
   b. Determine current state (apt list --upgradable, go version, etc.)
   c. Apply fixes per patterns above
   d. Verify fix (re-run apt list or equivalent)
5. Report back:
   - What was fixed on each host
   - Any findings that couldn't be fixed (no fix available, etc.)
   - Suggest running the pipeline to confirm resolution

Verification

After remediation, suggest running the pipeline (or checking the next scheduled cron run) to confirm CVEs transition to resolved.

The pipeline's state machine keys on (vuln_id, host, image, component, version) — if the component version changed, the old finding drops from the next scan and gets classified as resolved in the Discord alert.