Claude Skill

trailmark-finding-triage

Performs graph-assisted triage of a single security finding, SARIF result, weAudit annotation, suspicious function, or report excerpt using Trailmark reachability, entrypoint paths, taint, privilege-boundary, blast-radius, caller/callee, and neighborhood evidence. Use when decidi

LLM Mart · 0 points · 6 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download trailofbits-skills-plugins_trailmark_skills_trailmark-finding-triage-123037e.zip · 7 KB
trailofbits/skills 7234 616 forks CC-BY-SA-4.0 Updated 8h ago
Part of trailofbits/skills — 100 skills

Install

skills CLI npx skills add https://github.com/trailofbits/skills/tree/main/plugins/trailmark/skills/trailmark-finding-triage
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install trailofbits-skills@llmmart
Git git clone https://github.com/trailofbits/skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole trailofbits/skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Trailmark Finding Triage

Build a concise graph evidence packet for one candidate finding. This skill answers whether the affected code is reachable, what graph evidence supports or weakens the claim, and what manual review is still required before calling the issue exploitable.

When to Use

  • Triage one static-analysis result before spending PoC time
  • Check whether a manual finding is entrypoint-reachable
  • Build an evidence packet for PoC work
  • Review a single suspicious function discovered during manual audit
  • Decide whether one issue should be promoted, deprioritized, or treated as part of a broader chain analysis

When NOT to Use

  • Multiple weak findings might compose into a stronger chain. Use a chain or composition workflow instead.
  • The user wants a full audit. Use an audit or design-review workflow instead.
  • The user wants remediation verification for a known finding. Use a remediation-review workflow instead.
  • The target is a PR or branch diff. Use graph-evolution plus a differential review workflow.
  • No concrete finding, function, file/line, or suspicious sink exists yet. Use discovery skills first.

Rationalizations to Reject

Rationalization Why It Is Wrong Required Action
"The scanner says high severity, so reachability is obvious" Static findings need graph and code context before promotion Bind the finding to a graph node and check entrypoint paths
"No entrypoint path means impossible" It may mean parser, proxy, or dynamic dispatch limitations Report the limitation separately from reachability
"An auth check appears on the path, so the issue is safe" The check may enforce the wrong predicate or be bypassed by another path Treat validation/auth as review targets, not proof
"One reachable path is enough for a PoC claim" The path still needs attacker-controlled inputs and compatible preconditions Separate graph reachability from exploitability
"This is probably a chain" Single-finding triage stops at one candidate Hand off related findings to a composition workflow

Workflow

Finding Triage Progress:
- [ ] Step 1: Normalize the candidate
- [ ] Step 2: Build or reuse the Trailmark graph
- [ ] Step 3: Bind the candidate to graph node(s)
- [ ] Step 4: Analyze reachability, taint, boundaries, and blast radius
- [ ] Step 5: Decide and emit the evidence packet

Step 1: Normalize the Candidate

Accept file/line, function name, SARIF result, weAudit annotation, Markdown finding excerpt, or a manual claim. Normalize it to:

  • title
  • source type
  • file path and line range if present
  • function or node hint
  • suspected source, sink, or asset
  • claimed impact

If there is no concrete code anchor, stop and ask for one.

For input handling details, see references/input-normalization.md.

Step 2: Build Or Reuse The Graph

Use the public trailmark skill workflow. Prefer an existing fresh exported graph or .trailmark/ artifact when present. Otherwise build a graph with language="auto" or the target's explicit language list, then run engine.preanalysis().

Record the Trailmark version or feature probes used. Feature-gate Trailmark 0.4-only APIs with hasattr() or CLI help checks.

Step 3: Bind The Candidate

Bind by file and line overlap first, then function name plus file. If several nodes match, list every candidate and select the narrowest enclosing node as primary. If no node matches, report a binding limitation instead of guessing.

SARIF and weAudit users should reuse the audit-augmentation workflow for matching and then inspect the annotated node.

Step 4: Analyze Graph Evidence

Run the query recipe in references/query-recipes.md:

  • entrypoint paths to the bound node
  • trust level of each path when available
  • membership in tainted, privilege_boundary, and high_blast_radius subgraphs
  • direct callers and callees
  • high-impact downstream sinks
  • sibling or nearby nodes worth manual review

Do not treat graph reachability as proof of exploitability.

Step 5: Decide And Handoff

Produce one verdict:

