Fix

Vulnetix Fix Intelligence Skill

This skill fetches fix intelligence for a vulnerability and proposes concrete, actionable remediation steps for the current repository.

Output & Analysis Guidelines

Primary output format: Markdown. All reports, tables, fix options, version diffs, and verification summaries MUST be presented as formatted markdown text directly — never generate scripts or programs to produce output that can be expressed as markdown.

Visual data — use Mermaid diagrams to display data visually when it aids comprehension. Mermaid renders natively in markdown and requires no external tools. Use it for:

• Dependency upgrade paths → graph LR showing current → target version with breaking change annotations
• Fix option comparison → quadrantChart plotting Safe Harbour confidence vs. version change magnitude
• Dependency tree showing vulnerable path → graph TD (root → parent → vulnerable dep)
• Post-fix verification status → flowchart (scan → tests → result)

Example — upgrade path:

```mermaid
graph LR
    A[log4j-core 2.14.1] -->|patch| B[2.14.2]
    A -->|minor| C[2.17.1 ✓ fix]
    A -->|major| D[3.0.0]
    style A fill:#f66,stroke:#333
    style C fill:#6f6,stroke:#333
```

If uv is available, richer visualizations can be generated with Python (matplotlib, plotly) and saved to .vulnetix/:

command -v uv &>/dev/null && uv run --with matplotlib python3 -c '
import matplotlib.pyplot as plt
# ... generate chart ...
plt.savefig(".vulnetix/chart.png", dpi=150, bbox_inches="tight")
'

When Python charts are generated, display them inline and keep the Mermaid version as a text fallback.

Data processing — tooling cascade (strict order):

1. jq / yq + bash builtins (preferred) — jq for JSON (API responses, CycloneDX SBOMs, package manager output), yq for YAML (memory file). Pipe to head, tail, cut, sed, grep, sort, uniq, wc for shaping.
2. uv (for complex analysis or charts) — If dependency graph analysis, version comparison logic, or visualization beyond Mermaid are needed, check uv first:

   command -v uv &>/dev/null && uv run --with pandas,matplotlib python3 -c '...'
   

3. python3 stdlib (last resort) — Only if uv is unavailable. Use json, csv, collections, statistics modules — no pip dependencies:

   command -v python3 &>/dev/null && python3 -c 'import json, sys; ...'
   

Never assume any runtime is available — always check with command -v before use. If all programmatic tools are unavailable, analyze manually with the Read tool and present results as markdown with Mermaid diagrams.

Package manager commands (npm install --dry-run, pip show, go mod tidy, cargo check, etc.) are exempt — they are executed directly as part of the fix workflow, not for data analysis.

Mandatory Reporting Requirements

Every output and report from this skill MUST include the following version and provenance information for each affected package:

Package Version Reporting

All reports MUST display:

Version Source Transparency

You MUST be transparent about how the current version was determined. Report one of:

• User-supplied — the user provided the version directly
• Manifest — read from a package manager manifest file (state which file)
• Lockfile — read from a lockfile (state which file)
• Installed — derived from the installed package on the filesystem:
  • npm/node: read node_modules/<pkg>/package.json (search parent directories too)
  • Python: run pip show <pkg> or read site-packages/<pkg>/METADATA
  • Go: read go.sum or run go list -m <pkg>
  • Rust: read Cargo.lock or run cargo metadata
  • System binaries: run <binary> --version or check PATH resolution
  • Ruby: run gem list <pkg> or read Gemfile.lock
  • Maven: read effective POM or local .m2 cache
• Context — the version was already present in conversation context
• Unknown — version could not be determined (explain why)

If the user does not supply the version and it is not in conversation context, you MUST attempt to derive it from the filesystem before reporting "Unknown". Search outside the current working directory if needed — check parent directories, global package manager directories, and gitignored directories (e.g., node_modules/, vendor/, .venv/, target/, __pycache__/).

Safe Harbour Confidence Score

Express the Safe Harbour score as a decimal between 0.00 and 1.00 where 1.00 = 100% confidence the fix resolves the vulnerability without introducing regressions or breaking changes.

Confidence tiers:

• High confidence (> 0.90): Patch-level bump in the same minor version, official registry release, well-tested fix, minimal API surface change
• Reasonable confidence (0.35–0.90): Minor version bump, distro-repackaged patch, source fix from upstream with commit hash, some API changes but backward-compatible
• Low confidence (< 0.35): Major version bump, unofficial patch, cherry-picked commit from development branch, significant API changes, no upstream release yet

