remediation

name	remediation
description	Context-aware remediation plan (V2 endpoint) — registry fixes ranked by confidence, upstream commits, distribution patches, workarounds with effectiveness scores, CWE-specific defensive strategies, and per-package-manager verification commands. Use when you need a structured remediation playbook (not just a single fix), CWE guidance for related vulnerabilities, or per-ecosystem verify commands.
argument-hint	<vuln-id>
user-invocable	true
allowed-tools	Bash, Read, Glob, Grep, Edit, Write
model	sonnet
triggers	["remediation plan","how to remediate","remediation guidance"]
chain	["fix","verify-fix"]
outputBudget	medium
cooldown	per-session

Vulnetix Remediation Plan Skill

Use when

• You need a structured playbook with prioritized actions, not just "upgrade to X".
• CWE-specific guidance is needed (e.g. CWE-89 SQL injection across multiple packages).
• Per-package-manager verification commands are required (npm audit fix, pip-audit, go mod tidy --no-deps-check, cargo audit).
• Workaround effectiveness scores matter — partial mitigations need to be weighed against deferral.
• Producing a remediation report for stakeholders who want the "what + why + how + verify" breakdown.

Don't use for

• Just applying a single fix — use /vulnetix:fix.
• Verifying the fix worked — use /vulnetix:verify-fix.
• Detection-only mitigation — use /vulnetix:detection-rules.

Conventions

This skill follows _lib/contract.md: the Vulnetix CLI is auto-installed by hooks, .vulnetix/capabilities.yaml is always present, every vulnetix vdb call is piped through a verified jq filter from _lib/jq/, independent calls run in parallel as concurrent Bash tool calls, and trailing follow-ups are limited to one line. See the contract for output style, memory write rules, and cooldowns.

This skill generates a comprehensive, context-aware remediation plan for a specific vulnerability using the VDB V2 remediation API. It auto-detects your repository's ecosystem, package manager, installed versions, container images, and OS to provide targeted fix guidance including registry upgrades, source patches, distribution advisories, workarounds, CWE-specific remediation strategies, and verification commands.

How this differs from /vulnetix:fix: The existing /vulnetix:fix skill fetches V1 fix data and proposes manual manifest edits. This skill uses the V2 remediation plan endpoint which provides context-aware guidance (ecosystem, version, OS, container), CWE remediation strategies, CrowdSec threat intelligence (live exploitation data), workaround effectiveness scoring, SSVC decision support, and verification commands per package manager.

Vulnerability Memory (.vulnetix/memory.yaml)

This skill reads and updates the .vulnetix/memory.yaml file in the repository root. This file is shared with /vulnetix:fix, /vulnetix:exploits, /vulnetix:package-search, /vulnetix:vuln, and /vulnetix:exploits-search.

Schema

The canonical schema is defined in /vulnetix:fix. This skill updates base fields and appends remediation plan events to the history log.

Reading Prior State

At the start of every invocation:

1. Use Glob to check if .vulnetix/memory.yaml exists in the repo root
2. If it exists, use Read to load it and check for the vuln ID or aliases
3. Use Glob for .vulnetix/scans/*.cdx.json -- cross-reference for component data
4. If a prior entry exists, display:

   Previously seen: <vulnId> -- <developer-friendly status> (as of <date>)
   Priority: <P1/P2/P3/P4> (<score>) (if cwss data exists)
   Last decision: <developer-friendly decision> -- "<reason>"
   

Writing Updated State

After completing the remediation plan (Step 7):

1. If no entry exists, create one with status: under_investigation, discovery.source: user
2. If an entry exists, update severity, safe_harbour, and versions.fixed_in from the remediation plan data. Merge aliases.
3. Do NOT change status or decision unless the user explicitly makes a decision during the conversation
4. Append to history: event: remediation-plan, detail: summary of fix options found (registry fixes, source fixes, workarounds, distribution patches)
5. Confirm to the user

VEX Status Mapping

• not_affected --> "Not affected"
• affected --> "Vulnerable"
• fixed --> "Fixed"
• under_investigation --> "Investigating"

Dependabot Integration

When gh CLI is available (check with gh auth status 2>/dev/null), query Dependabot alerts for the vuln ID to cross-reference with the remediation plan.

1. Query alerts matching this vuln ID
2. If a Dependabot PR exists, note it in the output: "Dependabot PR #N proposes this upgrade -- consider reviewing and merging it"
3. Update the dependabot section in the memory entry

Workflow

Step 0: Ensure Vulnetix CLI is Available

Before running any vulnetix command, verify the CLI is callable:

command -v vulnetix &>/dev/null && vulnetix --version

If vulnetix is not found, install it automatically using this priority:

1. Homebrew (if brew exists): brew install vulnetix/tap/vulnetix
2. Scoop (Windows, if scoop exists): scoop bucket add vulnetix https://github.com/Vulnetix/scoop-bucket && scoop install vulnetix
3. Nix (if NixOS or nix exists): nix profile install github:Vulnetix/cli
4. GitHub releases (if curl/wget exist): Download the correct binary for the OS/arch from https://github.com/Vulnetix/cli/releases/latest, extract to ~/.local/bin/, and chmod +x
5. Go install (if go exists): go install github.com/Vulnetix/cli/cmd/vulnetix@latest

After each install attempt, verify with command -v vulnetix. If all methods fail, inform the user and abort. Do not proceed without the CLI.

Step 1: Load Memory and Detect Repository Context

1. Load .vulnetix/memory.yaml as described above
2. Use Glob to detect manifest files and determine:
   • Ecosystem -- npm, pypi, maven, go, cargo, rubygems, packagist
   • Package manager -- npm, yarn, pnpm, pip, poetry, uv, cargo, go, maven, gradle, bundler, composer
3. If the vuln ID is already in memory with a package field, use that package name
4. If not, run a quick lookup to get affected products:

   vulnetix vdb vuln "$ARGUMENTS" -o json
   

   Extract affected package names and ecosystems from the response.
5. For each affected package found in the repo, detect the installed version using the priority chain: lockfile --> manifest --> installed artifacts --> unknown

Step 2: Auto-Populate Context Flags

Build the CLI flags automatically from repository state:

Flag	Source	How to detect
--ecosystem	Manifest files	From Step 1 ecosystem detection
--package-name	VDB response or memory	Affected package name matching repo
--current-version	Lockfile/manifest	Installed version from Step 1
--package-manager	Manifest file type	package-lock.json --> npm, yarn.lock --> yarn, poetry.lock --> pip/poetry, etc.
--purl	Constructed	If ecosystem + name + version are known, construct pkg:<eco>/<name>@<version>
--container-image	Containerfile/Dockerfile	Use Glob for Containerfile, Dockerfile, *.dockerfile. If found, Read and extract FROM image reference (e.g., node:18-alpine)
--os	OS detection	Check for /etc/os-release or infer from container base image
--vendor	VDB response	From affected products vendor field
--product	VDB response	From affected products product field

Always set:

• --include-guidance -- includes CWE-specific remediation strategies
• --include-verification-steps -- includes per-package-manager verification commands

If no package context can be determined (no manifests, no memory), run the command without package-specific flags -- the API will still return general remediation guidance.

Step 3: Execute Remediation Plan Query

vulnetix vdb remediation plan "$ARGUMENTS" -V v2 --include-guidance --include-verification-steps -o json [context flags] | jq -f "${CLAUDE_PLUGIN_ROOT}/skills/_lib/jq/remediation.jq"

CLI Reference (from vulnetix vdb remediation plan docs):

Flag	Type	Description
--ecosystem	string	Package ecosystem (npm, pypi, maven, go, cargo, etc.)
--package-name	string	Package name
--current-version	string	Currently installed version (enables version-specific guidance)
--package-manager	string	Package manager (npm, pip, cargo, maven, etc.)
--purl	string	Package URL (overrides ecosystem + package-name)
--container-image	string	Container image reference (e.g., node:18-alpine)
--os	string	OS identifier (e.g., ubuntu:22.04, debian-11)
--vendor	string	Vendor name for CPE matching
--product	string	Product name for CPE matching
--registry	string	Registry filter (npm, pypi, maven-central)
--include-guidance	bool	Include CWE-specific markdown guidance
--include-verification-steps	bool	Include verification commands per package manager
-V	string	API version -- must be v2
-o, --output	string	Output format: json or pretty

Examples:

# Basic remediation plan
vulnetix vdb remediation plan CVE-2021-44228 -V v2 --include-guidance --include-verification-steps -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/skills/_lib/jq/remediation.jq"

# With full package context
vulnetix vdb remediation plan CVE-2021-44228 -V v2 \
  --ecosystem maven --package-name log4j-core --current-version 2.14.1 \
  --package-manager maven --include-guidance --include-verification-steps -o json

# Using PURL
vulnetix vdb remediation plan CVE-2021-44228 -V v2 \
  --purl "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1" \
  --include-guidance --include-verification-steps -o json

# With container context
vulnetix vdb remediation plan CVE-2024-XXXXX -V v2 \
  --ecosystem npm --package-name express --current-version 4.17.1 \
  --container-image "node:18-alpine" --include-guidance --include-verification-steps -o json

Response structure (from V2 OAS):

The response includes:

• cveId, state, title, aliases, description
• descriptions[] -- multi-source descriptions with language and source attribution
• crowdSecSummary -- live threat intelligence:
  • totalSightings, uniqueIPs, isActive
  • firstSeen, lastSeen
  • topSourceCountries, topTargetCountries
  • mitreTechniques, behaviors
• cvssDetails -- parsed CVSS vector components (attackVector, attackComplexity, privilegesRequired, userInteraction, scope, impact metrics)
• agent_prompt -- AI-optimized remediation context string
• Registry fixes, source fixes, distribution patches, workarounds, CWE guidance, verification steps (context-dependent based on flags provided)

Step 4: Present the Remediation Plan

Render a structured remediation report with the following sections:

Vulnerability Summary:

<CVE ID> -- <title>
<description -- first 2-3 sentences>
Severity: <CVSS score> (<level>)  |  EPSS: <score>

Threat Activity (from CrowdSec data, if present):

Live Exploitation: <Active/Inactive>
Sightings: <totalSightings> from <uniqueIPs> unique IPs
Last seen: <lastSeen>
Source countries: <top 3>
MITRE techniques: <techniques in developer language>

If no CrowdSec data, skip this section.

Registry Fixes (version upgrades per ecosystem):

Ecosystem	Package	Current	Fix Version	Verified	Confidence	Registry
maven	log4j-core	2.14.1	2.17.1	Yes	High	Maven Central

For each fix, report Safe Harbour confidence:

• High (> 0.90): patch-level bump, official registry release
• Reasonable (0.35-0.90): minor version bump, backward-compatible
• Low (< 0.35): major version bump, significant API changes

Source Fixes (upstream commits/PRs, if available):

Upstream fix: <commit URL>
  SHA: <sha>
  Author: <author>
  Message: <commit message>
  Repository health: <commit frequency, contributor count>

Distribution Patches (if --os or --container-image was set):

Distro	Patch ID	Affected Packages	Priority
Ubuntu 22.04	USN-XXXX-X	liblog4j2-java	High

Workarounds (interim mitigations, if no immediate fix):

Workaround: <description>
  Effectiveness: <score>/100
  Applicable versions: <range>
  Requires restart: <Yes/No>
  Verification: <steps>

CWE Guidance (weakness-specific remediation strategies):

CWE-<id>: <title>
Remediation strategy:
<markdown guidance from API>

Verification guidance:
<markdown from API>

Verification Steps (per package manager):

Verify the fix:
  npm: npm audit --json | jq '.vulnerabilities["<package>"]'
  maven: mvn dependency:tree | grep <package>
  pip: pip show <package> | grep Version

Step 5: Cross-Reference with Dependabot and Memory

1. If Dependabot PR exists for this upgrade, note: "Dependabot PR #N already proposes this upgrade -- consider reviewing and merging"
2. If a prior /vulnetix:exploits analysis exists in memory (threat_model, cwss), surface the priority: "Prior exploit analysis: P1 (87.5) -- Act now"
3. If a prior /vulnetix:fix analysis exists, note what was previously proposed

Step 6: Present Actionable Next Steps

Based on the remediation plan, present concrete actions:

1. If registry fix available: Show exact manifest edit (same diff format as /vulnetix:fix) with the fix version from the remediation plan. Offer to apply it.
2. If source fix only (no registry release): Note that the fix requires building from source or waiting for a release. Link to the commit/PR.
3. If workaround only: Present the workaround steps with effectiveness score. Note: "No patch available yet -- workaround is interim mitigation." Also fetch Snort rules: vulnetix vdb traffic-filters "$ARGUMENTS" -o json — if available, present them as a network-level defense alongside the workaround.
4. If distribution patch: Provide the package manager command (e.g., apt-get update && apt-get install --only-upgrade <package>)
5. Test commands: Suggest running tests after applying the fix
6. Re-scan: Suggest vulnetix vdb vuln <vuln-id> to verify the fix resolved the vulnerability
7. Rollback guidance: If the fix introduces breaking changes, note the backup/rollback approach

Snort Rules (when no patch or low Safe Harbour):

When no registry fix is available, Safe Harbour confidence is low (< 0.35), or the user's triage choice is not a patch (e.g., risk-accepted, deferred, mitigated), fetch and present Snort rules:

vulnetix vdb traffic-filters "$ARGUMENTS" -o json

If rules are returned, display each rule's rawText for direct IDS/IPS deployment. Note signatureSeverity and confidence. Present as: "While no patch is available, these IDS/IPS rules can detect and block exploit traffic targeting this vulnerability."

Cross-references:

• "Run /vulnetix:exploits $ARGUMENTS for exploit intelligence and threat modeling"
• "Run /vulnetix:vuln $ARGUMENTS for full vulnerability details"
• "Run /vulnetix:exploits-search --ecosystem <eco> to discover related exploited vulnerabilities"
• "Run vulnetix vdb traffic-filters $ARGUMENTS for Snort rules to filter malicious traffic"

Step 7: Update Vulnerability Memory

1. Use Read to load the current memory file
2. Create or update the entry:
   • versions.fixed_in -- from the registry fix data
   • versions.fix_source -- registry name and version
   • severity -- from CVSS data
   • safe_harbour -- computed from fix confidence
   • aliases -- merge any newly discovered aliases
   • dependabot -- if gathered in Step 5
3. Append to history: event: remediation-plan, detail: summary of fix options (e.g., "Registry fix: 2.17.1 (Maven Central, High confidence). 2 workarounds available. CWE-502 guidance provided.")
4. Use Write to save
5. Confirm to the user

If the user applies a fix or makes a decision:

• Record using the risk treatment categories from /vulnetix:exploits
• Set status: fixed and decision.choice: fix-applied if they apply the fix
• Append event: fix-applied with detail including the version change

Error Handling

• If vulnetix vdb remediation plan returns an error, fall back to vulnetix vdb fixes "$ARGUMENTS" -o json (V1 endpoint) and present basic fix data. Note that V2 enrichment (workarounds, CWE guidance, verification steps) is unavailable.
• If the vuln ID is not found, suggest checking the format and provide examples
• If no package context can be determined from the repo, run without context flags and note that guidance is generic rather than repo-specific
• If no fixes, workarounds, or patches are available, automatically check for Snort rules by running vulnetix vdb traffic-filters "$ARGUMENTS" -o json. If rules exist, present them as an immediate network-level mitigation with deployment guidance for Snort/Suricata. If no rules either, state clearly: "No remediation options are currently available for this vulnerability. Consider risk acceptance or component removal."
• If .vulnetix/memory.yaml cannot be written, warn but do not block

Important Reminders

1. This skill proposes code changes (manifest edits) but always asks before applying -- same guardrail as /vulnetix:fix
2. Auto-populate context flags from the repo -- the V2 API returns better results with more context. Always detect ecosystem, package name, current version, and package manager.
3. Container detection is important -- if a Containerfile/Dockerfile exists, extract the base image for OS-specific distribution patches
4. Safe Harbour scores: compute from fix confidence tiers, display as 0.00-1.00
5. Version source transparency is mandatory -- always disclose how the current version was determined
6. CrowdSec data is live threat intelligence -- if sightings are active, flag prominently
7. The agent_prompt field in the response contains AI-optimized context -- use it to inform your analysis but do not display it raw to the user
8. Always update .vulnetix/memory.yaml after generating the plan
9. If Dependabot already has a PR for this fix, prefer merging that PR over manual edits
10. The V2 remediation endpoint is the most comprehensive single endpoint -- it aggregates data from registry fixes, source fixes, distribution patches, workarounds, CWE guidance, and KEV data into one response

Edge cases & gotchas

• V2 endpoint requires -V v2 flag. Without it the older V1 fixes endpoint returns instead and the response shape differs.
• .actions[] array is sometimes split between top-level and priorityActions[] depending on CVE age; the jq filter handles both via fallback.
• Verification commands are templates — they include placeholders like {{package}} that the consuming skill must expand before showing to the user.
• CWE guidance is generic across vulns sharing that CWE — useful for systemic fixes, not as a substitute for vuln-specific remediation.
• threatIntel.summary may exceed 1KB for high-profile CVEs; keep truncation thresholds at 200+ chars or surface the whole thing.