Trailmark Finding Triage

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

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.

Shortcut for Steps 2–4 (file/line findings)

For file/line anchors, run the bundled script. It builds the graph and preanalysis once, binds every finding, and prints the Graph Evidence fields as JSON: all matching nodes and the primary one (the node containing the first line, then the narrowest), entrypoint paths with each entrypoint's trust level, tainted / entrypoint_reachable / privilege_boundary / high_blast_radius membership, callers, callees, downstream nodes, and the Trailmark version. Pass several findings in one call rather than rebuilding the graph per finding.

uv run --no-project "{baseDir}/scripts/evidence_packet.py" --target <dir> --finding <file>:<line>[-<end>] --out evidence.json [--finding ...] [--language auto]

With --out, the complete packet stays on disk and stdout contains only delivery counts. Read relevant finding records from that file. Without --out, stdout is the full packet. Relative anchors may be target- or working-directory-relative; ambiguous existing paths are rejected. Choose --path-base target or cwd, or use an absolute path. Lines must be positive and ordered; column syntax is not supported. Containers cover module/class/contract declarations when no callable overlaps. Inspect binding (exact, nested or ambiguous), binding_kind, all matches, unavailable signals and parser diagnostic limitations before judging the result. A zero-node graph is a failure. Batching shares graph work only: write a separate human verdict for each finding.

A finding that binds to nothing comes back with bound_node: null and the reason. The script judges nothing: read the bound code and its callers, decide attacker control, and treat an empty path list as a limitation to explain (dynamic dispatch, proxies, missing entrypoint models), not as proof. Use the steps below for inputs the script does not take (function names, SARIF via audit-augmentation) and for queries it does not run (connect_subgraphs).

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:

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