Investigate whether a specified CVE can be reached and triggered in a repository. Use for dependency-to-function tracing, parameter-level flow analysis, and evidence-backed reachability reports. Requires repository-specific inspection; does not provide an automatic call-graph engine.
Installs into .claude/skills of the current project.
Are you the author of Cve Reachability?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/sodejm-cve-reachability)
---
name: cve-reachability
description: Investigate whether a specified CVE can be reached and triggered in a repository. Use for dependency-to-function tracing, parameter-level flow analysis, and evidence-backed reachability reports. Requires repository-specific inspection; does not provide an automatic call-graph engine.
---
# CVE reachability
Read [the workflow](references/workflow.md), then use
[the report contract](references/report-contract.md) and
[tool selection guidance](references/tools.md) as needed.
1. Pin repository revision, dirty state, artifact, configuration, entrypoint and
attacker scope. Enumerate supported deployment variants before negative claims.
2. Verify the advisory against affected source, fix diff and actual resolved
component. Record aliases, versions, symbols, vulnerable operations and preconditions.
3. Map direct/transitive paths and actual loaded copies. Trace forward from real
entrypoints and backward from the vulnerable operation. Resolve dispatch and gaps.
4. Map arguments to formal parameters, receiver state, transformations, guards,
aliases and branch constraints. Check joint feasibility of the whole path.
5. Choose only available tools appropriate to the language and build. Record
tool version, command/query, configuration, extraction coverage, exit status,
captured output and interpretation. An installed binary is only available;
a completed command is only executed; neither proves analytical coverage.
6. Validate uncertain paths with manual inspection or bounded runtime tests.
Record what was observed and what remains untested. Never fabricate evidence.
7. Separate code reachability, trigger feasibility and observed impact. Use
confirmed, likely, potential, not_reachable or unresolved as defined in the
workflow. Scope every negative claim. Report limitations and next actions.
8. Run the helper's check command if using its JSON report. A pass checks
structure and evidence integrity only; review the actual evidence separately.
## Local helper
Requires Python 3.11+ and no third-party packages. From this skill directory:
```sh
python3 scripts/reachability-report.py init --repository "[REPOSITORY]" --cve "[CVE]" --component "[VULNERABLE_COMPONENT]" --output "[REPORT_JSON]"
python3 scripts/reachability-report.py evidence --root "[EVIDENCE_ROOT]" --file "[RELATIVE_EVIDENCE_FILE]" --id E1
python3 scripts/reachability-report.py check "[REPORT_JSON]" --evidence-root "[EVIDENCE_ROOT]"
```
Replace every bracketed placeholder. Store reports outside the target checkout.
The evidence command emits a record to paste into `evidence`; it does not edit a
report. Capture advisory snapshots, source, configurations and tool output under
an explicit evidence root. The helper never runs repository code, scans dependencies,
contacts advisory services, constructs call graphs or decides CVE reachability.