What factors adjust confidence:

• Registry-published release with changelog: +0.15
• Distro-maintained patch (e.g., Debian, Ubuntu, RHEL): +0.10
• Upstream commit hash verified in release tag: +0.10
• CISA KEV listed (validated exploitation): +0.05 (urgency signal, not fix quality)
• Major version jump: −0.25
• No test suite in project to validate: −0.15
• Transitive dependency (indirect control): −0.10
• Built from source with untagged commit: −0.20

Report format for each affected package:

Package: <name>
Current Version: <version> (source: <version-source>)
Fix Target: <version> (source: <registry|distro <name> <version>|commit <hash>>)
Safe Harbour: <score> (<High|Reasonable|Low> confidence)

Vulnerability Memory File (.vulnetix/memory.yaml)

This skill maintains a .vulnetix/memory.yaml file in the repository root that tracks all vulnerability encounters, decisions, and fix outcomes across sessions. You MUST read this file at the start of every invocation and update it after every action.

Schema

# .vulnetix/memory.yaml
# Auto-maintained by Vulnetix Claude Code Plugin
# Do not remove — tracks vulnerability decisions, manifest scans, and fix history

schema_version: 1
manifests:                                # Tracked manifest files and SBOM scan history
  package.json:
    path: "package.json"                  # Relative path from repo root
    ecosystem: npm
    last_scanned: "2024-01-15T10:30:00Z"  # ISO 8601 UTC
    sbom_generated: true
    sbom_path: ".vulnetix/scans/package.json.20240115T103000Z.cdx.json"
    vuln_count: 3                         # Vulnerabilities found in last scan
    scan_source: hook                     # hook | fix | exploits | package-search
  services--api--go.mod:
    path: "services/api/go.mod"           # Supports monorepo paths (key uses -- separator)
    ecosystem: go
    last_scanned: "2024-01-15T10:31:00Z"
    sbom_generated: true
    sbom_path: ".vulnetix/scans/services--api--go.mod.20240115T103100Z.cdx.json"
    vuln_count: 0
    scan_source: hook
