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 neighbors, and struc
By trailofbits · 619 installs
npx skills add trailofbits/skills --skill trailmark-variant-neighborhood
Source repository · Upstream listing
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
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