Vuln Research — CVE Deep-Dive and Applicability Assessment

When a CVE drops, the question isn't "do we have this package?" — dependency-audit answers that. The questions are:

• Is the vulnerable code path actually invoked in our usage?
• Is there a public proof-of-concept making this easy to exploit?
• Is there a patch? When? What's our exposure window if we can't deploy in 24 hours?
• If we can't patch, what's the mitigation?
• Is CISA tracking it as actively exploited?

This skill walks that workflow end-to-end. Pairs with dependency-audit (which surfaces the CVE in the first place) and finding-triage (which closes the disposition loop).

Authorization

Research vulnerabilities in code, dependencies and systems the user owns or is authorized to assess. Reading advisories, patches and public write-ups is fine. Reproduce a vulnerability only in an isolated environment the user controls, never against a live system you aren't authorized to test. Pre-disclosure details stay with the people entitled to them (see Boundaries).

Workflow

Step 1 — Pull the canonical sources

Start with the authoritative descriptions; everything downstream is summarized or sometimes wrong.

• NVD record — https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN
• Vendor advisory — search the vendor's security page; this is usually the most accurate description of which versions are affected and what the fix is
• GitHub Security Advisory — https://github.com/advisories/GHSA-... (often more concise than NVD, sometimes has detail NVD lacks; check the parent project's security tab)
• CISA Known Exploited Vulnerabilities catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog. If the CVE is here, treat as actively exploited — patch within CISA's stated due date
• EPSS score — https://www.first.org/epss/ — Exploit Prediction Scoring System; a 30-day probability of exploitation. Useful tiebreaker between high-CVSS-low-EPSS vs medium-CVSS-high-EPSS

Step 2 — Confirm affected versions

Vendor advisories sometimes hedge ("affects versions before X"); pin down the exact range.