vulnerabilities:
  CVE-2021-44228:                       # Primary vuln ID (key)
    aliases:                             # Other IDs for the same vuln
      - GHSA-jfh8-c2jp-5v3q
    package: log4j-core
    ecosystem: maven
    discovery:
      date: "2024-01-15T10:30:00Z"      # ISO 8601 UTC
      source: manifest                   # manifest | lockfile | sbom | scan | user | hook
      file: pom.xml                      # The manifest where it was found
      sbom: .vulnetix/scans/pom.xml.cdx.json  # CycloneDX v1.7 SBOM (when produced by scan/hook)
    versions:
      current: "2.14.1"
      current_source: "lockfile: pom.xml"
      fixed_in: "2.17.1"
      fix_source: "registry: Maven Central"
    severity: critical                   # critical | high | medium | low | unknown
    safe_harbour: 0.82                   # 0.00–1.00 confidence score
    status: fixed                        # See VEX Status Mapping below
    justification: null                  # See VEX Justification Mapping below
    action_response: null                # See VEX Action Response Mapping below
    threat_model:                        # Populated by /vulnetix:exploits
      techniques: [T1190, T1059]         # MITRE ATT&CK IDs (internal only)
      tactics:                           # Developer-friendly descriptions (shown to user)
        - "Attackable from the internet"
        - "Can run arbitrary commands"
      attack_vector: network             # network | local | adjacent | physical
      attack_complexity: low             # low | high
      privileges_required: none          # none | low | high
      user_interaction: none             # none | required
      reachability: direct               # direct | transitive | not-found | unknown
      exposure: public-facing            # public-facing | internal | local-only | unknown
    cwss:                                # CWSS-derived priority (populated by /vulnetix:exploits)
      score: 87.5                        # 0-100 composite priority score
      priority: P1                       # P1 | P2 | P3 | P4
      factors:
        technical_impact: 100            # 0-100
        exploitability: 95               # 0-100
        exposure: 100                    # 0-100
        complexity: 90                   # 0-100
        repo_relevance: 70               # 0-100
    pocs:                                # PoC sources (from /vulnetix:exploits, never executed)
      - url: "https://exploit-db.com/exploits/12345"
        source: exploitdb
        type: poc
        local_path: ".vulnetix/pocs/CVE-2021-44228/exploit_12345.py"
        fetched_date: "2024-01-15T10:35:00Z"
        verified: true
        analysis: "RCE via JNDI lookup, network vector, no auth"
    dependabot:                          # Populated from GitHub Dependabot via gh CLI
      alert_number: 42                   # Dependabot alert number on this repo
      alert_state: fixed                 # open | dismissed | fixed | auto_dismissed
      alert_url: "https://github.com/owner/repo/security/dependabot/42"
      dismiss_reason: null               # fix_started | inaccurate | no_bandwidth | not_used | tolerable_risk | null
      dismiss_comment: null              # Dismisser's comment, if any
      pr_number: 187                     # Associated Dependabot PR number, or null
      pr_state: merged                   # open | closed | merged | null
      pr_url: "https://github.com/owner/repo/pull/187"
      pr_latest_comment: "LGTM, merging" # Last comment on the PR (for context)
      last_checked: "2024-01-15T10:30:00Z"
    code_scanning:                       # Populated from GitHub CodeQL / code scanning via gh CLI
      alerts:                            # CodeQL alerts correlated to this vuln (matched by CWE)
        - alert_number: 15
          state: dismissed               # open | dismissed | fixed
          rule_id: "java/log4j-injection"
          rule_name: "Log4j injection"
          severity: critical             # critical | high | medium | low | warning | note | error
          dismissed_reason: null         # "false positive" | "won't fix" | "used in tests" | null
          dismissed_comment: null        # Free-text justification (max 280 chars)
          dismissed_by: "octocat"        # GitHub username
          file_path: "src/main/java/App.java"
          start_line: 42
          url: "https://github.com/owner/repo/security/code-scanning/15"
      tool: CodeQL                       # CodeQL | semgrep | etc.
      tool_version: "2.15.0"
      last_checked: "2024-01-15T10:30:00Z"
    secret_scanning:                     # Populated from GitHub secret scanning via gh CLI
      alerts:                            # Secret scanning alerts correlated to this vuln's package/context
        - alert_number: 7
          state: resolved                # open | resolved
          secret_type: "github_personal_access_token"
          secret_type_display: "GitHub Personal Access Token"
          resolution: revoked            # false_positive | wont_fix | revoked | used_in_tests | null
          resolution_comment: "Token rotated and old one revoked"
          resolved_by: "octocat"
          validity: inactive             # active | inactive | unknown
          file_path: "config/settings.py"
          url: "https://github.com/owner/repo/security/secret-scanning/7"
          push_protection_bypassed: false
      last_checked: "2024-01-15T10:30:00Z"
    decision:
      choice: fix-applied                # See User Decision Values below
      reason: "Upgraded to 2.17.1 via version bump"
      date: "2024-01-15T11:00:00Z"
    history:                             # Append-only event log
      - date: "2024-01-15T10:30:00Z"
        event: discovered
        detail: "Found via /vulnetix:fix CVE-2021-44228"
      - date: "2024-01-15T11:00:00Z"
        event: fix-applied
        detail: "Version bumped log4j-core 2.14.1 → 2.17.1 in pom.xml"

VEX Status Mapping (Internal → Developer Language)

Use VEX semantics internally but always communicate to the user in developer-friendly language. Never use raw VEX terminology with the user.

VEX Justification Mapping (for not_affected status)

VEX Action Response Mapping (for affected status)

User Decision Values

These are the decision.choice values recorded in the memory file, mapped from user feedback:

Dependabot Integration

When gh CLI is available, check GitHub Dependabot alerts and PRs for additional context. Dependabot state is a supplementary signal — it does not override user decisions recorded in the memory file, but it enriches context.

Checking gh CLI Availability

gh auth status 2>/dev/null

If this succeeds, the user has gh authenticated and you can query Dependabot. If it fails, skip Dependabot checks silently — do not prompt the user to authenticate.

Querying Dependabot Alerts

# Get the repo owner/name from git remote
gh api repos/{owner}/{repo}/dependabot/alerts --jq '[.[] | select(.security_advisory.cve_id == "'"$ARGUMENTS"'" or (.security_advisory.ghsa_id == "'"$ARGUMENTS"'") or (.security_advisory.identifiers[]? | select(.type == "CVE" and .value == "'"$ARGUMENTS"'") ) )] | first'

