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 to track findings. Use /vulnetix:fix for remediation.

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 — attack path:

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")
'

Data processing — tooling cascade (strict order):

• 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.
• 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 '...'

• 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 before use. If all programmatic tools are unavailable, perform CWSS calculations manually and present results as markdown with Mermaid diagrams.

CWE pattern matching (Step 5 grep commands for code analysis) uses the Grep tool directly — these are not data processing and are exempt from this cascade.

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 and /vulnetix:package-search and tracks all vulnerability encounters, threat models, priority scores, and user decisions across sessions.

Schema

The canonical schema is defined in /vulnetix:fix. This skill adds and maintains the threat_model and cwss fields on each vulnerability entry. The full per-vulnerability entry structure:

# .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. Always communicate to the user using the developer-friendly language in threat_model.tactics. Never surface ATT&CK IDs, tactic names, or technique names to the user — those are internal metadata only.

| ATT&CK ID | ATT&CK Name | Developer Language (store in tactics) |
|---|---|---|
| T1190 | Exploit Public-Facing Application | "Attackable from the internet — web app or API is the entry point" |
| T1195.001 | Supply Chain: Compromise Software Dependencies | "Compromised dependency — malicious code injected via a package you use" |
| T1195.002 | Supply Chain: Compromise Software Supply Chain | "Tampered build or distribution — the package source or registry was compromised" |
| T1059 | Command and Scripting Interpreter | "Can run arbitrary commands on your server" |
| T1203 | Exploitation for Client Execution | "Exploitable via user interaction — opening a file or clicking a link triggers it" |
| T1068 | Exploitation for Privilege Escalation | "Can escalate to admin or root access" |
| T1210 | Exploitation of Remote Services | "Exploitable over the network between services" |
| T1212 | Exploitation for Credential Access | "Can steal credentials — passwords, tokens, or keys" |
| T1005 | Data from Local System | "Can read sensitive data — files, env vars, or secrets on the host" |
| T1499 | Endpoint Denial of Service | "Can crash your service or exhaust resources" |
| T1565 | Data Manipulation | "Can tamper with, corrupt, or inject data" |

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

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:

| Factor | Weight | Source | How to score (0–100) |
|---|---|---|---|
| Technical Impact | 25% | CVSS impact sub-score, CWE consequence | RCE → 100, Priv escalation → 90, Data exfil → 85, Data tampering → 70, DoS → 40, Info disclosure → 30 |
| Exploitability | 25% | EPSS score, exploit records, CISA KEV | Base: EPSS × 100. Adjustments: Metasploit module → +20, Verified PoC → +15, CISA KEV → +15. Cap at 100. |
| Exposure | 15% | CVSS attack vector + repo deployment analysis | Network + public-facing → 100, Network + internal → 70, Adjacent → 50, Local → 30, Physical → 10 |
| Complexity | 15% | CVSS attack complexity, privileges, user interaction (inverted: higher = easier to exploit) | Low complexity + no auth + no interaction → 100. Each: high complexity → −30, auth required → −25, interaction required → −20. Floor at 0. |
| Repo Relevance | 20% | Dependency analysis from Step 5 | Direct dep + reachable code → 100, Direct dep + unknown reachability → 70, Transitive dep → 40, Not found → 0 |

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

| Priority | Score Range | Developer Language |
|---|---|---|
| P1 | ≥ 80 | "Act now — actively exploited, trivial to attack, you're exposed" |
| P2 | 60–79 | "Plan this sprint — public exploits exist, you're likely affected" |
| P3 | 40–59 | "Schedule it — known issue, limited exploitability or exposure" |
| P4 | < 40 | "Track it — low risk, no known exploitation, limited exposure" |

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.

| Treatment | Decision Choice | Developer Language | When to use |
|---|---|---|---|
| Mitigate | fix-applied | "Fix applied" | Upgraded, patched, or code fixed |
| Mitigate | mitigated | "Workaround in place" | Config change, input validation, selective import |
| Accept | risk-accepted | "Risk acknowledged, shipping as-is" | Consciously accepting with documented reason |
| Accept | deferred | "Fix planned for later" | Will address, but not right now |
| Avoid | risk-avoided | "Removed the exposure" | Dependency removed, feature disabled, not deployed |
| Avoid | inlined | "Replaced with own code" | Dependency replaced with first-party implementation |
| Avoid | not-affected | "Not affected" | Vuln doesn't apply — package absent, code unreachable |
| Transfer | risk-transferred | "Handled by platform or infrastructure" | WAF, CDN, runtime sandbox, managed service handles it |

