Vulnetix Exploit Analysis Skill

This skill analyzes exploit intelligence for a specific vulnerability (CVE, GHSA, etc.) and assesses its impact against the current repository. This skill does not modify application code — it only updates

.vulnetix/memory.yaml

/vulnetix:fix

Output & Analysis Guidelines

Primary output format: Markdown. All reports, tables, assessments, and evidence 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:

• Attack path / kill chain visualization →

  graph TD

• CWSS factor breakdown →

  pie

  or

  quadrantChart

• Exploit timeline (discovery dates, PoC releases) →

  timeline

• Threat model reachability →

  flowchart

  (dependency → vulnerable code → exposure)
• Priority comparison across multiple vulns →

  bar

  or

  xychart-beta

Example — CWSS factor breakdown:

```mermaid
pie title CWSS Priority Factors (Score: 87.5)
    "Technical Impact (100)" : 25
    "Exploitability (95)" : 25
    "Exposure (100)" : 15
    "Complexity (90)" : 15
    "Repo Relevance (70)" : 20
```

Example — attack path:

```mermaid
graph LR
    A[Internet] -->|network| B[Web App]
    B -->|imports| C[log4j-core 2.14.1]
    C -->|JNDI lookup| D[RCE]
    style C fill:#f66,stroke:#333
    style D fill:#f00,color:#fff
```

If

uv

.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 extraction/filtering (API responses, CycloneDX SBOMs),

   yq

   for YAML (memory file reads). Pipe to

   head

   ,

   tail

   ,

   cut

   ,

   sed

   ,

   grep

   ,

   sort

   ,

   uniq

   ,

   wc

   for shaping.
2. uv (for complex analysis or charts) — If CWSS scoring, statistical aggregation, 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

   ,

   math

   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