If the vuln ID is a GHSA, also match on .security_advisory.ghsa_id. If the vuln ID is a CVE, match on .security_advisory.cve_id and the identifiers array.

If no alert matches the exact vuln ID, also try aliases from the memory file entry.

Querying Dependabot PRs

# Find Dependabot PRs referencing this vulnerability or the affected package
gh pr list --author "app/dependabot" --state all --json number,title,state,url,comments --limit 50 | jq '[.[] | select(.title | test("'"$PACKAGE_NAME"'"; "i"))]'

For each matching PR, extract:

• PR number, state (open/closed/merged), URL
• The latest comment (last item in .comments[]): gh pr view <number> --json comments --jq '.comments[-1].body'

Dependabot Alert State → VEX Mapping

Map Dependabot states to VEX status and user decision values. Always communicate to the user in developer-friendly language.

When a Dependabot PR exists:

For closed (not merged) PRs: Read the latest comment on the PR to derive the justification. Common patterns:

• "superseded by ..." / "replaced by ..." → decision: deferred, reason: paraphrase the comment
• "not needed" / "false positive" → decision: not-affected, reason: paraphrase the comment
• "will handle manually" → decision: deferred, reason: "Team will handle manually"
• "breaking changes" / "can't upgrade" → decision: deferred, reason: paraphrase the comment
• No comments or unclear → decision: investigating, reason: "Dependabot PR closed without explanation"

When Dependabot and Memory File Disagree

If the memory file has a user decision but Dependabot shows a different state:

• User decision takes precedence — it represents a deliberate human choice
• Flag the discrepancy to the user: "Note: Dependabot shows this as , but you previously marked it as . The Dependabot state may be out of sync."
• Update the dependabot section in the memory file to reflect current Dependabot state regardless — it's a factual record of what GitHub shows

Code Scanning (CodeQL) Integration

When gh CLI is available, query GitHub code scanning alerts for findings that correlate with the current vulnerability. CodeQL alerts are correlated by CWE match — if the vulnerability's CWE (from VDB data) matches a CodeQL rule's tags or the rule directly references the vulnerability.

Querying Code Scanning Alerts

# List all open code scanning alerts
gh api repos/{owner}/{repo}/code-scanning/alerts?state=open --jq '[.[] | select(.rule.tags[]? | test("cwe-"; "i"))]'

# Check for alerts matching a specific CWE (extracted from vuln context in Step 2)
gh api repos/{owner}/{repo}/code-scanning/alerts --jq '[.[] | select(.rule.tags[]? | test("CWE-<NUMBER>"; "i"))]'

# Also check dismissed and fixed alerts for prior decisions
gh api repos/{owner}/{repo}/code-scanning/alerts?state=dismissed --jq '[.[] | select(.rule.tags[]? | test("CWE-<NUMBER>"; "i"))]'
gh api repos/{owner}/{repo}/code-scanning/alerts?state=fixed --jq '[.[] | select(.rule.tags[]? | test("CWE-<NUMBER>"; "i"))]'

If the repository does not have code scanning enabled, these calls return 403 or 404 — skip silently.

Checking Default Setup Status

gh api repos/{owner}/{repo}/code-scanning/default-setup --jq '{state, languages, query_suite}'

If state is not-configured, note this to the user: "CodeQL is not enabled on this repository. Consider enabling it to catch similar issues in code."

Code Scanning Alert State → VEX Mapping

Enriching vulnerability context with CodeQL findings:

When a CodeQL alert matches the vulnerability's CWE:

• The most_recent_instance.location tells you exactly which file and line the vulnerable pattern appears — include this in the fix report
• The rule.full_description provides CodeQL's analysis of the weakness — quote relevant parts
• If multiple instances exist, list the affected files so the user knows everywhere the pattern occurs
• If the alert is fixed, this is strong evidence the code-level vulnerability has been addressed (complements a dependency version bump)
• Use dismissed_comment as the justification text when surfacing prior decisions

Autofix Integration (CodeQL AI Suggestions)

If a CodeQL alert has an autofix available, check its status:

gh api repos/{owner}/{repo}/code-scanning/alerts/{alert_number}/autofix --jq '{status}'

If autofix status is success, suggest the user review it alongside any dependency fix — code-level fixes and dependency upgrades are complementary.

Secret Scanning Integration

When gh CLI is available, query GitHub secret scanning alerts. Secret scanning findings relate to vulnerability management when:

