/trailmark-variant-neighborhood
Expands one confirmed or suspected vulnerability into a Trailmark graph neighborhood of variant candidates by finding sibling functions, shared callers and callees, common sensitive sinks, common entrypoint paths, interface implementations, override relationships, type/reference
One skill from trailofbits-skills.
shell
$ npx -y skills add trailofbits/skills --skill trailmark-variant-neighborhood --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/trailmark-variant-neighborhood
Context preview
The summary Claude sees to decide when to auto-load this skill.
Expands one confirmed or suspected vulnerability into a Trailmark graph neighborhood of variant candidates by finding sibling functions, shared callers and callees, common sensitive sinks, common entrypoint paths, interface implementations, override relationships, type/reference
Stats
Stars6,343
Forks545
LanguagePython
LicenseCC-BY-SA-4.0
What is in the file
Measured from the trailmark-variant-neighborhood.SKILL.md below.
- 538 words, about a 3 minute read.
- Organized into 11 sections.
- Includes 1 worked example.
- Ends on a checklist you are expected to complete.
- Uses a reference table.
- Ships with 81 other skills in this plugin, and is the 78th longest of them.
SKILL.md
trailmark-variant-neighborhood.SKILL.md
--- name: trailmark-variant-neighborhood description: "Expands one confirmed or suspected vulnerability into a Trailmark graph neighborhood of variant candidates by finding sibling functions, shared callers and callees, common sensitive sinks, common entrypoint paths, interface implementations, override relationships, type/reference neighbors, and structurally similar nodes. Use after one issue is found to seed variant-analysis, semgrep-rule-creator, static-analysis, or manual review with graph-derived candidate locations." allowed-tools: - Bash - Read - Grep - Glob - Write --- # Trailmark Variant Neighborhood Expand one seed issue into graph-derived variant candidates. This skill generates review targets, not confirmed findings. ## When to Use - A finding is confirmed or plausible and variants may exist - The vulnerable pattern depends on call context - The issue involves a shared sink, source, validator, interface, override, trait, hook, handler, adapter, or critical type - The next step is to seed `variant-analysis`, `semgrep-rule-creator`, `static-analysis`, or manual review ## When NOT to Use - No seed issue exists. Use discovery or triage first. - The pattern is purely syntactic and already obvious. Use `semgrep-rule-creator` directly. - The question is exploit-chain composition across multiple findings. Use a composition workflow. - The goal is remediation verification. Use a remediation-review workflow. - The seed cannot be bound to a graph node. ## Rationalizations to Reject | Rationalization | Why It Is Wrong | Required Action | |---|---|---| | "Nearby code means variant" | Proximity is only a candidate reason | Rank it as a review target | | "Only exact same names matter" | Variants often share sinks or preconditions, not names | Expand across callers, callees, interfaces, and types | | "Every candidate is a finding" | This skill outputs candidates for review | Avoid vulnerability claims | | "Unreachable candidates can be ignored completely" | They may become reachable after refactors | Rank lower or list as deferred | | "Graph candidates replace semantic pattern work" | Graph structure finds locations, not root-cause semantics | Hand off to variant-analysis, Semgrep, CodeQL, or manual review | ## Workflow ``` Variant Neighborhood Progress: - [ ] Step 1: Normalize and bind the seed - [ ] Step 2: Expand graph neighborhoods - [ ] Step 3: Rank candidates - [ ] Step 4: Extract variant pattern guidance - [ ] Step 5: Emit handoff packet ``` ### Step 1: Normalize And Bind The Seed Accept finding text, file/line, function name, or output from `trailmark-finding-triage`. Bind the seed to a Trailmark node and record the root cause in plain language. If the seed has no concrete graph binding, stop before inventing variants. ### Step 2: Expand Neighborhoods Use the dimensions in [references/neighborhood-patterns.md](references/neighborhood-patterns.md): - shared callers - shared callees and sinks - entrypoint path neighbors - interface, override, trait, and implementation siblings - file or module cluster neighbors - taint or privilege-boundary peers - type and state-reference neighbors Bound expansion to avoid candidate floods. ### Step 3: Rank Candidates Rank with [references/ranking.md](references/ranking.md). Prioritize entrypoint-reachable, tainted, boundary-adjacent, high-blast-radius, shared sink, same-interface, and close-distance candidates. Penalize test, mock, generated, vendor, unreachable, and trusted-internal-only candidates. ### Step 4: Extract Pattern Guidance Summarize what should be searched for syntactically and what requires semantic review. Identify whether follow-up belongs in: - `variant-analysis` - `semgrep-rule-creator` - `static-analysis` with CodeQL or SARIF-producing tools - manual review ### Step 5: Emit Handoff Packet Use [references/output-format.md](references/output-format.md). Include ranked candidates, inclusion reasons, exclusions, limitations, and the variant-analysis handoff. ## Stop Conditions - No graph binding exists - Candidate count is too high and the root cause is underspecified - Trailmark cannot analyze the target language - The seed is only in test, generated, or vendor code and the user did not say that code is in scope
