AutoGineer
Generated banner for Trailmark Variant Neighborhood
Generated logo for Trailmark Variant Neighborhood

Trailmark Variant Neighborhood

Trail of BitsOfficialPublished by Trail of Bits

  • Skill
  • Research and analysis
  • Security
  • CC-BY-SA-4.0
  • No issues found
Download ZIP

From the author

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.
— the description by Trail of Bits

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Trailmark Variant Neighborhood is a research-analysis skill that takes a confirmed or suspected vulnerability and uses graph-based analysis to identify related code locations. By exploring dimensions such as shared callers, callees, interface implementations, and entrypoint paths, it generates a list of candidate targets for further investigation. This skill is designed to seed subsequent variant analysis, static analysis, or manual review processes, helping security practitioners identify potential patterns of vulnerability across a codebase.

What it does

  • Binds a seed vulnerability to a specific graph node.
  • Expands the search to related code using graph dimensions like shared sinks and callers.
  • Ranks candidate locations based on reachability and risk factors.
  • Extracts pattern guidance for follow-up analysis.
  • Produces a structured handoff packet for security review tools.

When to use it

  • After confirming a vulnerability and suspecting similar issues exist elsewhere.
  • When a vulnerability pattern is tied to specific call contexts or shared interfaces.
  • When preparing to perform variant analysis or create automated detection rules.
  • When the issue involves critical components like sinks, sources, or privilege boundaries.

Advantages

  • Systematically identifies potential variants using graph relationships.
  • Reduces manual effort by prioritizing candidates based on reachability and risk.
  • Provides clear context for why specific code locations were flagged as candidates.
  • Integrates with downstream security workflows like Semgrep or CodeQL.

Usage examples

“I have a confirmed SQL injection in user_controller.py. Use trailmark-variant-neighborhood to find other potential locations.”
The agent binds the vulnerability to the graph, identifies shared sinks and callers, and provides a ranked list of candidate functions for manual review.
“Analyze the neighborhood for this insecure file upload function to seed my next Semgrep rule.”
The agent generates a handoff packet containing the specific syntax to keep, abstract patterns to search for, and a list of candidate locations to test the rule against.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/trailofbits/trailmark-variant-neighborhood/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip trailmark-variant-neighborhood.zip -d .agents/skills

Documentation by Trail of Bits

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

RationalizationWhy It Is WrongRequired Action
"Nearby code means variant"Proximity is only a candidate reasonRank it as a review target
"Only exact same names matter"Variants often share sinks or preconditions, not namesExpand across callers, callees, interfaces, and types
"Every candidate is a finding"This skill outputs candidates for reviewAvoid vulnerability claims
"Unreachable candidates can be ignored completely"They may become reachable after refactorsRank lower or list as deferred
"Graph candidates replace semantic pattern work"Graph structure finds locations, not root-cause semanticsHand 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:

  • 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. 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. 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

Files

references/output-format.md

Output Format

Use Markdown unless the user asks for JSON.

# Trailmark Variant Neighborhood

## Seed

- Finding:
- Bound node:
- Root cause:

## Candidate Summary

| Rank | Candidate | Reason | Reachability | Confidence |
|---|---|---|---|---|

## Graph Neighborhoods

### Shared Callers
### Shared Callees / Sinks
### Entrypoint Path Neighbors
### Interface Or Implementation Siblings
### Type / State Neighbors

## Variant-Analysis Handoff

- Root cause:
- Keep specific:
- Abstract:
- Suggested searches:
- Suggested CodeQL/Semgrep direction:

## Exclusions And Limitations

Wording Requirements

  • Say "candidate" or "review target", not "variant vulnerability".

  • Explain why each candidate was included.

  • Separate graph similarity from semantic root-cause similarity.

  • Include exclusions so reviewers understand why obvious nearby code was not prioritized.

Handoff Guidance

For variant-analysis, provide:

  • seed location

  • root cause in one sentence

  • ranked candidate table

  • positive and negative examples

  • graph dimensions that produced useful candidates

For semgrep-rule-creator, provide:

  • the syntax that should stay specific

  • the syntax that should be abstracted

  • at least one true-positive candidate and one likely negative example

For static-analysis, provide:

  • candidate files and functions

  • suggested source, sink, or path query shape

  • SARIF output expectation if the user wants machine-readable results

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Trail of Bits
Publisher
Trail of Bits (Official)
Source
trailofbits/skills · plugins/trailmark/skills/trailmark-variant-neighborhood · commit e4dd0bb
Licence
Creative Commons Attribution-ShareAlike 4.0 International (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Trail of Bits.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download trailmark-variant-neighborhood.zip