VEX status mapping (internal → developer language, same as /vulnetix:fix):

| VEX Status | Developer Language |
|---|---|
| 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 current vuln ID to enrich exploit analysis context. The canonical Dependabot-to-VEX mapping is defined in /vulnetix:fix. This skill uses it read-only — it records Dependabot state in the memory file but does not change alert states on GitHub.

During Step 1 (Load Vulnerability Memory):

• 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'

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

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

• 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'

• Update the dependabot section in the memory entry during Step 10

• 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 CLI is available, query code scanning alerts that correlate with this vulnerability by CWE match. The canonical state-to-VEX mapping is defined in /vulnetix:fix.

During Step 1 (Load Vulnerability Memory):

• 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"))]'

• If matching CodeQL alerts are found:

• Check for autofix availability on each open alert:

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

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 CLI is available, check for secret scanning alerts relevant to this vulnerability's context. The canonical state-to-VEX mapping is defined in /vulnetix:fix.

During Step 1 (Load Vulnerability Memory):

• 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

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

• For resolved alerts, note the resolution for context

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

• 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 current vuln ID or any aliases
• 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.
• 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>

• If an entry exists:

• Append to history: event: exploit-analysis, detail: summary including CWSS score, priority tier, technique count, and key findings
• 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 as described in "Reading Prior State" above. Display any prior state to the user before proceeding.

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:

| Source | Type | Date | Description | Link |
|--------|------|------|-------------|------|
| ... | ... | ... | ... | ... |

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:

• Check cached SBOMs first:

• Check for affected dependencies:

• Search for code patterns matching the CWE:

• Assess exploit vector reachability:

Record findings as: reachability (direct/transitive/not-found/unknown) and exposure (public-facing/internal/local-only/unknown) for the threat model.

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:

• Create the .vulnetix/pocs/<VULN_ID>/ directory if it does not exist:

   mkdir -p .vulnetix/pocs/<VULN_ID>

• Check if .gitignore exists and contains .vulnetix/. If not, append it:

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

#### 6b: Fetch and Save PoC Source

For each PoC URL:

• Use WebFetch to retrieve the source code
• Derive a filename from the URL (e.g., exploit_12345.py from ExploitDB ID, log4shell_module.rb from Metasploit)
• Use Write to save the fetched content to .vulnetix/pocs/<VULN_ID>/<filename>
• 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)

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

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

• Select all applicable ATT&CK technique IDs → store in techniques
• Generate the developer-friendly description for each → store in tactics
• Set attack_vector from CVSS AV metric (N→network, L→local, A→adjacent, P→physical)
• Set attack_complexity from CVSS AC metric (L→low, H→high)
• Set privileges_required from CVSS PR metric (N→none, L→low, H→high)
• Set user_interaction from CVSS UI metric (N→none, R→required)
• Set reachability from Step 5 findings
• Set exposure from Step 5 findings

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.

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

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

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 as described in "Writing Updated State" above.

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

• Append to history — include GHAS sync notes if alert states changed: event: codeql-sync or event: secret-scanning-sync
• 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.
• Use Write to save the file
• Confirm to the user: include GHAS summary in output: "GitHub security sync: Dependabot <state>, CodeQL <N alerts>, Secret scanning <N alerts>"

• 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

• Never execute PoC code — static analysis only
• This skill does not modify application code — use /vulnetix:fix for remediation
• Always fetch both V1 and V2 exploit data if available
• EPSS and CISA KEV are strong signals — prioritize accordingly
• Always update .vulnetix/memory.yaml after analysis — record threat model, CWSS score, findings, and any user decisions
• ATT&CK IDs and CWSS internals are never shown to the user — only developer-friendly language
• 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.
• 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.