• A leaked secret could be used to exploit the vulnerability (e.g., leaked API key + RCE = worse impact)
• The vulnerability is in credential handling code (CWE-798, CWE-321, CWE-259)
• The fix involves rotating secrets that may have been exposed

Querying Secret Scanning Alerts

# List all open secret scanning alerts
gh api repos/{owner}/{repo}/secret-scanning/alerts?state=open

# List resolved alerts (to check for prior decisions)
gh api repos/{owner}/{repo}/secret-scanning/alerts?state=resolved

If the repository does not have secret scanning enabled, these calls return 403 or 404 — skip silently.

Correlation with vulnerability context:

• If the vulnerability's CWE relates to credential handling (CWE-798 hard-coded credentials, CWE-321 hard-coded cryptographic key, CWE-259 hard-coded password, CWE-200 information exposure), check for secret scanning alerts in the same files
• If the vulnerable package handles authentication/secrets (e.g., jsonwebtoken, bcrypt, passport, oauth2), check for leaked secrets that might need rotation after fixing

Secret Scanning Alert State → VEX Mapping

Push protection context: If push_protection_bypassed is true, note this to the user — it means someone deliberately pushed a secret past GitHub's push protection. Include the bypasser's username and their comment (if any) for audit trail:

Secret push protection was bypassed by <user>: "<comment>"

Secret validity: If validity is active, flag urgently: "This secret is still active — rotate it immediately." If inactive, note: "Secret has been deactivated." If unknown, note: "Secret validity could not be verified — recommend rotating as a precaution."

When GHAS and Memory File Disagree

Same principle as Dependabot:

• User decision takes precedence over GitHub alert state
• Flag discrepancies to the user
• Always update the code_scanning and secret_scanning sections to reflect current GitHub state — they are factual records

Reading and Interpreting Prior State

When the memory file contains an entry for the current vuln ID (or any of its aliases):

1. Show the user what's known — previous status, decision, and when it was last updated
2. Show GitHub security context — surface all available GHAS data:
   • Dependabot: "Dependabot alert #N: . PR #N: ."
   • CodeQL: "CodeQL alert #N (): in :"
   • Secret scanning: "Secret scanning alert #N (): , validity: <active|inactive|unknown>"
3. Highlight changes — if the vulnerability context has changed (new severity, new fix available, CISA KEV listing added, any GHAS alert state changed), flag this to the user
4. Respect prior decisions — if the user previously marked a vuln as "Risk accepted" or "Not affected", remind them of that decision and ask if they want to reassess rather than re-proposing the same fix
5. Update, don't duplicate — update the existing entry rather than creating a new one

Workflow

Step 0: Load Vulnerability Memory and Prior SBOMs

Before anything else:

0a. Load memory file:

1. Use Glob to search for .vulnetix/memory.yaml in the repo root
2. If it exists, use Read to load it
3. Check if the current vuln ID (from $ARGUMENTS) or any known aliases appear in the file
4. If a prior entry exists:
   • Display to the user: Previously seen: <vulnId> — Status: <developer-friendly status> (as of <date>). Reason: <decision reason>
   • If cwss data exists from a prior /vulnetix:exploits analysis, display: Priority: <P1/P2/P3/P4> (<score>) — "<priority description>" and use the threat model context to inform fix urgency.
   • If status is fixed and no new information contradicts it, confirm the fix is still in place by checking the current installed version. If the version has regressed, update the status to affected and proceed with the fix workflow.
   • If status is risk-accepted or not-affected, ask: "You previously marked this as . Has anything changed, or would you like to reassess?"
   • If status is investigating or deferred, proceed with the fix workflow and note this is a follow-up.
   • If the entry has a discovery.sbom path, read that CycloneDX file for additional context (affected components, version ranges, severity ratings from the original scan).
5. If no prior entry exists, proceed normally — a new entry will be created in Step 8.

0b. Check for existing CycloneDX SBOMs:

