vuln

What this skill does

# Vulnetix Vulnerability Lookup Skill

This skill serves two purposes based on the argument provided:

- **Vuln ID argument** (CVE-*, GHSA-*, PYSEC-*, etc.) --> retrieves detailed vulnerability intelligence and assesses its impact against the current repository
- **Package name argument** (express, lodash, log4j-core, etc.) --> lists all known vulnerabilities for that package and identifies which ones affect your installed version

**This skill does not modify application code** -- it only updates `.vulnetix/memory.yaml` to track findings. Use `/vulnetix:fix` for remediation, `/vulnetix:exploits` for exploit analysis, or `/vulnetix:remediation` for a context-aware remediation plan.

## Argument Detection

Determine the mode from the argument:

**Vuln lookup mode** -- argument matches any known vulnerability identifier pattern:
- `CVE-*` (e.g., CVE-2021-44228)
- `GHSA-*` (e.g., GHSA-jfh8-3a1q-hjz9)
- `PYSEC-*`, `GO-*`, `RUSTSEC-*`, `EUVD-*`, `OSV-*`, `GSD-*`, `VDB-*`, `GCVE-*`
- `SNYK-*`, `ZDI-*`, `MSCVE-*`, `MSRC-*`, `RHSA-*`, `TALOS-*`, `EDB-*`
- `WORDFENCE-*`, `PATCHSTACK-*`, `MFSA*`, `JVNDB-*`, `CNVD-*`, `BDU:*`, `HUNTR-*`
- `DSA-*`, `DLA-*`, `USN-*`, `ALSA-*`, `RLSA-*`, `MGASA-*`, `OPENSUSE-*`, `FreeBSD-*`, `BIT-*`

The VDB accepts **78+ identifier formats** in total.

**Package vulns mode** -- argument does not match any vuln-id pattern. Treat it as a package name.

If ambiguous, prefer vuln lookup mode (vuln IDs are more structured). If the vuln lookup returns an error or empty response, fall back to package vulns mode automatically.

## 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:exploits-search`, and `/vulnetix:remediation`.

### Schema

The canonical schema is defined in `/vulnetix:fix`. This skill creates or updates base vulnerability fields: `aliases`, `package`, `ecosystem`, `discovery`, `versions`, `severity`, `safe_harbour`, and `status`. It does not modify `threat_model` or `cwss` (owned by `/vulnetix:exploits`).

### 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
3. Use **Glob** for `.vulnetix/scans/*.cdx.json` -- if CycloneDX SBOMs exist from prior scans, cross-reference for additional context
4. **Vuln lookup mode**: check for the vuln ID or any aliases in memory. If found:
   ```
   Previously seen: <vulnId> -- <developer-friendly status> (as of <date>)
   Priority: <P1/P2/P3/P4> (<score>) -- "<priority description>" (if cwss data exists)
   Last decision: <developer-friendly decision> -- "<reason>"
   Dependabot: <alert state, PR state if available>
   ```
5. **Package vulns mode**: find all entries referencing the queried package name. If found:
   ```
   Known history for <package>:
   - CVE-2021-44228 -- Fixed (2024-01-15), P1 (87.5)
   - CVE-2023-1234 -- Investigating (2024-03-01)
   ```

### Writing Updated State

**Vuln lookup mode (after Step L6):**

1. If no entry exists, create one with `status: under_investigation`, `decision.choice: investigating`, `discovery.source: user`
2. If an entry exists, merge aliases, update `severity` and `safe_harbour` if newer. **Do NOT change `status` or `decision`.**
3. Append to `history`: `event: lookup`

**Package vulns mode (after Step P7):**

For each vulnerability that **affects the installed version** and is **not already tracked**:
1. Create a minimal stub entry with `status: under_investigation`, `decision.choice: investigating`, `discovery.source: scan`, `decision.reason: "Discovered via /vulnetix:vuln <package>"`
2. Append to `history`: `event: discovered`

For existing entries, do **not** change `status` or `decision` -- only update `severity` if newer.

### VEX Status Mapping

