analyze-cve

Name: analyze-cve
Author: ShulkwiSEC

18stars5forks

How to install analyze-cve?

shulkwisec/bb-huge/analyze-cve

$npx -y skills add ShulkwiSEC/bb-huge --skill analyze-cve

Installs into the current project.

Summary

Analyzes CVE vulnerabilities in project dependencies with code path tracing and PoC generation for Burp Suite. Traces vulnerable code from user input to sink, assesses exploitability, and generates HTTP requests for testing.

Files · 1

View on GitHub

SKILL.md

1	# CVE Vulnerability Analysis Workflow
2
3	## Purpose
4
5	This workflow provides a structured methodology for analyzing whether a CVE affecting a project dependency poses a real security risk. It:
6	- Traces vulnerable code paths in your application
7	- Analyzes dataflow from user input to vulnerable functions
8	- Creates proof-of-concept HTTP requests for Burp Suite validation
9
10	Language/Framework Agnostic: Works with Python, Node.js, Java, Go, Ruby, PHP, and more.
11
12	## Important Assumptions
13
14	### Trust User-Provided Information
15	- The user has already verified the CVE and version through SCA tools (Snyk, Dependabot, GitHub Security, etc.)
16	- Trust the dependency name, version, and CVE information provided - do not require verification
17	- Do not fail if dependency files are missing or incomplete - focus on code analysis
18	- Do not stop if packages aren't installed locally - many projects use private artifactories or complex build processes
19	- Your job is to analyze CODE USAGE, not verify dependency versions
20
21	### What This Means
22	- If the user says "analyze CVE-X in package Y version Z", proceed with the analysis
23	- Look for usage of the vulnerable code in the application
24	- If you can't find dependency files, document this but continue the analysis
25	- If the package isn't locally installed, work with the CVE description to understand what to look for
26
27	---
28
29	## CHAIN COMMITMENTS — DECLARE BEFORE STARTING
30
31	Read this before executing any workflow phase. Commit to MANDATORY chains before your first tool call.
32
33	\| Trigger \| Chain \| Mandatory? \| Claude Code \| opencode \|
34	\|---------\|-------\|-----------\|-------------\|---------\|
35	\| After `session(action="complete")` (confirmed exploitable finding) \| `/gh-export` \| OPTIONAL — user request only \| `Skill(skill="gh-export")` \| `cat ~/.config/opencode/commands/gh-export.md` \|
36	\| Exploitable CVE confirmed + live target available \| `/web-exploit` \| OPTIONAL \| `Skill(skill="web-exploit")` \| `cat ~/.config/opencode/commands/web-exploit.md` \|
37	\| Exploitable CVE confirmed + Metasploit module available \| `/metasploit` \| OPTIONAL \| `Skill(skill="metasploit")` \| `cat ~/.config/opencode/commands/metasploit.md` \|
38
39
40
41	Logging: Before invoking any skill above, call `session(action="set_skill", options={"skill":"<name>","reason":"<why>","chained_from":"<this-skill>"})` — this writes the SKILL_CHAIN entry to pentest.log.
42
43	---
44
45	## Analysis Workflow
46
47	### Phase 1: Vulnerability Context Gathering
48
49	1. Read CVE Details
50	- Fetch and analyze CVE from provided link
51	- Identify vulnerable function/method/class
52	- Understand attack vector and vulnerability type
53	- Note affected version range
54	- Document any PoC or exploit details
55	- Search Exploit-DB for existing exploits: `kali(command="searchsploit <product> <version>")`
56
57	2. Trust User-Provided Version Information
58	- IMPORTANT: Trust the user's input about dependency version and CVE applicability
59	- User has already verified this information through SCA tools (Snyk, Dependabot, etc.)
60	- Optional: If dependency files are available, you MAY verify the version:
61	- Python: `pyproject.toml`, `requirements.txt`, `Pipfile`
62	- Node.js: `package.json`, `package-lock.json`
63	- Java: `pom.xml`, `build.gradle`, `build.gradle.kts`
64	- Go: `go.mod`
65	- Ruby: `Gemfile`, `Gemfile.lock`
66	- PHP: `composer.json`
67	- DO NOT stop analysis if:
68	- Dependency files are missing or inaccessible
69	- The package is not found in lock files
70	- Private artifactories require authentication
71	- Dependencies are not locally installed
72	- Always proceed to Phase 2 - focus on analyzing whether the vulnerable code is actually used
73
74	### Phase 2: Code Path Analysis
75
76	3. Understand Vulnerable Function from CVE
77	- Primary source: Use the CVE description to identify the vulnerable function/method/class
78	- Document the vulnerable component (e.g., `jackson-databind.readValue()`, `pymupdf.Document.open()`)
79	- Note: You typically won't have access to the dependency source code
80	- Optional: If dependency is installed locally, you may inspect it for additional context
81	- Key information needed:
82	- Vulnerable module/package name
83	- Vulnerable function/method/class name
84	- Basic understanding of what triggers the vulnerability
85
86	4. Trace Usage in Application
87	- Search codebase for:
88	- Imports of vulnerable module (document these as evidence)
89	- Instantiation of vulnerable classes
90	- Calls to vulnerable functions
91	- Document all usage locations with file:line references
92	- IMPORTANT: For each file using the vulnerable code, cap