• Check the vendor's release notes and the commit history of the fix
• For OSS projects: find the patch commit (usually mentioned in the advisory) and run git tag --contains <commit> to see which releases include the fix
• For closed-source: the advisory is the only source — verify version comparisons carefully (semver isn't always observed)
• For monorepos / re-publishers: confirm the same fix landed in any forks or distributions you depend on

Step 3 — Map to your environment

# Is the package installed at all?
npm ls <package>           # or yarn why <package>, pnpm why <package>
pip show <package>          # or pip list | grep <package>
bundle info <gem>
go list -m all | grep <package>

# What version exactly?
# Inspect lockfiles directly — the resolved version is what runs, not the range
grep -A1 '"<package>"' package-lock.json

# Where is it used?
# Direct dependency, transitive, dev-only?
npm ls <package> --omit=dev  # production-reachable?

If transitive, walk up the dependency tree until you find which direct dependency is pulling it in. That's where the override / pin / replacement lives.

Step 4 — Reachability analysis (the high-leverage step)

A CVE is only exploitable if you actually call the vulnerable code path. This is where dependency-audit's noise gets cut down to real risk. For a bug in a C, C++ or Rust library, native-code-review traces whether your inputs reach the faulty memory operation.

Read the patch. The fix commit shows exactly which function / file / API was vulnerable. Then:

# Does your code call the vulnerable function directly?
grep -rn "vulnerableFunction\|VulnerableClass" . \
  --include="*.{js,ts,py,rb,go,java}" \
  --exclude-dir=node_modules

# Does the dependency call it internally even if you don't?
# Trickier — you have to read the parent's source. For an indirect call:
cd node_modules/<package>
grep -rn "vulnerableFunction" .

Common reachability outcomes:

• Reachable, direct: You call the bad code. Highest priority — patch or workaround now
• Reachable, indirect: Your dependency calls the bad code as part of normal use. Still high priority
• Not reachable: The bad code is in a feature you don't use (different module, different entry point, different runtime). Lower priority; still recommend patching but won't break SLA
• Unknown: Document as unknown and patch on the cautious side

Don't write "not reachable" without showing the work. Future-you will want to revisit when usage changes.

Step 5 — Check for public PoCs and active exploitation

• GitHub: search for CVE-YYYY-NNNNN in code and repos — PoCs land here within days of disclosure
• CISA KEV: if listed, it's actively exploited in the wild
• Exploit-DB: https://www.exploit-db.com/ — confirmed exploits
• Vendor's security mailing list: sometimes the most recent intel
• GreyNoise: https://www.greynoise.io/ — internet-wide scanning telemetry; if attackers are mass-scanning for this, your exposure window is now
• Twitter / Mastodon security circles — for breaking intel, but verify against canonical sources before acting

EPSS interpretation:

EPSS is empirically tuned; it correlates better with actual exploitation than CVSS does.

Step 6 — Patch / mitigate / accept-risk

Patch (preferred):

• If a patched version exists and you can deploy quickly — upgrade the package, run tests, deploy
• For transitive deps without a direct patch, use overrides (npm) / resolutions (yarn) / pin to force the patched version

Mitigate (when you can't patch):

• Disable the affected feature if your code doesn't need it
• Add a request-level filter (WAF rule, proxy filter) that blocks the known-malicious input pattern — for exploitation that goes through HTTP, this is often deployable in hours
• Network-segment the vulnerable service so it can't be reached from untrusted networks
• Add detection (see siem-detection) so you'll see exploitation attempts even if mitigations fail

Accept risk (only when truly justified):

• Code path is genuinely unreachable in your usage
• Vulnerable component is in an internal-only service with no untrusted input
• Compensating controls reduce exploitation likelihood / impact enough to justify
• See the Accepted Risk disposition in owasp-audit's Output Format — three required fields (why, compensating controls, re-evaluation trigger). No exceptions.

Step 7 — Document and close the loop

After deciding:

• Record the decision in your vuln-tracking system (Jira, Linear, Vanta, etc.)
• For accept-risk: set a re-evaluation date and a calendar reminder
• For patches: confirm via npm ls / lockfile that the patched version is actually deployed (rollouts are not the same as decisions)
• For mitigations: write a runbook entry so the next person knows the mitigation exists and why

Common research traps

• The advisory says "fixed in vX" but the package never released vX — happens with abandoned projects. Use overrides to a known-good fork, or replace the dependency
• The vendor patched it silently — fix landed before the CVE; advisory is for the version before the silent fix. Verify the fix commit is in your version
• The CVE applies to a sibling package you also have — same code, different name (forks, monorepo siblings). Search every package you have for the vulnerable function, not just the named one
• The CVSS is high but the EPSS is low — usually means complex preconditions in the wild. Patch but don't panic
• The CVSS is medium but the EPSS is high — usually means it's already being exploited in mass scans. Treat as urgent
• The PoC needs auth that's hard to get — but your application makes that auth easy to get (signup is open). The "complexity" attacker rating doesn't account for your threat model

Output Format

# Vulnerability Assessment: CVE-YYYY-NNNNN
## Date: [date]
## Assessor: [name]

### Summary
- **Title:** [from advisory]
- **CVSS / EPSS:** [scores]
- **CISA KEV:** [yes / no, and due date if listed]
- **Affected versions:** [exact range]
- **Our version:** [version + how installed]

### Reachability
- **Direct call:** [yes / no — with evidence]
- **Indirect via dependency:** [yes / no — with evidence]
- **Verdict:** Reachable / Not reachable / Unknown

### Exploitation availability
- **Public PoC:** [yes / no — link]
- **Active exploitation:** [yes / no — source]

### Decision
- [ ] Patch (target deploy: [date])
- [ ] Mitigate (controls: [list]; re-evaluate: [date])
- [ ] Accept risk (why / compensating controls / re-eval trigger)

### Action items
| Item | Owner | Deadline |
|------|-------|----------|

### References
[Links to advisory, patch commit, PoC, EPSS, CISA, etc.]

Boundaries

• Research vulnerabilities affecting code, dependencies, or systems the user has authorization for
• Do not develop, weaponize, or distribute exploits — read existing PoCs only for the purpose of assessing applicability
• For internal-only vulnerabilities or pre-disclosure intel, do not redistribute without authorization
• If research surfaces an unreported vulnerability in someone else's code, follow responsible disclosure — do not publish, do not exploit
• Refuse requests to use CVE research output to attack systems

References

• NVD (National Vulnerability Database)
• CISA Known Exploited Vulnerabilities Catalog
• GitHub Security Advisories Database
• EPSS (Exploit Prediction Scoring System) — FIRST.org
• MITRE CVE — cve.mitre.org (now redirects to cve.org)
• Exploit-DB
• GreyNoise — internet scanning telemetry
• "Patch Tuesday" / vendor-specific cadences for context on disclosure timing
• Project Zero disclosure policy — the reference for responsible disclosure timelines