OS Vulnerability Fix Skill
Description
This skill remediates OS and base-image vulnerabilities in Docker-hosted applications.
It analyzes provided scan findings, evaluates safer base-image candidates, applies Dockerfile or image-tag updates when safe, rebuilds and rescans, and produces an OS-focused remediation report.
Application dependency remediation is out of scope for this skill and must be documented as out-of-scope in the report.
When to Use
Use this skill when the user asks to:
- Fix OS-level CVEs in container images.
- Reduce base-image vulnerabilities.
- Compare current and candidate base images.
- Update Docker FROM images to safer compatible tags.
- Produce an OS vulnerability remediation report.
Inputs
Expected inputs may include:
- Vulnerability scan report or CVE list.
- Dockerfile.
- Docker Compose files.
- Kubernetes manifests.
- Existing scanner output (Docker Scout, Trivy, Grype, Snyk, or similar).
- Build and runtime validation instructions.
Outputs
This skill produces:
- Applied OS/base-image fixes where safe and feasible.
- Updated Dockerfile or container image references.
- Baseline and final scan comparison evidence.
- Validation results.
- An OS vulnerability remediation report.
Scope Rules
- In scope: Linux distro packages, system libraries, shell utilities, and base-image layer CVEs.
- Out of scope: application and language-ecosystem dependency upgrades.
- If non-OS findings are present, list them as out-of-scope follow-up items.
Core Principle
Use Docker Hub API for candidate discovery and Docker Scout (or approved scanner) for vulnerability evidence.
Do not treat Docker Hub tag metadata as proof that CVEs are fixed. A CVE is only considered fixed after final scan evidence confirms absence or a non-vulnerable installed package version.
Process
Step 1: Classify and Baseline
Classify each finding as
,
, or
.
Scan the current image to establish a baseline:
bash
TS=$(date +%Y%m%d%H%M%S)
docker build -t app-current:scan-$TS .
docker scout cves --only-base --format sarif --output scout-current.sarif.json app-current:scan-$TS
docker scout recommendations app-current:scan-$TS
Registry variant: use
instead of a local tag.
Step 2: Evaluate and Select Candidate
Inspect Dockerfile FROM lines, discover compatible tags with Docker Hub API, scan candidates, and select the safest compatible base image.
bash
# Discover tags (adjust namespace/repo/prefix for the actual base image)
curl -s "https://hub.docker.com/v2/namespaces/library/repositories/eclipse-temurin/tags?page_size=100" \
| jq -r '.results[] | select(.name | startswith("17-jre")) | [.name, .last_updated] | @tsv'
# Scan candidate
docker scout cves --only-base --platform linux/amd64 registry://eclipse-temurin:17-jre-jammy
docker scout recommendations registry://eclipse-temurin:17-jre-jammy
Prefer: same runtime version, fewer critical/high CVEs, official/trusted publisher, supported OS, no new critical CVEs introduced.
Avoid:
, EOL images, untrusted publishers, major runtime jumps without evidence.
Step 3: Apply Fix, Rebuild, and Rescan
Update the Dockerfile FROM line, rebuild, and run the final scan:
bash
TS=$(date +%Y%m%d%H%M%S)
docker build -t app-os-fixed:scan-$TS .
docker scout cves --only-base --format sarif --output scout-final.sarif.json app-os-fixed:scan-$TS
Assign each original OS finding one status based on baseline vs final comparison:
| Condition | Status |
|---|
| Absent in final scan | fixed |
| Present, fixed version exists | fix_available_not_applied |
| Present, no fixed version | no_fix_available |
| Remains after fix attempt | still_vulnerable |
| Appears only after fix | newly_introduced |
| Ambiguous evidence | manual_review_required |
Step 4: Generate Report
Produce an OS-focused remediation report using the template in references.
Report Template
Use os-vulnerability-remediation-report-template.md.
Safety Requirements
This skill must not:
- Disable or suppress scanner findings without evidence.
- Use latest blindly.
- Upgrade to unsupported or EOL base images.
- Claim a CVE is fixed without scan/version evidence.
- Modify dependency manifests or lockfiles for application package upgrades.
- Modify unrelated application logic unless required for runtime compatibility.
Completion Criteria
Task is complete when:
- Safe OS/base-image fixes are applied where feasible.
- Docker image is rebuilt.
- Final scanner evidence is captured, or inability is documented.
- Report includes fixed, remaining, no-fix, manual-review, and newly introduced OS findings.
- Out-of-scope non-OS findings are explicitly listed for follow-up.