People who liked this also viewed

6 picks

Type

analyze-cve

18stars5forks

View on GitHub

How to install analyze-cve?

shulkwisec/bb-huge/analyze-cve

$npx -y skills add ShulkwiSEC/bb-huge --skill analyze-cve

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# CVE Vulnerability Analysis Workflow
2
3	## Purpose
4
5	This workflow provides a structured methodology for analyzing whether a CVE affecting a project dependency poses a real security risk. It:
6	- Traces vulnerable code paths in your application
7	- Analyzes dataflow from user input to vulnerable functions
8	- Creates proof-of-concept HTTP requests for Burp Suite validation
9
10	Language/Framework Agnostic: Works with Python, Node.js, Java, Go, Ruby, PHP, and more.
11
12	## Important Assumptions
13
14	### Trust User-Provided Information
15	- The user has already verified the CVE and version through SCA tools (Snyk, Dependabot, GitHub Security, etc.)
16	- Trust the dependency name, version, and CVE information provided - do not require verification
17	- Do not fail if dependency files are missing or incomplete - focus on code analysis
18	- Do not stop if packages aren't installed locally - many projects use private artifactories or complex build processes
19	- Your job is to analyze CODE USAGE, not verify dependency versions
20
21	### What This Means
22	- If the user says "analyze CVE-X in package Y version Z", proceed with the analysis
23	- Look for usage of the vulnerable code in the application
24	- If you can't find dependency files, document this but continue the analysis
25	- If the package isn't locally installed, work with the CVE description to understand what to look for
26
27	---
28
29	## CHAIN COMMITMENTS — DECLARE BEFORE STARTING
30
31	Read this before executing any workflow phase. Commit to MANDATORY chains before your first tool call.
32
33	\| Trigger \| Chain \| Mandatory? \| Claude Code \| opencode \|
34	\|---------\|-------\|-----------\|-------------\|---------\|
35	\| After `session(action="complete")` (confirmed exploitable finding) \| `/gh-export` \| OPTIONAL — user request only \| `Skill(skill="gh-export")` \| `cat ~/.config/opencode/commands/gh-export.md` \|
36	\| Exploitable CVE confirmed + live target available \| `/web-exploit` \| OPTIONAL \| `Skill(skill="web-exploit")` \| `cat ~/.config/opencode/commands/web-exploit.md` \|
37	\| Exploitable CVE confirmed + Metasploit module available \| `/metasploit` \| OPTIONAL \| `Skill(skill="metasploit")` \| `cat ~/.config/opencode/commands/metasploit.md` \|
38
39
40
41	Logging: Before invoking any skill above, call `session(action="set_skill", options={"skill":"<name>","reason":"<why>","chained_from":"<this-skill>"})` — this writes the SKILL_CHAIN entry to pentest.log.
42
43	---
44
45	## Analysis Workflow
46
47	### Phase 1: Vulnerability Context Gathering
48
49	1. Read CVE Details
50	- Fetch and analyze CVE from provided link
51	- Identify vulnerable function/method/class
52	- Understand attack vector and vulnerability type
53	- Note affected version range
54	- Document any PoC or exploit details
55	- Search Exploit-DB for existing exploits: `kali(command="searchsploit <product> <version>")`
56
57	2. Trust User-Provided Version Information
58	- IMPORTANT: Trust the user's input about dependency version and CVE applicability
59	- User has already verified this information through SCA tools (Snyk, Dependabot, etc.)
60	- Optional: If dependency files are available, you MAY verify the version:
61	- Python: `pyproject.toml`, `requirements.txt`, `Pipfile`
62	- Node.js: `package.json`, `package-lock.json`
63	- Java: `pom.xml`, `build.gradle`, `build.gradle.kts`
64	- Go: `go.mod`
65	- Ruby: `Gemfile`, `Gemfile.lock`
66	- PHP: `composer.json`
67	- DO NOT stop analysis if:
68	- Dependency files are missing or inaccessible
69	- The package is not found in lock files
70	- Private artifactories require authentication
71	- Dependencies are not locally installed
72	- Always proceed to Phase 2 - focus on analyzing whether the vulnerable code is actually used
73
74	### Phase 2: Code Path Analysis
75
76	3. Understand Vulnerable Function from CVE
77	- Primary source: Use the CVE description to identify the vulnerable function/method/class
78	- Document the vulnerable component (e.g., `jackson-databind.readValue()`, `pymupdf.Document.open()`)
79	- Note: You typically won't have access to the dependency source code
80	- Optional: If dependency is installed locally, you may inspect it for additional context
81	- Key information needed:
82	- Vulnerable module/package name
83	- Vulnerable function/method/class name
84	- Basic understanding of what triggers the vulnerability
85
86	4. Trace Usage in Application
87	- Search codebase for:
88	- Imports of vulnerable module (document these as evidence)
89	- Instantiation of vulnerable classes
90	- Calls to vulnerable functions
91	- Document all usage locations with file:line references
92	- IMPORTANT: For each file using the vulnerable code, cap

People who liked this also viewed

6 picks

Type