trailmark-review-gate
Runs a Trailmark structural review gate over a branch, pull request, fix commit, release diff, or git ref range to detect new entrypoints, new tainted paths, removed validation or authorization calls, privilege-boundary drift, blast-radius growth, complexity growth, and newly reachable sensitive sinks. Use when reviewing a PR, branch, remediation commit, or release diff where graph-level security regressions should be checked before merge.
git clone --depth 1 https://github.com/trailofbits/skills /tmp/trailmark-review-gate && cp -r /tmp/trailmark-review-gate/plugins/trailmark/skills/trailmark-review-gate ~/.claude/skills/trailmark-review-gateSKILL.md
# Trailmark Review Gate Apply deterministic security gate rules to Trailmark structural diff evidence. This skill does not replace line-level review. It produces a compact structural packet reviewers can cite while they inspect the code. ## When to Use - Reviewing a branch, pull request, release diff, or fix commit - Checking whether a change expands attack surface - Looking for removed validation or authorization on reachable paths - Comparing before/after taint, privilege-boundary, blast-radius, or complexity signals - Producing graph evidence for a differential review ## When NOT to Use - Single-snapshot analysis. Use `trailmark` or `trailmark-structural`. - Text-diff review only. Use `differential-review`. - Full vulnerability discovery. Use an audit or bug-finding workflow. - One static finding. Use `trailmark-finding-triage`. - Tooling is unavailable and the user wants manual review only. ## Rationalizations to Reject | Rationalization | Why It Is Wrong | Required Action | |---|---|---| | "The line diff is small, so no graph gate is needed" | Small changes can create new call paths | Compare before/after graphs | | "Graph gate passed, so the PR is secure" | The gate only checks structural regressions | Still perform line-level review | | "Trailmark failed, so pass the gate" | Tool failure is unknown risk, not success | Emit `UNKNOWN` | | "Tests pass, so removed validation is fine" | Tests may miss affected entrypoint paths | Review the removed path manually | | "Only new code matters" | Removed auth, validation, and callers can be higher risk than additions | Review removals and path changes | ## Workflow ``` Review Gate Progress: - [ ] Step 1: Resolve before/after inputs - [ ] Step 2: Build graph-evolution evidence - [ ] Step 3: Normalize structural changes - [ ] Step 4: Apply gate rules - [ ] Step 5: Emit review packet and actions ``` ### Step 1: Resolve Inputs Accept two refs, a branch name, a commit range, or before/after directories. Do not check out branches unnecessarily. Prefer `git diff`, `git show`, and git worktrees, following the `graph-evolution` snapshot workflow. ### Step 2: Build Graph Evidence Run `graph-evolution` or equivalent Trailmark before/after graph analysis. Both snapshots must run `engine.preanalysis()` so taint, privilege-boundary, blast-radius, complexity, and entrypoint signals are available. Record Trailmark version and any feature probes. If graph construction fails, emit `UNKNOWN`. ### Step 3: Normalize Changes Normalize evidence into: - added, removed, and modified nodes - added and removed edges - entrypoint set changes - taint membership changes - privilege-boundary membership changes - blast-radius changes - complexity changes - newly reachable sensitive sinks - unresolved, proxy, or dynamic edge changes ### Step 4: Apply Gate Rules Apply the rules in [references/gate-rules.md](references/gate-rules.md). Gate verdicts are: | Verdict | Meaning | |---|---| | `FAIL` | A high-risk structural regression needs review before acceptance | | `WARN` | A meaningful graph change needs reviewer attention | | `PASS` | No configured structural gate fired | | `UNKNOWN` | Trailmark failed or evidence is too incomplete | ### Step 5: Emit Packet Write the packet using [references/output-format.md](references/output-format.md), then hand it to the branch reviewer. Use [references/review-integration.md](references/review-integration.md) when combining this packet with `differential-review` or another PR review process. ## Requirements - Never mutate the user's working branch while comparing refs. - Never report `PASS` when Trailmark failed. - Separate graph evidence from manual security judgment. - Include exact changed nodes or paths for every `FAIL` and `WARN`. - Include limitations when parser, proxy, unresolved-call, or dynamic-dispatch uncertainty affects the verdict.
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 patterns, direct expression injection, dangerous sandbox configurations, and wildcard user allowlists. Use when reviewing workflow files that invoke AI coding agents, auditing CI/CD pipeline security for prompt injection risks, or evaluating agentic action configurations.
Clarify requirements before implementing. Use when serious doubts arise.
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.
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).
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 to be audited by someone else, getting a repository review-ready before an external security review, deciding what to fix before auditors start, or asking what assessors need from a project. For understanding unfamiliar code you are about to audit, use audit-context-building instead.
Scans Cairo/StarkNet smart contracts for 6 critical vulnerabilities including felt252 arithmetic overflow, L1-L2 messaging issues, address conversion problems, and signature replay. Use when auditing StarkNet projects.
Systematic code maturity assessment using Trail of Bits' 9-category framework. Analyzes codebase for arithmetic safety, auditing practices, access controls, complexity, decentralization, documentation, MEV risks, low-level code, and testing, then produces a scorecard with evidence-based ratings and a priority-ordered roadmap. Use when assessing or scoring the maturity of a smart contract or blockchain codebase, producing a maturity scorecard or evaluation, or judging how mature, well-tested, or well-documented such a project is against a rubric.
Scans Cosmos SDK blockchain modules and CosmWasm contracts for consensus-critical vulnerabilities — chain halts, fund loss, state divergence. 25 core + 16 IBC + 10 EVM + 3 CosmWasm patterns. Use when auditing custom x/ modules, reviewing IBC integrations, or assessing pre-launch chain security. Updated for SDK v0.53.x.