# Cve Analyzer

> CVE Analyzer

- Skill: `uitbreidenos/cve-analyzer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add uitbreidenos/cve-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/uitbreidenos/cve-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: UitbreidenOS (https://skillmd.com/u/uitbreidenos)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/uitbreidenos/cve-analyzer

---

# CVE Analyzer

## When to activate

When you need to assess one or more CVEs across your dependency tree or threat landscape:
- New CVE alerts arrive (NVD feed, Snyk, GitHub Security Advisory)
- Prioritizing patching work for a service or library
- Evaluating whether a third-party package introduces unacceptable risk
- Deciding between upgrading a dependency or switching to an alternative
- Responding to a security disclosure that mentions specific CVE IDs

## When NOT to use

- **Active exploitation in production:** If a live system is already compromised, delegate to incident response first; CVE analysis is a post-incident or preventive activity
- **Zero-day or unconfirmed exploits:** This skill assumes CVE records with severity scores and patch information are available; if the vulnerability is not yet in NVD or CVE databases, escalate to a security researcher
- **Legal/compliance disputes:** If you need to argue a compliance exemption or liability question, involve legal/policy teams — CVE analysis is technical, not binding for regulatory decisions
- **Incomplete vulnerability data:** If the CVE ID is malformed or doesn't exist in public databases, verify the source before proceeding

## Instructions

### 1. Gather CVE Information
Use WebSearch to fetch the latest details from authoritative sources:
- **NVD (nvd.nist.gov):** Official US government CVE database — includes CVSS scores, CWE mappings, and patch references
- **CVE.ORG (cve.mitre.org):** Authoritative CVE records, often with less detail than NVD
- **Vendor advisories:** Search the affected vendor's security page (e.g., Apache, Django, Node.js, Go) for official patches and timelines

For each CVE, extract:
- **ID:** CVE-YYYY-NNNNN format
- **CVSS v3.1 score** (prefer v3.1 over v2; 0–10 scale)
- **Affected versions:** Exact version ranges vulnerable to the issue
- **Fixed version:** When was it patched?
- **CWE category:** Weakness type (e.g., CWE-79 for XSS, CWE-89 for SQL injection)
- **Public exploits:** Are public PoCs available? (CISA Known Exploited Vulnerabilities list is authoritative)
- **Patch status:** Is the vendor actively supporting the affected versions?

### 2. Assess Severity and Context
Score each CVE by impact to your stack:

**CVSS Base Score (technical severity):**
- 9.0–10.0: Critical — patch immediately (hours to 1 day)
- 7.0–8.9: High — patch within 1–2 weeks
- 5.0–6.9: Medium — patch within 30 days; may defer if mitigations exist
- 3.0–4.9: Low — patch in next routine update
- 0.0–2.9: Minimal — monitor but not urgent

**Contextual multipliers:**
- **Exploitability:** Is public exploit code available? (increases urgency 2× for critical/high)
- **Exposure:** Is the vulnerable component internet-facing or trusted-network-only?
- **Wormable vs. requires user action:** Network-propagating worms (Exploitability=Network, User Interaction=None) are more urgent
- **Patch availability:** If vendor is no longer supporting the version (EOL), elevation is required (plan upgrade or replace)
- **Workaround:** Can you disable the feature or add WAF/network filtering in the interim?

### 3. Identify Affected Dependencies
Search your codebase (or dependency tree) for:
- Direct dependencies on the vulnerable package
- Transitive (nested) dependencies — use package manager query tools (e.g., `npm ls <package>`, `pip show <package>`)
- Version overlap: Is your lock file (package-lock.json, poetry.lock, go.sum) pinned to a vulnerable version?

Output a table:

| Dependency | Current Version | Vulnerable Versions | Status |
|---|---|---|---|
| `libfoo` | 2.1.0 | < 2.3.0 | Vulnerable |
| `bar` | 1.5.1 | 1.5.0–1.5.2 | Vulnerable |

### 4. Evaluate Patch Readiness
For each vulnerable dependency:
- **Patch available?** Check the vendor's changelog or GitHub releases — is there a patched version?
- **Breaking changes?** Does the patch require code changes (major version bump, API deprecation)?
- **Transitive blocker?** Are other dependencies pinned to versions incompatible with the patch?
- **CI/CD readiness?** Can you test the patch in staging within 1–2 days?

### 5. Generate Recommendations
Rank options by risk and effort:

**Option A: Patch in place**
- Upgrade to the fixed version (or next stable release)
- Plan: Create a branch, update lock file, run full test suite, deploy to staging for 24–48 hours, merge and release
- Timeline: 3–5 days for low-risk patches; 2–4 weeks for major version bumps

**Option B: Workaround (temporary)**
- Disable the vulnerable feature (e.g., disable auto-update in a package, disable file upload if RCE is via uploads)
- Add network/WAF rules to block exploit patterns
- Suitable for: High CVSS with critical patches not yet available, or patching blocked by transitive dependencies
- Timeline: 1–2 days; review effectiveness weekly

**Option C: Switch library**
- Replace the vulnerable package with a maintained alternative (if available)
- Effort: Medium to High (requires code changes, testing, potential API adaptation)
- Suitable for: EOL packages, repeated critical CVEs in unmaintained libraries, or blocking dependency chains

**Option D: Accept and monitor**
- Leave unpatched if CVSS < 4.0 and exploitability is low (no public PoC, requires local access)
- Document the decision with a security note in code (e.g., inline comment linking to CVE)
- Suitable for: Low-severity issues in trusted components with mitigations already in place
- Timeline: Patch in next quarterly release

### 6. Output Summary
Provide a structured report:

```
CVE Batch Analysis — [Date]
===============================================

