exploitability-validation

Name: exploitability-validation
Author: gadievron

3.4kstars541forks

How to install exploitability-validation?

gadievron/raptor/exploitability-validation

$npx -y skills add gadievron/raptor --skill exploitability-validation

Installs into the current project.

Summary

Multi-stage pipeline for validating that vulnerability findings are real, reachable, and exploitable, preventing wasted effort on hallucinated findings, dead code paths, or findings with unrealistic preconditions.

Files · 1

View on GitHub

SKILL.md

1	# Exploitability Validation Skill
2
3	A multi-stage pipeline for validating that vulnerability findings are real, reachable, and exploitable.
4
5	## Purpose
6
7	Prevents wasted effort on:
8	- Hallucinated findings (file doesn't exist, code doesn't match)
9	- Unreachable code paths (dead code, test-only)
10	- Findings with unrealistic preconditions
11
12	## When to Use
13
14	After scanning produces findings, BEFORE exploit development:
15	1. Scanner finds potential vulnerability
16	2. This skill validates it's real and reachable
17	3. Exploit Feasibility checks binary constraints
18	4. Exploit development proceeds
19
20	---
21
22	## [CONFIG] Configuration
23
24	```yaml
25	models:
26	native: true
27	additional: false # Set true to also run GPT, Gemini
28
29	output_when_additional:
30	display: "agreement: 2/3"
31	threshold: "1/3 is enough to proceed"
32	```
33
34	---
35
36	## [EXEC] Execution Rules
37
38	1. Run the full pipeline end-to-end.
39	2. Solve and fix any issues you encounter, unless you failed five times in a row, or need clarification.
40	3. Run on latest thinking/reasoning model available (verify model name).
41	4. Pipeline must be deterministic - if ran again, results should be the same.
42	5. Validate after writing. Run `libexec/raptor-validate-schema <type> <file>` after each Write. Match the type to what you wrote:
43	- `stage` for any `stage-*.json` file (e.g., `stage-a.json`, `stage-c.json`, `stage-f.json`)
44	- `attack-tree`, `attack-paths`, `attack-surface`, `hypotheses`, `disproven` for the matching working doc
45
46	Fix any errors before proceeding to the next stage.
47	6. No finding may reach Stage D without passing through Stages B and C, even if Stage A produced a successful PoC.
48	7. Do not narrate gate compliance ("GATE-8 satisfied"), schema validation passes ("findings.json: OK"), or stage transitions ("Stage C complete") to the user. Do show substantive work: PoC test output, tool investigations (objdump, checksec), binary protections, hypothesis results, and evidence discovered. Document gate compliance in validation-report.md only. Report schema or pipeline failures immediately.
49	8. Python imports: All `python3 -c` snippets must start with `import sys, os; sys.path.insert(0, os.environ["RAPTOR_DIR"])` before importing from `packages.` or `core.`.
50	9. Build directory: Stage 0 creates `$OUTPUT_DIR/build/`. Compile and run PoCs there, not in the target repo.
51	10b. Sandbox: Run ALL compilation and execution via `libexec/raptor-run-sandboxed <cmd> [args]`. This blocks network, restricts writes, and limits resources. Never run gcc or binaries directly.
52	10. libexec scripts: Run `libexec/` scripts exactly as shown in the prompts — do not prepend `export` commands, do not use absolute paths, do not wrap in additional shell logic. The permission system auto-approves `libexec/raptor-*` commands only when run in this exact form.
53	11. Per-stage JSON files. Write your stage's output to `stage-X.json` (e.g., `stage-a.json`, `stage-b.json`), not to `findings.json`. The prep script merges stage files into findings.json automatically. Do not read or write findings.json directly. Do not use `python3 -c` scripts for JSON — use the Write tool.
54
55	---
56
57	## [GATES] MUST-GATEs
58
59	Rationale: Without these gates, models sample instead of checking all code, hedge with "if" and "maybe" instead of verifying, and miss exploitable findings.
60
61	GATE-1 [ASSUME-EXPLOIT]: Your goal is to discover real exploitable vulnerabilities. If you think something isn't - don't assume. First, investigate under the assumption that it is.
62
63	GATE-2 [STRICT-SEQUENCE]: Strictly follow instructions. If you think or try something else, or a new idea comes up, present the results of that analysis separately at the end. Always display the results of the strict criteria first, and only then display the results of the additional methods, if any.
64
65	GATE-3 [CHECKLIST]: Check pipeline, update checklist, and collect evidence of compliance to present at the end that you successfully executed all actions through these gates.
66
67	GATE-4 [NO-HEDGING]: If your Chain-of-Thought or results include "if", "maybe", "uncertain", "unclear", "could potentially", "may be possible", "depending on", "in theory", "in certain circumstances", or similar - immediately verify the claim. Do not leave unverified.
68
69	GATE-5 [FULL-COVERAGE]: Test the entire code provided (file(s)/code base) against checklist.json, ensuring you checked all functions and lines of code. Do not sample, estimate, or guess.
70
71	GATE-6 [PROOF]: Always provide proof and show the vulnerable code.
72
73	GATE-7 [CONSISTENCY]: Before finalizing each finding, verify that `vuln_type`, `severity`, and `status` are consistent with the `description` and `proof` text. A description

