Vulnetix Remediation Plan Skill

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 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:

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]

CLI Reference (from vulnetix vdb remediation plan docs):

Examples:

# Basic remediation plan
vulnetix vdb remediation plan CVE-2021-44228 -V v2 --include-guidance --include-verification-steps -o json

# 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
• Reg