CVE-2024-XXXXX: Remote Code Execution in libfoo
CVSS: 9.2 (Critical)
Affected: libfoo < 2.3.0
Current: 2.1.0 (VULNERABLE)
Fixed in: 2.3.0 ✓ Available
Public PoC: Yes (CISA Known Exploited list)
Recommendation: Patch immediately to 2.3.0
Effort: Low (no breaking changes, already tested in staging)
Timeline: Merge by [date]

---

CVE-2024-YYYYY: XSS via User Input in bar
CVSS: 5.3 (Medium)
Affected: bar 1.5.0–1.5.2
Current: 1.5.1 (VULNERABLE)
Fixed in: 1.5.3 ✓ Available
Public PoC: No
Workaround: Input sanitization already in place via [library X]
Recommendation: Patch within 30 days; no immediate action required
Effort: Low
Timeline: Next quarterly release OK

---

[Dependency graph diagram, if needed]
```

## Example

**Scenario:** Your team uses `express@4.17.1` in a Node.js microservice. A critical RCE CVE is disclosed (CVE-2024-12345) affecting Express < 4.19.0.

**Process:**

1. **Gather:** WebSearch "CVE-2024-12345 express" → Find NVD entry: CVSS 9.8, RCE via middleware bypass, public exploit available, fixed in 4.19.0.

2. **Assess:** CVSS 9.8 + public PoC + internet-facing service = **Critical, patch today.** No mitigations possible.

3. **Check dependencies:** Run `npm ls express` → 4.17.1 is in use; no transitive blockers. Pinned in package-lock.json.

4. **Patch readiness:** Express 4.19.0 released 1 week ago, no breaking changes in changelog. Minor security patches only.

5. **Recommend:** Upgrade to 4.19.0, test in staging (4 hours), deploy to production (1 hour).

6. **Output:**
   ```
   CVE-2024-12345: Express Middleware RCE
   CVSS: 9.8 (Critical)
   Current: 4.17.1 → Fixed in 4.19.0 ✓ Available
   Patch effort: Low (no API changes)
   Recommendation: Merge patch PR within 2 hours; deploy to prod immediately
   ```

---

## Tools and Resources

- **NVD Query:** `https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN`
- **CISA Exploited Vulnerabilities List:** Track real-world exploitation of CVEs
- **Snyk Database:** `https://snyk.io/vuln/` — includes remediation steps for specific libraries
- **GitHub Security Advisories:** `https://github.com/advisories` — filtered by ecosystem (npm, pip, etc.)
- **Package manager queries:**
  - Node.js: `npm audit`, `npm ls <package>`
  - Python: `pip show <package>`, `safety check`
  - Go: `go list -m all`, `govulncheck ./...`

---

## Notes

- **Always verify urgency context:** A critical CVE in a transitive dependency you don't use directly is lower priority than a high CVSS in your main app
- **Track decision rationale:** Document why you chose patch, workaround, or accept — helps with future audits
- **Automate where possible:** Use GitHub Dependabot, Snyk, or equivalent for continuous monitoring