People who liked this also viewed

6 picks

Type

exploitability-validation

3.4kstars541forks

View on GitHub

How to install exploitability-validation?

gadievron/raptor/exploitability-validation

$npx -y skills add gadievron/raptor --skill exploitability-validation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Exploitability Validation Skill
2
3	A multi-stage pipeline for validating that vulnerability findings are real, reachable, and exploitable.
4
5	## Purpose
6
7	Prevents wasted effort on:
8	- Hallucinated findings (file doesn't exist, code doesn't match)
9	- Unreachable code paths (dead code, test-only)
10	- Findings with unrealistic preconditions
11
12	## When to Use
13
14	After scanning produces findings, BEFORE exploit development:
15	1. Scanner finds potential vulnerability
16	2. This skill validates it's real and reachable
17	3. Exploit Feasibility checks binary constraints
18	4. Exploit development proceeds
19
20	---
21
22	## [CONFIG] Configuration
23
24	```yaml
25	models:
26	native: true
27	additional: false # Set true to also run GPT, Gemini
28
29	output_when_additional:
30	display: "agreement: 2/3"
31	threshold: "1/3 is enough to proceed"
32	```
33
34	---
35
36	## [EXEC] Execution Rules
37
38	1. Run the full pipeline end-to-end.
39	2. Solve and fix any issues you encounter, unless you failed five times in a row, or need clarification.
40	3. Run on latest thinking/reasoning model available (verify model name).
41	4. Pipeline must be deterministic - if ran again, results should be the same.
42	5. Validate after writing. Run `libexec/raptor-validate-schema <type> <file>` after each Write. Match the type to what you wrote:
43	- `stage` for any `stage-*.json` file (e.g., `stage-a.json`, `stage-c.json`, `stage-f.json`)
44	- `attack-tree`, `attack-paths`, `attack-surface`, `hypotheses`, `disproven` for the matching working doc
45
46	Fix any errors before proceeding to the next stage.
47	6. No finding may reach Stage D without passing through Stages B and C, even if Stage A produced a successful PoC.
48	7. Do not narrate gate compliance ("GATE-8 satisfied"), schema validation passes ("findings.json: OK"), or stage transitions ("Stage C complete") to the user. Do show substantive work: PoC test output, tool investigations (objdump, checksec), binary protections, hypothesis results, and evidence discovered. Document gate compliance in validation-report.md only. Report schema or pipeline failures immediately.
49	8. Python imports: All `python3 -c` snippets must start with `import sys, os; sys.path.insert(0, os.environ["RAPTOR_DIR"])` before importing from `packages.` or `core.`.
50	9. Build directory: Stage 0 creates `$OUTPUT_DIR/build/`. Compile and run PoCs there, not in the target repo.
51	10b. Sandbox: Run ALL compilation and execution via `libexec/raptor-run-sandboxed <cmd> [args]`. This blocks network, restricts writes, and limits resources. Never run gcc or binaries directly.
52	10. libexec scripts: Run `libexec/` scripts exactly as shown in the prompts — do not prepend `export` commands, do not use absolute paths, do not wrap in additional shell logic. The permission system auto-approves `libexec/raptor-*` commands only when run in this exact form.
53	11. Per-stage JSON files. Write your stage's output to `stage-X.json` (e.g., `stage-a.json`, `stage-b.json`), not to `findings.json`. The prep script merges stage files into findings.json automatically. Do not read or write findings.json directly. Do not use `python3 -c` scripts for JSON — use the Write tool.
54
55	---
56
57	## [GATES] MUST-GATEs
58
59	Rationale: Without these gates, models sample instead of checking all code, hedge with "if" and "maybe" instead of verifying, and miss exploitable findings.
60
61	GATE-1 [ASSUME-EXPLOIT]: Your goal is to discover real exploitable vulnerabilities. If you think something isn't - don't assume. First, investigate under the assumption that it is.
62
63	GATE-2 [STRICT-SEQUENCE]: Strictly follow instructions. If you think or try something else, or a new idea comes up, present the results of that analysis separately at the end. Always display the results of the strict criteria first, and only then display the results of the additional methods, if any.
64
65	GATE-3 [CHECKLIST]: Check pipeline, update checklist, and collect evidence of compliance to present at the end that you successfully executed all actions through these gates.
66
67	GATE-4 [NO-HEDGING]: If your Chain-of-Thought or results include "if", "maybe", "uncertain", "unclear", "could potentially", "may be possible", "depending on", "in theory", "in certain circumstances", or similar - immediately verify the claim. Do not leave unverified.
68
69	GATE-5 [FULL-COVERAGE]: Test the entire code provided (file(s)/code base) against checklist.json, ensuring you checked all functions and lines of code. Do not sample, estimate, or guess.
70
71	GATE-6 [PROOF]: Always provide proof and show the vulnerable code.
72
73	GATE-7 [CONSISTENCY]: Before finalizing each finding, verify that `vuln_type`, `severity`, and `status` are consistent with the `description` and `proof` text. A description

People who liked this also viewed

6 picks

Type