plugins/building-secure-contracts/skills/secure-workflow-guide/SKILL.md
Guides through Trail of Bits' 5-step secure development workflow. Runs Slither scans, checks special features (upgradeability/ERC conformance/token integration), generates visual security diagrams, helps document security properties for fuzzing/verification, and reviews manual security areas.
npx skillsauth add trailofbits/skills secure-workflow-guideInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Guides through Trail of Bits' secure development workflow - a 5-step process to enhance smart contract security throughout development.
Use this: On every check-in, before deployment, or when you want a security review
Covers a security workflow including:
Run Slither with 70+ built-in detectors to find common vulnerabilities:
Goal: Clean Slither report or documented triages
Detect and validate applicable features:
Note: Only runs checks that apply to your codebase
Generate 3 security diagrams:
Review each diagram for security concerns
Help document critical security properties:
Then set up testing:
Note: Most important activity for security
Analyze areas automated tools miss:
Search codebase for these patterns and flag risks
For detailed instructions, commands, and explanations for each step, see WORKFLOW_STEPS.md.
When invoked, I will:
Adapts based on:
| Rationalization | Why It's Wrong | Required Action | |-----------------|----------------|-----------------| | "Slither not available, I'll check manually" | Manual checking misses 70+ detector patterns | Install and run Slither, or document why it's blocked | | "Can't generate diagrams, I'll describe the architecture" | Descriptions aren't visual - diagrams reveal patterns text misses | Execute slither --print commands, generate actual visual outputs | | "No upgrades detected, skip upgradeability checks" | Proxies and upgrades are often implicit or planned | Verify with codebase search before skipping Step 2 checks | | "Not a token, skip ERC checks" | Tokens can be integrated without obvious ERC inheritance | Check for token interactions, transfers, balances before skipping | | "Can't set up Echidna now, suggesting it for later" | Property-based testing is Step 4, not optional | Document properties now, set up fuzzing infrastructure | | "No DeFi interactions, skip oracle/flash loan checks" | DeFi patterns appear in unexpected places (price feeds, external calls) | Complete Step 5 manual review, search codebase for patterns | | "This step doesn't apply to my project" | "Not applicable" without verification = missed vulnerabilities | Verify with explicit codebase search before declaring N/A | | "I'll provide generic security advice instead of running workflow" | Generic advice isn't actionable, workflow finds specific issues | Execute all 5 steps, generate project-specific findings with file:line references |
When I complete the workflow, you'll get a comprehensive security report covering:
For a complete example workflow report, see EXAMPLE_REPORT.md.
Security Report:
Action Plan:
Workflow Checklist:
Trail of Bits Resources:
Other Security:
Let me know when you're ready and I'll run through the workflow with your codebase!
development
Performs comprehensive Rust security review for safe/unsafe boundary issues, memory safety in unsafe blocks, concurrency hazards, panic-induced DoS, FFI safety, and async runtime mistakes. Use when auditing Rust crates, services, or libraries — particularly those with `unsafe`, FFI, or concurrent code.
development
Performs comprehensive C/C++ security review for memory corruption, integer overflows, race conditions, and platform-specific vulnerabilities. Use when auditing native C/C++ applications, reviewing daemons or services for memory safety, or hunting integer overflow / use-after-free / race conditions in userspace code.
testing
Systematically verifies suspected security bugs to eliminate false positives, producing a TRUE POSITIVE or FALSE POSITIVE verdict with documented evidence for each. Use when asked whether a specific finding is real, exploitable, or a false positive, or to verify or validate a suspected vulnerability — not for hunting or discovering new bugs.
development
Creates custom Semgrep rules for detecting security vulnerabilities, bug patterns, and code patterns. Use when writing Semgrep rules or building custom static analysis detections.