viral-ngs: Skill for Claude Code

Container Vulnerability Management

Guidance for scanning, triaging, and mitigating container image vulnerabilities in the viral-ngs Docker image hierarchy.

Scanning

Container images are scanned for vulnerabilities using Trivy:

PR/Push Scans (docker.yml)

• Runs on every PR/push after image build
• SARIF scan: CRITICAL/HIGH, fixable-only → uploads to GitHub Security tab
• JSON scan: CRITICAL/HIGH, fixable-only, exit-code: 1 → gates CI (fails if CVEs found)
• Both apply .trivyignore.yaml and .trivy-ignore-policy.rego

Scheduled Scans (container-scan.yml)

• Runs daily at 09:00 UTC on published main-mega-amd64 image
• SARIF scan: CRITICAL/HIGH, fixable-only → uploads to GitHub Security tab
• JSON scan: CRITICAL/HIGH/MEDIUM, all vulnerabilities (fixable + non-fixable), exit-code: 0 → uploaded as artifact for comprehensive debugging and Claude analysis
• When new fixable HIGH/CRITICAL CVEs are detected (i.e. IDs that no open or closed GH issue title names, directly or by a CVE/GHSA alias — .github/scripts/cve_pipeline.py new-ids), the workflow invokes Claude Sonnet 5.5 on Vertex AI to triage each one and files a GitHub issue per CVE (labels: security, cve)
• Auto-fix PR (cve-fix-pr job): after new issues are filed, Claude assesses all currently-open cve issues and either opens a single cve-fix + security PR — only if every open issue meets the moderate confidence bar (version-floor bump, precedent-mirroring Dockerfile mitigation, or precedent-mirroring .trivyignore.yaml entry; all-or-nothing) — or uploads a SKIPPED.md decision-log artifact. The PR is authored with a GitHub App token so it triggers the required CI checks. Its title, which is what release notes list, names the advisories it closes: the agent writes TITLE.txt, and cve_pipeline.py pr-title uses it only if it is plain text naming every closed advisory, otherwise it lists the closed issues' IDs grouped by package.
• Recovery / manual re-run: the auto-fix job only fires when the scan finds a new CVE, so once an issue is filed the CVE is no longer "new" and a failed or skipped fix run will not retry on its own. To re-run it on demand against all currently-open cve issues, dispatch manually: gh workflow run container-scan.yml -f force_fix_pr=true
• Conda availability probe: both Claude steps are preceded by .github/scripts/probe-conda-availability.py, which queries the conda-forge and bioconda APIs and writes .cve-fix-context/conda-availability.json. Per affected package it reports whether the Trivy FixedVersion exists on a channel, whether it is built for both linux-64 and linux-aarch64 (or is noarch), whether a requirements pin can fix the finding at all (fix_shape — an Ubuntu os-package or a bundled-jar cannot), and which other pinned packages carry a constraint that would exclude the fix version (constrained_by, e.g. pyopenssl<50 capping cryptography). Uploaded as a workflow artifact. Before this existed the agents had no network tool at all and skipped every version-floor bump as unverifiable — the primary category the pipeline was built for.
• CI verifies ARM64, so the agent does not have to: docker.yml builds all six tiers for both amd64 and native arm64 on every PR and re-scans each with Trivy, so a solver conflict from a floor bump fails required checks before merge. The auto-fix prompt says so explicitly and instructs the agent to reserve SKIP for "I cannot determine what the fix is", not "I cannot prove the fix works". Unproven solvability used to be the standard reason for skipping.
• Steering the bot via issue comments: maintainer comments on a cve issue are passed to the auto-fix agent and outrank the machine-generated issue body — use them to specify or amend a fix. Comments are hard-filtered to OWNER/MEMBER/COLLABORATOR in the workflow's jq, not in the prompt: this is a public repo, so an unfiltered comments array would be an untrusted-instruction channel into an agent that edits files and opens PRs.
• Agent guardrails: each agent runs in a job of its own (triage, cve-fix-pr) whose GITHUB_TOKEN is read-only. Writes happen in jobs no agent ran in: scan uploads SARIF, file-issues files the triage reports (only for the IDs it asked about), and cve-fix-pr-open applies the auto-fix agent's patch to a fresh checkout and is the only job holding the GitHub App token. That split matters because claude-code-action exports its github_token into the agent's environment, and an agent with Write has to be assumed able to run code in its job (git grep -O<cmd> is on its allowlist; .git/config it writes is obeyed by any later git command). cve-fix-pr-open treats the patch as untrusted: it must stay inside the path allowlist (docker/requirements/*.txt, docker/Dockerfile.*, .trivyignore.yaml), change only the text content of regular files (no binary content, symlinks, modes or renames), and pass gitleaks along with the PR body and title. It checks out github.sha itself rather than taking a commit from the agent's job. The auto-fix agent has domain-scoped WebFetch (no WebSearch, since its output is committed); the triage agent gets WebSearch too.
• The Vertex/WIF infra used here is documented in .agents/skills/claude-on-vertex-ci/SKILL.md