Vuln

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:

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:

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

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

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:

Affected Packages:

Repository Impact:

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

References: List top advisory and reference URLs.

Next Steps:

• "Run /vulnetix:exploits $ARGUMENTS for exploit intelligence and threat modeling"
• "Run /vulnetix:fix $ARGUMENTS for fix intelligence and manifest edits"
• "Run /vulnetix:remediation $ARGUMENTS for a context-aware remediation plan"
• "Run /vulnetix:exploits-search --ecosystem <eco> to discover related exploited vulnerabilities"

Step L6: Update Vulnerability Memory

Update .vulnetix/memory.yaml as described in "Writing Updated State" above. If the user provides a decision during the conversation, record it using the risk treatment categories defined in /vulnetix:exploits.