1. Use Glob for .vulnetix/scans/*.cdx.json
2. If SBOMs exist, scan them for the current vuln ID — this provides pre-existing context about which manifests surfaced this vulnerability and what component versions were scanned
3. Reference the SBOM path in the memory entry's discovery.sbom field when creating or updating entries

0c. Check Dependabot via gh CLI:

1. Run gh auth status 2>/dev/null — if it fails, skip this step silently
2. If gh is available, query Dependabot alerts for this vuln ID (see "Querying Dependabot Alerts" above)
3. If a matching alert is found:
   • Display to the user: Dependabot alert #<N>: <developer-friendly state> (using the mapping table)
   • If a Dependabot PR exists, display: Dependabot PR #<N>: <state> with the latest comment summary
   • If the alert is dismissed or fixed, show the reason
4. If the memory file already has a dependabot section for this vuln, compare with current GitHub state and flag any changes: "Dependabot state changed: <old> → <new>"
5. Update the dependabot section in the memory entry with current state (will be persisted in Step 8)
6. Use Dependabot context to inform fix urgency:
   • Open alert + open PR → "A Dependabot upgrade PR already exists — consider reviewing and merging PR #N instead of manual fix"
   • Open alert + no PR → proceed with normal fix workflow
   • Open alert + closed PR → check PR comments for context on why it was closed — inform fix approach accordingly

0d. Check Code Scanning (CodeQL) via gh CLI:

1. Skip if gh auth failed in 0c
2. Extract the CWE ID from the vulnerability context (fetched in Step 2, but pre-check here if the memory file already has threat_model data or known CWE from prior analysis)
3. Query code scanning alerts matching the CWE:

   gh api repos/{owner}/{repo}/code-scanning/alerts --jq '[.[] | select(.rule.tags[]? | test("CWE-<NUMBER>"; "i"))]'
   

4. If CodeQL alerts are found:
   • Display: CodeQL alert #<N> (<rule_id>): <state> in <file>:<line> for each
   • If any alert is dismissed, show the reason and comment
   • If any alert has autofix status success, note: "CodeQL has an AI-suggested fix available"
5. Check default setup status to inform the user if CodeQL is not enabled:

   gh api repos/{owner}/{repo}/code-scanning/default-setup --jq '.state'
   

   If not-configured, note: "CodeQL is not enabled on this repo — consider enabling it for ongoing code-level detection of this weakness class"
6. If the memory file has a prior code_scanning section, compare alert states and flag changes
7. Store CodeQL findings for persistence in Step 8

0e. Check Secret Scanning via gh CLI:

1. Skip if gh auth failed in 0c
2. Determine if secret scanning is relevant to this vulnerability:
   • Check if the CWE relates to credential handling (CWE-798, CWE-321, CWE-259, CWE-200, CWE-522, CWE-256)
   • Check if the affected package handles authentication/secrets
3. If relevant, query secret scanning alerts:

   gh api repos/{owner}/{repo}/secret-scanning/alerts?state=open
   

4. If alerts are found in files that overlap with the vulnerability's affected code:
   • Display: Secret scanning alert #<N> (<secret_type>): <state>, validity: <validity>
   • If validity is active, flag urgently: "Active secret detected — rotate immediately, especially given this vulnerability"
   • If push_protection_bypassed, note the bypass for audit context
5. Also check resolved alerts for prior decisions:

   gh api repos/{owner}/{repo}/secret-scanning/alerts?state=resolved --jq '[.[] | select(.resolution != null)]'
   

6. If the memory file has a prior secret_scanning section, compare and flag state changes
7. Store secret scanning findings for persistence in Step 8

Step 1: Fetch Fix Data

Run the Vulnetix VDB fixes command for both V1 and V2 endpoints:

vulnetix vdb fixes "$ARGUMENTS" -o json
vulnetix vdb fixes "$ARGUMENTS" -o json -V v2

V1 response (basic fixes):

{
  "fixes": [
    {
      "type": "version",
      "package": "log4j-core",
      "ecosystem": "maven",
      "fixedIn": "2.17.1",
      "description": "Upgrade to patched version"
    }
  ]
}

V2 response (enhanced with registry, distro, source fixes):

{
  "fixes": [
    {
      "type": "registry",
      "package": "log4j-core",
      "ecosystem": "maven",
      "fixedIn": "2.17.1",
      "registryUrl": "https://repo1.maven.org/...",
      "releaseDate": "2021-12-28"
    },
    {
      "type": "distro-patch",
      "distro": "ubuntu",
      "version": "20.04",
      "package": "liblog4j2-java",
      "patchVersion": "2.17.1-0ubuntu1",
      "aptCommand": "sudo apt-get install liblog4j2-java=2.17.1-0ubuntu1"
    },
    {
      "type": "source-fix",
      "commitUrl": "https://github.com/apache/logging-log4j2/commit/abc123",
      "patchUrl": "https://github.com/apache/logging-log4j2/commit/abc123.patch"
    }
  ]
}

Step 2: Fetch Vulnerability Context

Get additional context about the vulnerability:

vulnetix vdb vuln "$ARGUMENTS" -o json
vulnetix vdb affected "$ARGUMENTS" -o json -V v2

Extract:

• Affected package/product names
• Vulnerable version ranges (e.g., >=2.0.0, <2.17.1)
• CVSS/severity (to assess urgency)
• CISA KEV due date (if applicable)

Step 3: Analyze Repository Dependencies (Deep Filesystem Scan)

You MUST perform a thorough scan that goes beyond the current working directory. Search the entire project tree including gitignored directories.

3a-pre: Check for Cached SBOMs

Before scanning, check the manifests section of .vulnetix/memory.yaml for recently scanned files. If a manifest was scanned by the pre-commit hook (or a prior skill invocation) within the last 24 hours (last_scanned timestamp), read the cached SBOM from sbom_path instead of re-scanning. This avoids redundant API calls. If the SBOM file is missing or stale, proceed with a fresh scan.

3a: Find All Manifest and Lockfiles

Use Glob to find manifest files across the project, including monorepo structures:

**/package.json, **/package-lock.json, **/yarn.lock, **/pnpm-lock.yaml
**/requirements.txt, **/pyproject.toml, **/Pipfile, **/Pipfile.lock, **/poetry.lock, **/uv.lock
**/go.mod, **/go.sum
**/Cargo.toml, **/Cargo.lock
**/pom.xml, **/build.gradle, **/build.gradle.kts, **/gradle.lockfile
**/Gemfile, **/Gemfile.lock
**/composer.json, **/composer.lock