Verdict Meaning
Promote Graph evidence supports reachability and plausible impact
Needs manual review Evidence is suggestive but not decisive
Deprioritize No reachable path or only trusted/internal paths found
Blocked Binding or Trailmark analysis failed

Write the evidence packet using references/output-format.md.

Hand off promoted PoC-worthy issues to the user's PoC workflow. Hand off related findings to a composition workflow. Hand off repeatable root causes to trailmark-variant-neighborhood, variant-analysis, or a custom Semgrep/CodeQL rule workflow.

Example Prompts

  • "Use Trailmark finding triage on src/Vault.sol:148; I think withdraw can bypass the balance update."
  • "Triage this SARIF result before I spend PoC time: semgrep:error unchecked-transfer in contracts/Bridge.sol line 91."
  • "This report excerpt claims parse_packet is attacker reachable. Build the Trailmark evidence packet and tell me what is still missing."
Files (skills)
  • agents
    • openai.yaml 245 B
      interface:
        display_name: "Trailmark Finding Triage"
        short_description: "Assess a security finding with code graph evidence"
        icon_small: "assets/trail-of-bits-mark.svg"
        icon_large: "assets/trail-of-bits-mark.svg"
        brand_color: "#D83A34"
      
  • assets
    • trail-of-bits-mark.svg 3 KB · in bundle
  • references
    • input-normalization.md 1.8 KB
      # Input Normalization
      
      Normalize every request into one candidate record before graph analysis.
      
      ## Accepted Inputs
      
      | Input | Required fields | Notes |
      |---|---|---|
      | File/line | `file`, `line` | Best starting point for direct graph binding |
      | Function name | `function`, optional `file` | Ambiguous across files; ask for file if many nodes match |
      | SARIF result | `artifactLocation.uri`, `region` | Prefer `audit-augmentation` matching when SARIF is available |
      | weAudit annotation | file, line, severity, text | Convert 0-indexed lines to Trailmark's expected source lines when needed |
      | Markdown finding | title, location or symbol | Extract the claimed impact but do not assume it is true |
      | Manual claim | anchor plus suspected issue | Ask for a concrete anchor if none is provided |
      
      ## Candidate Record
      
      Use this shape in notes and final output:
      
      ```json
      {
        "title": "Unchecked balance update before transfer",
        "source_type": "manual|sarif|weaudit|report|function",
        "file": "src/Vault.sol",
        "line_range": [148, 168],
        "function_hint": "withdraw(uint256)",
        "suspected_source": "external caller",
        "suspected_sink": "value transfer",
        "claimed_impact": "withdrawal without balance decrement"
      }
      ```
      
      ## Stop Conditions
      
      Stop and request a concrete anchor when:
      
      - only a vulnerability class is provided
      - only a package or directory is provided
      - the excerpt has no file, function, line, symbol, or SARIF/weAudit location
      - all matching graph nodes are test, generated, or vendor code and the user did
        not say those are in scope
      
      ## Ambiguity Handling
      
      If multiple graph nodes match:
      
      1. Keep all matches in the evidence packet.
      2. Prefer file/line overlap over name matching.
      3. Prefer the narrowest enclosing node.
      4. Mark confidence `Low` unless the candidate source unambiguously identifies
         the intended node.
      
    • output-format.md 1.7 KB
      # Output Format
      
      Return a concise evidence packet. Use Markdown unless the user asks for JSON.
      
      ```markdown
      # Trailmark Finding Triage: <title>
      
      ## Verdict
      
      Status: Promote | Needs manual review | Deprioritize | Blocked
      Confidence: High | Medium | Low
      
      ## Candidate
      
      - Source:
      - Location:
      - Bound node:
      - Claimed issue:
      
      ## Graph Evidence
      
      - Entrypoint reachable:
      - Entry paths:
      - Tainted:
      - Privilege boundary:
      - Blast radius:
      - Direct callers:
      - Direct callees:
      - Relevant sinks:
      
      ## Manual Review Targets
      
      | Target | Why it matters |
      |---|---|
      
      ## Limitations
      
      ## Recommended Next Step
      ```
      
      ## Verdict Criteria
      
      | Verdict | Use when |
      |---|---|
      | `Promote` | The candidate binds cleanly, has reachable entrypoint paths, and graph evidence supports plausible impact |
      | `Needs manual review` | The candidate is reachable but exploitability depends on validation, authorization, type, or state semantics |
      | `Deprioritize` | The candidate is not entrypoint-reachable, is only trusted-internal, or sits in test/generated/vendor code outside scope |
      | `Blocked` | The candidate cannot be bound, Trailmark fails, or the language/parser is unsupported |
      
      ## Confidence Criteria
      
      | Confidence | Use when |
      |---|---|
      | `High` | Binding is exact, paths are explicit, and graph evidence is consistent |
      | `Medium` | Binding is clear but path or sink evidence has uncertainty |
      | `Low` | Binding is ambiguous, dynamic dispatch/proxy edges dominate, or important graph features are unavailable |
      
      ## Wording Requirements
      
      - Say "graph evidence supports" instead of "Trailmark proves".
      - Say "manual review target" for validators, auth checks, and sanitizers.
      - Separate "reachable" from "attacker controlled".
      - Separate "candidate" from "confirmed vulnerability".
      
    • query-recipes.md 2.2 KB
      # Query Recipes
      
      Use these recipes after building a graph and running `engine.preanalysis()`.
      Feature-gate optional Trailmark 0.4 APIs with `hasattr()`.
      
      ## Build And Preanalyze
      
      ```python
      from trailmark.query.api import QueryEngine
      
      engine = QueryEngine.from_directory("{targetDir}", language="auto")
      engine.preanalysis()
      ```
      
      If auto-detection is wrong, rerun with an explicit language or comma-separated
      language list.
      
      ## Bind A File/Line Candidate
      
      Prefer Trailmark or `audit-augmentation` matching helpers when available. If
      working from exported JSON, match nodes whose location file equals the
      candidate file and whose line span overlaps the candidate line range. Pick the
      smallest span as primary.
      
      ## Reachability
      
      ```python
      node_id = "{bound_node}"
      
      entry_paths = engine.entrypoint_paths_to(node_id)
      ```
      
      Classify paths as:
      
      - `untrusted_external`
      - `semi_trusted_external`
      - `trusted_internal`
      - `unknown`
      
      If no path exists, distinguish likely dead/internal code from parser,
      language, proxy, dynamic dispatch, or missing-entrypoint modeling gaps.
      
      ## Taint And Privilege Boundaries
      
      ```python
      tainted = node_id in set(engine.subgraph("tainted"))
      boundary = node_id in set(engine.subgraph("privilege_boundary"))
      entry_reachable = node_id in set(engine.subgraph("entrypoint_reachable"))
      ```
      
      When `connect_subgraphs()` exists, use it to find paths from tainted nodes to
      privilege-boundary nodes and check whether the candidate sits on or near those
      paths.
      
      ## Blast Radius And Neighborhood
      
      ```python
      callers = engine.callers_of(node_id)
      callees = engine.callees_of(node_id)
      high_blast = node_id in set(engine.subgraph("high_blast_radius"))
      
      downstream = engine.reachable_from(node_id)
      ```
      
      Flag downstream sinks involving:
      
      - value transfer
      - authorization or role decisions
      - persistence or state writes
      - parsing or deserialization
      - cryptographic keys, sessions, or signatures
      - external process, network, or file operations
      
      ## Evidence Limits
      
      Always record:
      
      - Trailmark version or feature probes
      - unsupported languages or parser errors
      - unresolved/proxy/dynamic call uncertainty
      - unmatched or ambiguous graph binding
      - missing entrypoint modeling
      - places where manual security judgment is still required
      
  • SKILL.md 5.7 KB
    ---
    name: trailmark-finding-triage
    description: "Performs graph-assisted triage of a single security finding, SARIF result, weAudit annotation, suspicious function, or report excerpt using Trailmark reachability, entrypoint paths, taint, privilege-boundary, blast-radius, caller/callee, and neighborhood evidence. Use when deciding whether one candidate issue is reachable, prioritizing a finding before PoC work, preparing evidence for exploit validation, or checking whether a static-analysis result is actionable."
    allowed-tools:
      - Bash
      - Read
      - Grep
      - Glob
      - Write
    ---
    
    # Trailmark Finding Triage
    
    Build a concise graph evidence packet for one candidate finding. This skill
    answers whether the affected code is reachable, what graph evidence supports
    or weakens the claim, and what manual review is still required before calling
    the issue exploitable.
    
    ## When to Use
    
    - Triage one static-analysis result before spending PoC time
    - Check whether a manual finding is entrypoint-reachable
    - Build an evidence packet for PoC work
    - Review a single suspicious function discovered during manual audit
    - Decide whether one issue should be promoted, deprioritized, or treated as
      part of a broader chain analysis
    
    ## When NOT to Use
    
    - Multiple weak findings might compose into a stronger chain. Use a chain or
      composition workflow instead.
    - The user wants a full audit. Use an audit or design-review workflow instead.
    - The user wants remediation verification for a known finding. Use a
      remediation-review workflow instead.
    - The target is a PR or branch diff. Use `graph-evolution` plus a differential
      review workflow.
    - No concrete finding, function, file/line, or suspicious sink exists yet. Use
      discovery skills first.
    
    ## Rationalizations to Reject
    
    | Rationalization | Why It Is Wrong | Required Action |
    |---|---|---|
    | "The scanner says high severity, so reachability is obvious" | Static findings need graph and code context before promotion | Bind the finding to a graph node and check entrypoint paths |
    | "No entrypoint path means impossible" | It may mean parser, proxy, or dynamic dispatch limitations | Report the limitation separately from reachability |
    | "An auth check appears on the path, so the issue is safe" | The check may enforce the wrong predicate or be bypassed by another path | Treat validation/auth as review targets, not proof |
    | "One reachable path is enough for a PoC claim" | The path still needs attacker-controlled inputs and compatible preconditions | Separate graph reachability from exploitability |
    | "This is probably a chain" | Single-finding triage stops at one candidate | Hand off related findings to a composition workflow |
    
    ## Workflow
    
    ```
    Finding Triage Progress:
    - [ ] Step 1: Normalize the candidate
    - [ ] Step 2: Build or reuse the Trailmark graph
    - [ ] Step 3: Bind the candidate to graph node(s)
    - [ ] Step 4: Analyze reachability, taint, boundaries, and blast radius
    - [ ] Step 5: Decide and emit the evidence packet
    ```
    
    ### Step 1: Normalize the Candidate
    
    Accept file/line, function name, SARIF result, weAudit annotation, Markdown
    finding excerpt, or a manual claim. Normalize it to:
    
    - title
    - source type
    - file path and line range if present
    - function or node hint
    - suspected source, sink, or asset
    - claimed impact
    
    If there is no concrete code anchor, stop and ask for one.
    
    For input handling details, see
    [references/input-normalization.md](references/input-normalization.md).
    
    ### Step 2: Build Or Reuse The Graph
    
    Use the public `trailmark` skill workflow. Prefer an existing fresh exported
    graph or `.trailmark/` artifact when present. Otherwise build a graph with
    `language="auto"` or the target's explicit language list, then run
    `engine.preanalysis()`.
    
    Record the Trailmark version or feature probes used. Feature-gate Trailmark
    0.4-only APIs with `hasattr()` or CLI help checks.
    
    ### Step 3: Bind The Candidate
    
    Bind by file and line overlap first, then function name plus file. If several
    nodes match, list every candidate and select the narrowest enclosing node as
    primary. If no node matches, report a binding limitation instead of guessing.
    
    SARIF and weAudit users should reuse the `audit-augmentation` workflow for
    matching and then inspect the annotated node.
    
    ### Step 4: Analyze Graph Evidence
    
    Run the query recipe in
    [references/query-recipes.md](references/query-recipes.md):
    
    - entrypoint paths to the bound node
    - trust level of each path when available
    - membership in `tainted`, `privilege_boundary`, and `high_blast_radius`
      subgraphs
    - direct callers and callees
    - high-impact downstream sinks
    - sibling or nearby nodes worth manual review
    
    Do not treat graph reachability as proof of exploitability.
    
    ### Step 5: Decide And Handoff
    
    Produce one verdict:
    
    | Verdict | Meaning |
    |---|---|
    | `Promote` | Graph evidence supports reachability and plausible impact |
    | `Needs manual review` | Evidence is suggestive but not decisive |
    | `Deprioritize` | No reachable path or only trusted/internal paths found |
    | `Blocked` | Binding or Trailmark analysis failed |
    
    Write the evidence packet using
    [references/output-format.md](references/output-format.md).
    
    Hand off promoted PoC-worthy issues to the user's PoC workflow. Hand off
    related findings to a composition workflow. Hand off repeatable root causes to
    `trailmark-variant-neighborhood`, `variant-analysis`, or a custom Semgrep/CodeQL
    rule workflow.
    
    ## Example Prompts
    
    - "Use Trailmark finding triage on `src/Vault.sol:148`; I think withdraw can
      bypass the balance update."
    - "Triage this SARIF result before I spend PoC time: `semgrep:error
      unchecked-transfer` in `contracts/Bridge.sol` line 91."
    - "This report excerpt claims `parse_packet` is attacker reachable. Build the
      Trailmark evidence packet and tell me what is still missing."
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related