Use developer-friendly language when surfacing status:
- `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 to enrich the output.

**Vuln lookup mode:** Query alerts matching the vuln ID:
```bash
gh api repos/{owner}/{repo}/dependabot/alerts --jq '[.[] | select(.security_advisory.cve_id == "'"$ARGUMENTS"'" or .security_advisory.ghsa_id == "'"$ARGUMENTS"'")] | first'
```

**Package vulns mode:** Query alerts for the package:
```bash
gh api repos/{owner}/{repo}/dependabot/alerts?state=open --jq '[.[] | select(.dependency.package.name == "'"$PACKAGE_NAME"'")] | length'
```

---

## Vuln Lookup Mode Workflow

Use this workflow when the argument matches a vulnerability identifier pattern.

### Step L1: Load Vulnerability Memory

Check for and load `.vulnetix/memory.yaml` as described in "Reading Prior State" above. Display any prior state before proceeding.

### Step L2: Fetch Vulnerability Data

```bash
vulnetix vdb vuln "$ARGUMENTS" -o json
```

**CLI Reference** (from `vulnetix vdb vuln` docs):
- Accepts any of the 78+ identifier formats
- `-o json` returns machine-readable output
- Response includes: identifier and aliases, description, published/modified dates, CVSS scores (v2, v3, v4), references/advisories, affected products/versions, EPSS probability, KEV status

Extract: identity, aliases, description, dates, CVSS vectors/scores, EPSS, KEV status/deadline, CWE IDs, affected products with version ranges and fixed versions, reference URLs.

### Step L3: Enrich with Metrics

```bash
vulnetix vdb metrics "$ARGUMENTS" -o json
```

**CLI Reference** (from `vulnetix vdb metrics` docs):
- Returns structured metric objects by type (CVSS v2, v3.1, v4, EPSS, etc.)
- Each metric includes: source, type, score, vector string, timestamp

Merge with Step L2 data. If this call fails, continue with Step L2 data alone.

### Step L4: Analyze Repository Impact

Use **Glob** and **Grep** to assess repo impact:

1. **Detect manifest files:**
   - `package.json`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` --> **npm**
   - `go.mod`, `go.sum` --> **go**
   - `Cargo.toml`, `Cargo.lock` --> **cargo**
   - `requirements.txt`, `pyproject.toml`, `Pipfile`, `poetry.lock`, `uv.lock` --> **pypi**
   - `Gemfile`, `Gemfile.lock` --> **rubygems**
   - `pom.xml`, `build.gradle`, `gradle.lockfile` --> **maven**
   - `composer.json`, `composer.lock` --> **packagist**

2. **Search for affected packages** from VDB response using **Grep** in manifests/lockfiles
3. **Determine installed version** (lockfile --> manifest --> installed artifacts --> unknown). Report source transparently.
4. **Assess dependency relationship** -- direct vs transitive, whether installed version is in vulnerable range
5. **Cross-reference CycloneDX SBOMs** in `.vulnetix/scans/*.cdx.json`

### Step L5: Present Structured Summary

**Identity:**
```
<Vuln ID> (<alias1>, <alias2>, ...)
<Description -- first 2-3 sentences>
Published: <date>  |  Modified: <date>
```

**Severity Table:**

| Metric | Score | Vector |
|--------|-------|--------|
| CVSS v3.1 | 10.0 (Critical) | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| CVSS v4.0 | 10.0 (Critical) | ... |
| EPSS | 0.97 (97% chance of exploitation within 30 days) | -- |
| CISA KEV | Listed (deadline: YYYY-MM-DD) | -- |

**Affected Packages:**

| Package | Ecosystem | Vulnerable Range | Fixed In |
|---------|-----------|-----------------|----------|
| log4j-core | maven | < 2.17.1 | 2.17.1 |

**Repository Impact:**

| Package | Installed Version | Source | Affected? | Relationship |
|---------|------------------|--------|-----------|-------------|
| log4j-core | 2.14.1 | lockfile: pom.xml | Yes (in range) | Direct |

If no affected packages found: **"No affected packages detected in this repository."**

**References:** List top advisory and reference URLs.

**Next Steps:**
- "Run `/vulnetix:exploits