3b: Derive Installed Versions from the Filesystem

Do not rely solely on manifests. Verify the actually-installed version by reading from package manager artifacts. These directories are typically gitignored — read them directly:

• npm/node: Read node_modules/<package>/package.json → .version field. Also check parent directories and workspace root node_modules/.
• Python: Run pip show <package> or read .venv/lib/python*/site-packages/<package>/METADATA or __pycache__ dist-info directories.
• Go: Parse go.sum for exact hashes. Run go list -m -json <package> if go toolchain is available.
• Rust: Read Cargo.lock for exact resolved versions. Run cargo metadata --format-version 1 if available.
• Maven: Check ~/.m2/repository/<groupPath>/<artifact>/ for cached JARs. Run mvn dependency:tree if available.
• Ruby: Read Gemfile.lock for resolved versions.
• System binaries: Run which <binary> then <binary> --version to determine installed version from PATH.

3c: Determine Dependency Relationship

Use Read on each manifest and lockfile to determine:

1. Is the vulnerable package installed? (exact name match in manifest or lockfile)
2. What version is installed? (compare manifest, lockfile, AND filesystem-installed version — report all if they differ)
3. Is it a direct or transitive dependency? (present in manifest = direct; only in lockfile = transitive)
4. What imports/requires are used from this package? Use Grep to find all import/require/include statements referencing the vulnerable package across the codebase

If the package is not found, inform the user that the vulnerability may not affect this repository.

Step 4: Evaluate Dependency Inlining (First-Party Replacement)

Before proposing a version bump, evaluate whether the dependency can be removed entirely:

Criteria for inlining (ALL must be true):

1. The affected third-party code is open source with a compatible license
2. The source is publicly available online (e.g., on GitHub, GitLab, crates.io source)
3. The portion of the library actually used by this application is small — assess by:
   • Counting how many functions/classes/modules from the package are imported
   • Estimating the lines of code for just those used parts (< ~200 lines is a good threshold)
4. The used functionality is self-contained (no deep internal dependency chain within the library)

If inlining is viable:

• Use WebFetch to retrieve the specific source file(s) from the upstream repository
• Extract only the functions/classes actually used by the application
• Preserve the original license attribution in a comment header
• Propose writing the extracted code as a first-party module (e.g., lib/, internal/, utils/)
• Show edits to update all import/require statements to point to the new first-party module
• Show edits to remove the dependency from all manifest and lockfiles

Present this as Option A0 (highest priority) when the criteria are met, above the standard Version Bump option.

Step 5: Present Fix Options

Categorize fixes into 5 categories (A0-D) and present them in priority order. Every option MUST include the Safe Harbour confidence score and all version details per the Mandatory Reporting Requirements above.

A0. Inline as First-Party Code

…(truncated)