Agent Skills › davepoon/buildwithclaude › remediation

remediation

GitHub

生成上下文感知的漏洞修复计划，利用V2 API提供针对特定环境（如容器、OS）的精准修复建议、CWE策略及验证命令。支持读取历史状态并更新记忆文件，集成Dependabot数据以辅助决策。

plugins/vulnetix/skills/remediation/SKILL.md davepoon/buildwithclaude

Trigger Scenarios

需要获取漏洞的详细修复方案请求基于当前环境的上下文感知补丁建议查询漏洞的缓解措施和验证步骤

Install

npx skills add davepoon/buildwithclaude --skill remediation -g -y

More Options

Non-standard path

npx skills add https://github.com/davepoon/buildwithclaude/tree/main/plugins/vulnetix/skills/remediation -g -y

Use without installing

npx skills use davepoon/buildwithclaude@remediation

指定 Agent (Claude Code)

npx skills add davepoon/buildwithclaude --skill remediation -a claude-code -g -y

安装 repo 全部 skill

npx skills add davepoon/buildwithclaude --all -g -y

预览 repo 内 skill

npx skills add davepoon/buildwithclaude --list

SKILL.md

Frontmatter

{
    "name": "remediation",
    "model": "sonnet",
    "description": "Get a context-aware remediation plan for a vulnerability with fix verification steps",
    "allowed-tools": "Bash, Read, Glob, Grep, Edit, Write",
    "argument-hint": "<vuln-id>",
    "user-invocable": true
}

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:

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

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

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

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

Workflow

Step 1: Load Memory and Detect Repository Context

Load .vulnetix/memory.yaml as described above
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
If the vuln ID is already in memory with a package field, use that package name
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.
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]

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

# 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

If Dependabot PR exists for this upgrade, note: "Dependabot PR #N already proposes this upgrade -- consider reviewing and merging"
If a prior /vulnetix:exploits analysis exists in memory (threat_model, cwss), surface the priority: "Prior exploit analysis: P1 (87.5) -- Act now"
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:

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.
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.
If workaround only: Present the workaround steps with effectiveness score. Note: "No patch available yet -- workaround is interim mitigation."
If distribution patch: Provide the package manager command (e.g., apt-get update && apt-get install --only-upgrade <package>)
Test commands: Suggest running tests after applying the fix
Re-scan: Suggest vulnetix vdb vuln <vuln-id> to verify the fix resolved the vulnerability
Rollback guidance: If the fix introduces breaking changes, note the backup/rollback approach

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"

Step 7: Update Vulnerability Memory

Use Read to load the current memory file
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
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.")
Use Write to save
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, 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

This skill proposes code changes (manifest edits) but always asks before applying -- same guardrail as /vulnetix:fix
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.
Container detection is important -- if a Containerfile/Dockerfile exists, extract the base image for OS-specific distribution patches
Safe Harbour scores: compute from fix confidence tiers, display as 0.00-1.00
Version source transparency is mandatory -- always disclose how the current version was determined
CrowdSec data is live threat intelligence -- if sightings are active, flag prominently
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
Always update .vulnetix/memory.yaml after generating the plan
If Dependabot already has a PR for this fix, prefer merging that PR over manual edits
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

Version History

502fc01 Current 2026-07-05 15:18

Metadata

Files: 0
Version: 502fc01
Hash: b94d1399
Indexed: 2026-07-05 15:18

remediation

remediation

Trigger Scenarios

Install

SKILL.md

Vulnetix Remediation Plan Skill

Vulnerability Memory (.vulnetix/memory.yaml)

Schema

Reading Prior State

Writing Updated State

VEX Status Mapping

Dependabot Integration

Workflow

Step 1: Load Memory and Detect Repository Context

Step 2: Auto-Populate Context Flags

Step 3: Execute Remediation Plan Query

Step 4: Present the Remediation Plan

Step 5: Cross-Reference with Dependabot and Memory

Step 6: Present Actionable Next Steps

Step 7: Update Vulnerability Memory

Error Handling

Important Reminders

Version History

Same Skill Collection