substrate-vulnerability-scanner
by trailofbitssubstrate-vulnerability-scanner helps audit Substrate and FRAME pallets for critical issues like arithmetic overflow, panic DoS, bad origin checks, incorrect weights, and unsafe unsigned extrinsics. Use this substrate-vulnerability-scanner skill for Security Audit reviews of runtimes, pallet extrinsics, and weight logic.
This skill scores 78/100, which means it is a solid listing candidate for directory users: it has a clear Substrate-specific security use case, enough procedural detail to guide execution, and enough repository substance to justify install consideration. Users should still expect some adoption friction because there is no install command and the workflow is documentation-driven rather than tool-automated.
- Clearly targeted at auditing Substrate/FRAME pallets, with explicit use cases like runtime review, pre-launch assessment, and dispatchable validation.
- Provides concrete vulnerability coverage for 7 Substrate-specific patterns, backed by a dedicated reference file with detection patterns and mitigations.
- Includes substantial operational guidance such as platform detection markers, code examples, and constraints, which lowers guesswork for an agent.
- No install command or automated scripts are provided, so users must integrate it manually into their workflow.
- The skill appears documentation-heavy rather than execution-heavy, so results may depend on the agent interpreting the patterns correctly instead of following a runnable pipeline.
Overview of substrate-vulnerability-scanner skill
What substrate-vulnerability-scanner does
The substrate-vulnerability-scanner skill helps you audit Substrate and FRAME code for seven high-risk, platform-specific bugs that can lead to crashes, denial of service, or unauthorized state changes. It is most useful when you need a focused substrate-vulnerability-scanner for Security Audit workflow rather than a general Rust review.
Who should use it
Use this skill if you are reviewing custom pallets, runtime extrinsics, weight logic, or unsigned transaction validation in Polkadot parachains or standalone Substrate chains. It is a strong fit for security engineers, protocol developers, and reviewers who need a fast first-pass security screen before deeper manual analysis.
What it catches best
The repository is tuned for patterns that often slip through ordinary code review: arithmetic overflow, panic-triggered DoS, bad origin checks, incorrect weights, unsafe unsigned extrinsics, and related FRAME-specific mistakes. The main value is not broad code understanding; it is identifying the security classes that matter most in Substrate runtime code.
How to Use substrate-vulnerability-scanner skill
Install and scope the review
Run the substrate-vulnerability-scanner install flow with the trailofbits skills package, then aim it at a runtime or pallet boundary rather than an entire monorepo. Best results come when the input clearly says what is being audited, which pallet or chain is in scope, and whether you care about exploitability, fix recommendations, or a checklist-style pass.
Read these files first
Start with SKILL.md to understand the detection logic, then read resources/VULNERABILITY_PATTERNS.md for the actual check patterns and mitigations. If your repository has multiple pallets, inspect the pallet lib.rs or mod.rs files first, plus weight files and any unsigned transaction validation code, because those are the most likely places where this skill adds value.
Give the skill a complete prompt
A weak prompt says: “Scan this pallet for issues.” A stronger prompt says: “Review pallet_balances for Substrate-specific vulnerabilities. Focus on extrinsics, storage mutation, weight calculation, and origin checks. Flag any arithmetic that is not checked, any panic path reachable from user input, and any unsigned extrinsic validation gaps. Return findings with file paths, impacted function names, exploit impact, and remediation suggestions.” That kind of prompt makes substrate-vulnerability-scanner usage more reliable because it tells the model what to prioritize and what output format you want.
Workflow tips that improve signal
Use the skill as a structured first pass, then verify every flagged path against the runtime context. When you paste code, include surrounding type definitions and helper functions, because many Substrate bugs depend on config traits, origin types, or weight assumptions that are not obvious from one function alone. If the repo contains multiple pallets, run the skill per pallet instead of asking for a single global verdict.
substrate-vulnerability-scanner skill FAQ
Is substrate-vulnerability-scanner only for Substrate?
Yes, it is designed for Substrate/FRAME patterns, not generic Rust applications. A normal prompt can find code smells, but substrate-vulnerability-scanner is better when you need chain-runtime security judgment tied to pallet semantics and dispatchable behavior.
Do I need to be a Substrate expert?
No, but you will get better results if you can identify which code is runtime logic versus off-chain tooling. Beginners can still use the skill if they provide the exact pallet path and ask for concrete findings instead of broad advice.
When should I not use this skill?
Do not use it as your only audit method for business logic, cryptography, or off-chain services. If the risky area is outside runtime pallets, the skill may miss the real issue because its detection rules are optimized for FRAME and dispatchable functions.
How is it different from a generic security prompt?
A generic prompt may produce broad review notes, but this skill is anchored to a curated set of Substrate vulnerability patterns and the places they usually appear. That makes the substrate-vulnerability-scanner guide more decision-friendly when you need a security-oriented pass on runtime code with less guesswork.
How to Improve substrate-vulnerability-scanner skill
Provide the right context up front
The best inputs name the pallet, the chain type, and the code paths you care about most. Include whether the code handles balances, rewards, fees, governance, unsigned transactions, or root-only calls, because those details change which vulnerabilities matter most.
Ask for exploitable paths, not just matches
A common failure mode is a list of suspicious lines with no security meaning. Ask the skill to explain whether a pattern is actually reachable, what input triggers it, what the impact is, and whether the issue is a false positive caused by config traits or upstream invariants. That makes substrate-vulnerability-scanner usage more actionable for triage.
Tighten the review after the first pass
If the first output is noisy, narrow the scope to one pallet, one extrinsic, or one concern such as ensure_* checks, weight math, or storage arithmetic. If the first output is too shallow, ask for a second pass that compares the flagged code against the patterns in resources/VULNERABILITY_PATTERNS.md and the surrounding trait bounds, because those details often separate real bugs from safe abstractions.