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 deciding whether one candi
- 0
- Installs
- —
- Rating
- —
- Success rate
- 5
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 dfa479ae48b75f05… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
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-evolutionplus 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, andhigh_blast_radiussubgraphs - 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-transferincontracts/Bridge.solline 91." - "This report excerpt claims
parse_packetis attacker reachable. Build the Trailmark evidence packet and tell me what is still missing."
Files
5- SKILL.md
9f76e25b1e5.7 KB - agents/openai.yaml
39998c9958245 B - references/input-normalization.md
12ff637d581.8 KB - references/output-format.md
69deec7c251.7 KB - references/query-recipes.md
d0c948a22a2.2 KB
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from trailofbits/skills8
Builds and runs code under AddressSanitizer to catch buffer overflows, use-after-free, and other memory errors during fuzzing or tests. Covers -fsanitize=address builds, ASAN_OPTIONS, reading the crash report, LeakSanitizer, and the overhead and platform trade-offs. Use when fuzzing C/C++ or Rust th
Sets up and runs AFL++ for multi-core fuzzing of C/C++ projects built with afl-clang-fast or afl-gcc-fast. Covers instrumentation modes, parallel main and secondary campaigns, persistent mode, corpus minimization, and crash triage. Use when scaling fuzzing across cores, fuzzing a mature C/C++ codeba
Audits GitHub Actions workflows for security vulnerabilities in AI agent integrations including Claude Code Action, Gemini CLI, OpenAI Codex, and GitHub AI Inference. Detects attack vectors where attacker-controlled input reaches AI agents running in CI/CD pipelines, including env var intermediary p
Scans Algorand smart contracts for 11 common vulnerabilities including rekeying attacks, unchecked transaction fees, missing field validations, and access control issues. Use when auditing Algorand projects (TEAL/PyTeal).
Sets up and runs Atheris, the coverage-guided Python fuzzer built on libFuzzer. Covers TestOneInput harnesses, FuzzedDataProvider, instrumenting both pure Python and native C extensions, and running under AddressSanitizer. Use when fuzzing a Python package, hunting memory corruption in a Python C ex
Augments Trailmark code graphs with external audit findings from SARIF static analysis results, weAudit annotation files, and version-gated Trailmark 0.4.x binary-analysis graph exports. Maps findings to graph nodes by file and line overlap, creates severity-based subgraphs, and enables cross-refere
Understand a codebase before looking for bugs in it - what each function assumes, what it guarantees, and what it depends on elsewhere. Use when starting an audit, threat model, or architecture review on unfamiliar code, and before any vulnerability-hunting pass.
Prepares codebases for security review using Trail of Bits' checklist. Helps set review goals, runs static analysis tools, increases test coverage, removes dead code, ensures accessibility, and generates documentation (flowcharts, user stories, inline comments). Use when preparing your own codebase
Related security skillsscan passed
AI-powered codebase security scanner that reasons about code like a security researcher — tracing data flows, understanding component interactions, and catching vulnerabilities that pattern-matching tools miss. Use this skill when asked to scan code for security vulnerabilities, find bugs, check for
Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppS
Hunt for exploitable, bounty-worthy security issues in repositories. Focuses on remotely reachable vulnerabilities that qualify for real reports instead of noisy local-only findings. Use when hunting reportable, remotely reachable vulnerabilities in a repository.
Security audit: supported static findings; qualified profiles add reproduction and repair candidates. (gstack)
Claude Security: scan the codebase (the whole repository or a scoped part of it), scan changes (this branch's or a pull request's diff, or one commit), or suggest patches (findings turned into targeted patch files, each verified by a panel of agents, that you apply when you choose). Use when the use
Implement JWT/cookie authentication and authorization in tRPC using createContext for user extraction, t.middleware with opts.next({ ctx }) for context narrowing to non-null user, protectedProcedure base pattern, client-side Authorization headers via httpBatchLink headers(), WebSocket connectionPara