CWE pattern matching (Step 5

grep

Vulnerability Memory (.vulnetix/memory.yaml)

This skill reads and updates the

.vulnetix/memory.yaml

/vulnetix:fix

/vulnetix:package-search

Schema

The canonical schema is defined in

/vulnetix:fix

threat_model

cwss

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

schema_version: 1
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: affected                     # VEX: not_affected | affected | fixed | under_investigation
    justification: null                  # VEX justification (for not_affected)
    action_response: null                # VEX action (for affected)
    threat_model:                        # Populated by /vulnetix:exploits
      techniques:                        # MITRE ATT&CK technique IDs (internal reference)
        - T1190
        - T1059
      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
    pocs:                                # PoC sources (static analysis only, never executed)
      - url: "https://exploit-db.com/exploits/12345"
        source: exploitdb
        type: poc                        # poc | exploit-framework | article
        local_path: ".vulnetix/pocs/CVE-2021-44228/exploit_12345.py"
        fetched_date: "2024-01-15T10:35:00Z"
        verified: true
        analysis: "RCE via JNDI lookup injection, network vector, no auth required"
    cwss:                                # CWSS-derived priority scoring
      score: 87.5                        # 0-100 composite priority score
      priority: P1                       # P1 | P2 | P3 | P4
      factors:
        technical_impact: 100            # 0-100 from CVSS impact / CWE consequence
        exploitability: 95               # 0-100 from EPSS, exploit availability
        exposure: 100                    # 0-100 from attack vector + repo deployment
        complexity: 90                   # 0-100 inverted (higher = easier to exploit)
        repo_relevance: 70               # 0-100 from dependency relationship, reachability
    decision:
      choice: investigating              # See Decision Values below
      reason: "Exploit analysis in progress"
      date: "2024-01-15T10:30:00Z"
    history:                             # Append-only event log
      - date: "2024-01-15T10:30:00Z"
        event: discovered
        detail: "Found via /vulnetix:exploits CVE-2021-44228"
      - date: "2024-01-15T10:35:00Z"
        event: exploit-analysis
        detail: "3 public exploits, EPSS 0.97, Metasploit module, CISA KEV listed. CWSS 87.5 (P1)."

MITRE ATT&CK Mapping

Use ATT&CK technique IDs internally in

threat_model.techniques

threat_model.tactics

tactics

How to select techniques: Map from the CWE, CVSS vector, and exploit analysis:

• CWE-78/CWE-77 (OS/Command injection) → T1059
• CWE-502 (Deserialization) → T1059 + T1068
• CWE-89 (SQL injection) → T1005 + T1565
• CWE-79 (XSS) → T1203 + T1212
• CWE-22 (Path traversal) → T1005
• CWE-400/CWE-770 (Resource exhaustion) → T1499
• CWE-306/CWE-287 (Auth issues) → T1068
• CVSS AV:N → T1190 or T1210
• Supply chain advisory → T1195.001 or T1195.002
• RCE impact → T1059
• Privilege escalation impact → T1068
• Info disclosure impact → T1005 or T1212

Multiple techniques may apply to a single vulnerability.

CWSS Priority Scoring

Compute a CWSS-derived priority score (0–100) from Vulnetix data to help developers decide what to fix first. This uses Common Weakness Scoring System principles simplified into five factors that map directly to available API data and repo analysis.

Factors:

Composite score:

CWSS = (technical_impact × 0.25) + (exploitability × 0.25) + (exposure × 0.15) + (complexity × 0.15) + (repo_relevance × 0.20)

Priority tiers (shown to user):

Risk Treatment Decisions

When the user makes a decision about a vulnerability, map it to one of four risk treatment categories. Use these categories as internal guidance only — always communicate using the developer-friendly language.

fix-applied

mitigated

risk-accepted

deferred

risk-avoided

inlined

not-affected

risk-transferred

VEX status mapping (internal → developer language, same as

/vulnetix:fix

not_affected

affected

fixed

under_investigation

Dependabot Integration

When

gh

gh auth status 2>/dev/null

/vulnetix:fix

During Step 1 (Load Vulnerability Memory):

1. If

   gh

   is available, query Dependabot alerts matching this vuln ID:

   gh api repos/{owner}/{repo}/dependabot/alerts --jq '[.[] | select(.security_advisory.cve_id == "'"$ARGUMENTS"'" or .security_advisory.ghsa_id == "'"$ARGUMENTS"'")] | first'
   

2. If a matching alert exists, include in the prior state display:

   Dependabot alert #<N>: <developer-friendly state>
   

3. If a Dependabot PR exists, check its state and latest comment:

   gh pr list --author "app/dependabot" --state all --json number,title,state,url --limit 50 | jq '[.[] | select(.title | test("'"$PACKAGE_NAME"'"; "i"))] | first'
   

   Display:

   Dependabot PR #<N>: <state> — "<latest comment summary>"

4. Update the

   dependabot

   section in the memory entry during Step 10

Dependabot context informs exploit analysis:

• Open alert + merged PR → fix may already be applied, verify installed version
• Open alert + open PR → team is aware and working on it, note in assessment
• Dismissed alert with reason → factor dismiss reason into repo relevance scoring (e.g.,

  not_used

  → lower repo_relevance)

Code Scanning (CodeQL) Integration

When

gh

/vulnetix:fix

During Step 1 (Load Vulnerability Memory):

1. If

   gh

   is available and the vulnerability's CWE is known (from prior memory or VDB data), query:

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

2. If matching CodeQL alerts are found:
   • Display:

     CodeQL alert #<N> (<rule_id>): <state> in <file>:<line>

   • The file/line data directly informs reachability analysis in Step 5 — if CodeQL found the vulnerable pattern, the code path is confirmed reachable
   • If dismissed, show the

     dismissed_reason

     and

     dismissed_comment

3. Check for autofix availability on each open alert:

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

   If

   success

   , note: "CodeQL has an AI-suggested code fix available"

CodeQL context informs exploit analysis:

• Open CodeQL alert matching the CWE → strong signal for

  reachability: direct

  in threat model, increases

  repo_relevance

  CWSS factor (+20)
• CodeQL

  fixed

  alert → the code pattern was already remediated, may reduce exploit relevance
• CodeQL

  dismissed

  as

  false positive

  → evidence the pattern doesn't actually apply here, may lower

  repo_relevance

• CodeQL alert location data pinpoints exact attack surface for PoC correlation

Secret Scanning Integration

When

gh

/vulnetix:fix

During Step 1 (Load Vulnerability Memory):

1. If

   gh

   is available and the vulnerability relates to credential handling (CWE-798, CWE-321, CWE-259, CWE-200, CWE-522, CWE-256) or the package handles auth/secrets:

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

2. If active secrets are found, this increases exploit impact — an attacker exploiting the vulnerability could also leverage exposed credentials:
   • Display:

     Secret scanning: <N> active secrets detected — credential exposure compounds this vulnerability

   • Factor into CWSS

     technical_impact

     (+10 if active secrets in affected code paths)
3. For resolved alerts, note the resolution for context

Secret scanning context informs exploit analysis:

• Active leaked secret + exploitable vulnerability = compounded risk (flag in assessment)
• Secrets in the same files as the vulnerable code path = direct exploitation chain
• Push protection bypasses indicate security process gaps — note in assessment

Reading Prior State and SBOMs

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 current vuln ID or any aliases
3. Use Glob for

   .vulnetix/scans/*.cdx.json

   — if SBOMs exist, scan them for the current vuln ID to get additional context (affected components, scanned versions, severity ratings from prior scans). If a memory entry has a

   discovery.sbom

   path, read that file specifically.
4. If a prior entry exists, display to the user:

   Previously seen: <vulnId> — <developer-friendly status> (as of <date>)
   Priority: <P1/P2/P3/P4> (<score>) — "<priority description>"
   Last decision: <developer-friendly decision> — "<reason>"
   Dependabot: <alert state, PR state if available>
   CodeQL: <N alerts matching CWE, states>
   Secret scanning: <N relevant alerts, active/inactive>
   

5. If the user previously decided "Not affected", "Risk acknowledged", or "Handled by platform", remind them:

   "You previously marked this as <status>. Proceeding with exploit analysis for updated intelligence."

6. If prior

   cwss

   data exists, note whether the new analysis changes the priority tier

Writing Updated State

After completing the analysis (Step 9):

1. If no entry exists yet, create one with:

   • status: under_investigation

     ,

     decision.choice: investigating

   • discovery.source: user

     (or

     scan

     /

     hook

     if triggered from those)

   • discovery.sbom

     : path to the relevant

     .vulnetix/scans/*.cdx.json

     file if one was found for this vuln's package/manifest
   • Full

     threat_model

     and

     cwss

     sections from the analysis
2. If an entry exists:
   • Update

     severity

     ,

     safe_harbour

     ,

     threat_model

     , and

     cwss

     with new findings
   • Preserve existing

     aliases

     and merge any newly discovered aliases
   • Do NOT change

     status

     or

     decision

     based on exploit analysis alone — those reflect user decisions, not technical findings
   • Exception: if the exploit analysis reveals the package is not present in the repo at all, set

     status: not_affected

     ,

     justification: component_not_present

     ,

     decision.choice: not-affected

3. Append to

   history

   :

   event: exploit-analysis

   , detail: summary including CWSS score, priority tier, technique count, and key findings
4. After writing, confirm to the user:

   "Vulnerability memory updated: <VULN_ID> — <status> (CWSS <score>, <priority>)"

Workflow

Step 1: Load Vulnerability Memory

Check for and load

.vulnetix/memory.yaml

Step 2: Fetch Exploit Data

Run the Vulnetix VDB exploits command:

vulnetix vdb exploits "$ARGUMENTS" -o json

If the V1 response is empty or lacks detail, try the V2 endpoint:

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

The output structure:

{
  "exploits": [
    {
      "source": "exploitdb",
      "type": "poc",
      "url": "https://exploit-db.com/exploits/12345",
      "date": "2021-12-15",
      "description": "Remote code execution via log4j",
      "verified": true
    },
    {
      "source": "metasploit",
      "type": "exploit-framework",
      "url": "https://github.com/rapid7/metasploit-framework/...",
      "date": "2021-12-20",
      "description": "Log4Shell RCE module",
      "verified": true
    }
  ]
}

Step 3: Parse Exploit Records

Group exploits by source and present a structured summary:

Exploit Intelligence Summary:

Exploit types:

• poc

  — Proof-of-concept code

• exploit-framework

  — Metasploit/Canvas modules

• article

  — Writeups, blog posts

• advisory

  — Security advisories

• patch

  — Patches or fixes

• mitigation

  — Workarounds

Step 4: Fetch Vulnerability Context

Get additional vulnerability details:

vulnetix vdb vuln "$ARGUMENTS" -o json

Extract:

• CVSS scores (base score, vector string — parse AV, AC, PR, UI components)
• EPSS score (exploit prediction probability)
• CISA KEV status (Known Exploited Vulnerabilities catalog)
• CWE ID (weakness type, e.g., CWE-502 Deserialization)
• Affected products/packages and version ranges

Step 5: Analyze Repository Impact

Use Glob and Grep to assess if this vulnerability affects the current repository:

1. Check cached SBOMs first:

   • If

     .vulnetix/memory.yaml

     has a

     manifests

     section, check for recently scanned files (< 24h old by

     last_scanned

     )
   • If a cached SBOM exists at

     sbom_path

     and is recent, read it instead of re-scanning — it contains the full component inventory from the last scan
   • If the pre-commit hook already created a memory entry for this vuln (

     discovery.source: hook

     ), use that context rather than duplicating the discovery — update the existing entry in Step 10

2. Check for affected dependencies:

   • Glob for manifest files (

     package.json

     ,

     requirements.txt

     ,

     go.mod

     , etc.)
   • Read each manifest and check if any affected packages are listed
   • Note the installed version vs. vulnerable version range

3. Search for code patterns matching the CWE:

   • CWE-502 (Deserialization) →

     grep -r "pickle.loads\|yaml.load\|ObjectInputStream" --include="*.py" --include="*.java"

   • CWE-78 (OS Command Injection) →

     grep -r "exec\|system\|subprocess" --include="*.py" --include="*.js"

   • CWE-89 (SQL Injection) →

     grep -r "execute\|query.*\+.*" --include="*.py" --include="*.js"

4. Assess exploit vector reachability:

   • Is the vulnerable dependency direct or transitive?
   • Are the vulnerable code paths actually called in the repo?
   • Is the application exposed to the internet (check for web frameworks, API servers)?

Record findings as:

reachability

exposure

Step 6: PoC Analysis and Local Caching

For each PoC URL from the exploit records, use WebFetch to retrieve the source code.

6a: Ensure

.vulnetix/

Directory and

.gitignore

Before saving any PoC files:

1. Create the

   .vulnetix/pocs/<VULN_ID>/

   directory if it does not exist:

   mkdir -p .vulnetix/pocs/<VULN_ID>
   

2. Check if

   .gitignore

   exists and contains

   .vulnetix/

   . If not, append it:

   # Only if .vulnetix/ is not already in .gitignore
   echo '.vulnetix/' >> .gitignore
   

   This ensures PoC source files are never committed to the repository.

6b: Fetch and Save PoC Source

For each PoC URL:

1. Use WebFetch to retrieve the source code
2. Derive a filename from the URL (e.g.,

   exploit_12345.py

   from ExploitDB ID,

   log4shell_module.rb

   from Metasploit)
3. Use Write to save the fetched content to

   .vulnetix/pocs/<VULN_ID>/<filename>

4. Record the PoC in the

   pocs

   list in

   .vulnetix/memory.yaml

   :

   pocs:
     - url: "https://exploit-db.com/exploits/12345"
       source: exploitdb
       type: poc
       local_path: ".vulnetix/pocs/CVE-2021-44228/exploit_12345.py"
       fetched_date: "<current ISO 8601 UTC timestamp>"
       verified: true
       analysis: "<one-line summary of what it does>"
   

If a PoC was previously fetched (local_path exists from prior invocation), skip re-fetching unless the user requests it. Read the local copy for analysis instead.

6c: Static Analysis

Analyze each PoC statically only — read the saved source to understand:

• What is the attack vector? (network, local, physical)
• What conditions must be met? (authentication required, specific config, user interaction)
• What is the impact? (RCE, data exfiltration, DoS)

Store the one-line analysis summary in the

pocs[].analysis

CRITICAL SECURITY RULE: NEVER EXECUTE PoC CODE

Do NOT:

• Run the PoC script
• Copy PoC commands into a shell
• Download malicious payloads
• Execute any exploit code
• Set executable permissions on saved PoC files

Only analyze the source code to understand the exploit mechanism. The local copies exist solely for offline static reference.

Step 7: Threat Model

Map the vulnerability to MITRE ATT&CK techniques using the CWE, CVSS vector, and exploit analysis from previous steps. Follow the mapping table in "MITRE ATT&CK Mapping" above.

Build the

threat_model

1. Select all applicable ATT&CK technique IDs → store in

   techniques

2. Generate the developer-friendly description for each → store in

   tactics

3. Set

   attack_vector

   from CVSS AV metric (N→network, L→local, A→adjacent, P→physical)
4. Set

   attack_complexity

   from CVSS AC metric (L→low, H→high)
5. Set

   privileges_required

   from CVSS PR metric (N→none, L→low, H→high)
6. Set

   user_interaction

   from CVSS UI metric (N→none, R→required)
7. Set

   reachability

   from Step 5 findings
8. Set

   exposure

   from Step 5 findings

Present to the user (developer language only):

How this could be exploited:
- Attackable from the internet — web app or API is the entry point
- Can run arbitrary commands on your server
Attack requirements: No authentication needed, no user interaction, low complexity
Your exposure: Direct dependency, public-facing deployment

Step 8: Priority Score (CWSS-derived)

Compute the CWSS priority score using the factors and formula defined in "CWSS Priority Scoring" above.

1. Score each factor (0–100) using the data gathered in Steps 2–5
2. Apply weights and compute composite score
3. Determine priority tier (P1–P4)

Present to the user:

Priority: P1 (87.5) — Act now
  Impact: Can run arbitrary commands (100)
  Exploitability: EPSS 0.97, Metasploit module available (95)
  Exposure: Network-accessible, public-facing (100)
  Complexity: Low barrier — no auth, no interaction (90)
  Relevance: Direct dependency, code paths reachable (70)

If the priority tier changed from a prior analysis (loaded in Step 1), flag it:

Priority changed: P3 → P1 (new Metasploit module released, EPSS increased)

Step 9: Risk Assessment

Provide a unified exploitability assessment combining the threat model and priority score:

Rating levels:

• CRITICAL — Active exploitation in the wild, trivial to exploit, repository is vulnerable (typically P1)
• HIGH — Public PoC available, exploit is reliable, vulnerable dependency is present (typically P1–P2)
• MEDIUM — Public PoC available, but repository may not be affected or exploit is complex (typically P2–P3)
• LOW — No public exploits, or vulnerability is not present in repository (typically P3–P4)
• N/A — Insufficient information to assess

Assessment format:

Exploitability Rating: HIGH
Priority: P2 (72.5) — Plan this sprint

How this could be exploited:
- Attackable from the internet — web app or API is the entry point
- Can run arbitrary commands on your server
Attack requirements: No authentication needed, low complexity
Your exposure: Direct dependency, public-facing app

Evidence:
  Metasploit module available (verified exploit)
  EPSS score: 0.89 (89% chance of exploitation within 30 days)
  CISA KEV: Listed (deadline 2024-01-15)
  Repository impact: log4j-core 2.14.1 found in pom.xml (vulnerable version)
  Mitigation: No workaround available, upgrade required

Recommendation: Run `/vulnetix:fix CVE-2021-44228` to get fix options.

If the rating is CRITICAL or HIGH and a fix is available, recommend:

Next step: Run `/vulnetix:fix $ARGUMENTS` for remediation options.

After presenting the assessment, if the user provides a decision (e.g., "we'll accept this risk", "doesn't affect us", "our WAF handles it"), record it immediately using the risk treatment mapping. Ask the user to confirm their reasoning so it can be stored in

decision.reason

Step 10: Update Vulnerability Memory

Update

.vulnetix/memory.yaml

1. Use Read to load the current file (or start fresh if none exists)
2. Create or update the entry with all fields from the analysis:

   • threat_model

     — full object from Step 7

   • cwss

     — full object from Step 8

   • pocs

     — all PoC records from Step 6 (url, source, type, local_path, fetched_date, verified, analysis)

   • severity

     — from VDB data

   • safe_harbour

     — from VDB data or computed

   • aliases

     — merge any newly discovered aliases

   • dependabot

     — if Dependabot data was gathered in Step 1, write the full

     dependabot

     section (alert_number, alert_state, alert_url, dismiss_reason, dismiss_comment, pr_number, pr_state, pr_url, pr_latest_comment, last_checked)

   • code_scanning

     — if CodeQL data was gathered in Step 1, write the full

     code_scanning

     section (alerts[], tool, tool_version, last_checked). Each alert: alert_number, state, rule_id, rule_name, severity, dismissed_reason, dismissed_comment, dismissed_by, file_path, start_line, url

   • secret_scanning

     — if secret scanning data was gathered in Step 1, write the full

     secret_scanning

     section (alerts[], last_checked). Each alert: alert_number, state, secret_type, secret_type_display, resolution, resolution_comment, resolved_by, validity, file_path, url, push_protection_bypassed
3. Append to

   history

   — include GHAS sync notes if alert states changed:

   event: codeql-sync

   or

   event: secret-scanning-sync

4. Update

   manifests

   section — if any manifest files were scanned during Step 5 (not from cache), update or add their entries with

   last_scanned

   ,

   vuln_count

   ,

   scan_source: exploits

   . Do not remove entries added by the hook or other skills.
5. Use Write to save the file
6. Confirm to the user: include GHAS summary in output:

   "GitHub security sync: Dependabot <state>, CodeQL <N alerts>, Secret scanning <N alerts>"

If the user provides a decision during the conversation, record it:

• Map their words to a

  decision.choice

  using the Risk Treatment Decisions table
• Store their actual words (verbatim or close paraphrase) in

  decision.reason

• Set

  status

  ,

  justification

  , and

  action_response

  per the VEX mapping
• Append to

  history

  with

  event: user-decision

• Confirm:

  "Vulnerability memory updated: <VULN_ID> — <developer-friendly status> (<reason summary>)"

Error Handling

• If

  vulnetix vdb exploits

  returns no results, inform the user that no public exploits are known (not necessarily safe — just not publicly documented). Set CWSS exploitability factor to base EPSS only.
• If

  vulnetix vdb vuln

  fails, continue with exploit analysis but note that CVSS/EPSS context is limited. Use available exploit records to estimate factors.
• If manifest files are missing or unreadable, note that impact analysis is inconclusive. Set

  repo_relevance

  to 0 and

  reachability

  to

  unknown

  .
• If

  .vulnetix/memory.yaml

  cannot be written (permissions, etc.), warn the user but do not block the analysis workflow.
• If CWSS factors cannot all be determined, compute with available data and note which factors used defaults. Document this in the history detail.

Important Reminders

1. Never execute PoC code — static analysis only
2. This skill does not modify application code — use

   /vulnetix:fix

   for remediation
3. Always fetch both V1 and V2 exploit data if available
4. EPSS and CISA KEV are strong signals — prioritize accordingly
5. Always update

   .vulnetix/memory.yaml

   after analysis — record threat model, CWSS score, findings, and any user decisions
6. ATT&CK IDs and CWSS internals are never shown to the user — only developer-friendly language
7. Decisions and status changes from exploit analysis alone are limited to technical updates (

   severity

   ,

   safe_harbour

   ,

   threat_model

   ,

   cwss

   ). Status/decision changes require explicit user feedback, with one exception: if the package is confirmed absent from the repo, set

   not-affected

   automatically.
8. When a vulnId is encountered again in a future invocation, the prior

   threat_model

   and

   cwss

   serve as baseline — update them with new findings rather than starting from scratch.