vuln-research

Name: vuln-research
Author: briiirussell

111installs36forks

How to install vuln-research?

briiirussell/cybersecurity-skills/vuln-research

$npx -y skills add briiirussell/cybersecurity-skills --skill vuln-research

Installs into the current project.

Summary

Research a specific CVE or vulnerability disclosure end-to-end — what version is affected, is your code reachable, is there a public PoC, is there a patch, what's the exposure window, what's the mitigation if you can't patch immediately. Use when the user mentions 'CVE,' 'vulnera

Files · 1

View on GitHub

SKILL.md

1	# Vuln Research — CVE Deep-Dive and Applicability Assessment
2
3	When a CVE drops, the question isn't "do we have this package?" — `dependency-audit` answers that. The questions are:
4
5	- Is the vulnerable code path actually invoked in our usage?
6	- Is there a public proof-of-concept making this easy to exploit?
7	- Is there a patch? When? What's our exposure window if we can't deploy in 24 hours?
8	- If we can't patch, what's the mitigation?
9	- Is CISA tracking it as actively exploited?
10
11	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).
12
13	## Workflow
14
15	### Step 1 — Pull the canonical sources
16
17	Start with the authoritative descriptions; everything downstream is summarized or sometimes wrong.
18
19	- NVD record — `https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN`
20	- 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
21	- 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)
22	- 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
23	- 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
24
25	### Step 2 — Confirm affected versions
26
27	Vendor advisories sometimes hedge ("affects versions before X"); pin down the exact range.
28
29	- Check the vendor's release notes and the commit history of the fix
30	- 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
31	- For closed-source: the advisory is the only source — verify version comparisons carefully (semver isn't always observed)
32	- For monorepos / re-publishers: confirm the same fix landed in any forks or distributions you depend on
33
34	### Step 3 — Map to your environment
35
36	```bash
37	# Is the package installed at all?
38	npm ls <package> # or yarn why <package>, pnpm why <package>
39	pip show <package> # or pip list \| grep <package>
40	bundle info <gem>
41	go list -m all \| grep <package>
42
43	# What version exactly?
44	# Inspect lockfiles directly — the resolved version is what runs, not the range
45	grep -A1 '"<package>"' package-lock.json
46
47	# Where is it used?
48	# Direct dependency, transitive, dev-only?
49	npm ls <package> --omit=dev # production-reachable?
50	```
51
52	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.
53
54	### Step 4 — Reachability analysis (the high-leverage step)
55
56	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.
57
58	Read the patch. The fix commit shows exactly which function / file / API was vulnerable. Then:
59
60	```bash
61	# Does your code call the vulnerable function directly?
62	grep -rn "vulnerableFunction\\|VulnerableClass" . \
63	--include="*.{js,ts,py,rb,go,java}" \
64	--exclude-dir=node_modules
65
66	# Does the dependency call it internally even if you don't?
67	# Trickier — you have to read the parent's source. For an indirect call:
68	cd node_modules/<package>
69	grep -rn "vulnerableFunction" .
70	```
71
72	Common reachability outcomes:
73
74	- Reachable, direct: You call the bad code. Highest priority — patch or workaround now
75	- Reachable, indirect: Your dependency calls the bad code as part of normal use. Still high priority
76	- 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
77	- Unknown: Document as unknown and patch on the cautious side
78
79	Don't write "not reachable" without showing the work. Future-you will want to revisit when usage changes.
80
81	### Step 5 — Check for public PoCs and active exploitation
82
83	- GitHub: search for `CVE-YYYY-NNNNN` in code and repos — PoCs land here within days of disclosure
84	- CISA KEV: if listed, it's actively exploited in the wild
85	- **Exploit-

People who liked this also viewed

6 picks

Type

vuln-research

111installs36forks

View on GitHub

How to install vuln-research?

briiirussell/cybersecurity-skills/vuln-research

$npx -y skills add briiirussell/cybersecurity-skills --skill vuln-research

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Vuln Research — CVE Deep-Dive and Applicability Assessment
2
3	When a CVE drops, the question isn't "do we have this package?" — `dependency-audit` answers that. The questions are:
4
5	- Is the vulnerable code path actually invoked in our usage?
6	- Is there a public proof-of-concept making this easy to exploit?
7	- Is there a patch? When? What's our exposure window if we can't deploy in 24 hours?
8	- If we can't patch, what's the mitigation?
9	- Is CISA tracking it as actively exploited?
10
11	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).
12
13	## Workflow
14
15	### Step 1 — Pull the canonical sources
16
17	Start with the authoritative descriptions; everything downstream is summarized or sometimes wrong.
18
19	- NVD record — `https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN`
20	- 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
21	- 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)
22	- 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
23	- 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
24
25	### Step 2 — Confirm affected versions
26
27	Vendor advisories sometimes hedge ("affects versions before X"); pin down the exact range.
28
29	- Check the vendor's release notes and the commit history of the fix
30	- 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
31	- For closed-source: the advisory is the only source — verify version comparisons carefully (semver isn't always observed)
32	- For monorepos / re-publishers: confirm the same fix landed in any forks or distributions you depend on
33
34	### Step 3 — Map to your environment
35
36	```bash
37	# Is the package installed at all?
38	npm ls <package> # or yarn why <package>, pnpm why <package>
39	pip show <package> # or pip list \| grep <package>
40	bundle info <gem>
41	go list -m all \| grep <package>
42
43	# What version exactly?
44	# Inspect lockfiles directly — the resolved version is what runs, not the range
45	grep -A1 '"<package>"' package-lock.json
46
47	# Where is it used?
48	# Direct dependency, transitive, dev-only?
49	npm ls <package> --omit=dev # production-reachable?
50	```
51
52	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.
53
54	### Step 4 — Reachability analysis (the high-leverage step)
55
56	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.
57
58	Read the patch. The fix commit shows exactly which function / file / API was vulnerable. Then:
59
60	```bash
61	# Does your code call the vulnerable function directly?
62	grep -rn "vulnerableFunction\\|VulnerableClass" . \
63	--include="*.{js,ts,py,rb,go,java}" \
64	--exclude-dir=node_modules
65
66	# Does the dependency call it internally even if you don't?
67	# Trickier — you have to read the parent's source. For an indirect call:
68	cd node_modules/<package>
69	grep -rn "vulnerableFunction" .
70	```
71
72	Common reachability outcomes:
73
74	- Reachable, direct: You call the bad code. Highest priority — patch or workaround now
75	- Reachable, indirect: Your dependency calls the bad code as part of normal use. Still high priority
76	- 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
77	- Unknown: Document as unknown and patch on the cautious side
78
79	Don't write "not reachable" without showing the work. Future-you will want to revisit when usage changes.
80
81	### Step 5 — Check for public PoCs and active exploitation
82
83	- GitHub: search for `CVE-YYYY-NNNNN` in code and repos — PoCs land here within days of disclosure
84	- CISA KEV: if listed, it's actively exploited in the wild
85	- **Exploit-

People who liked this also viewed

6 picks

Type