substrate-vulnerability-scanner

substrate-vulnerability-scanner 技能概览

substrate-vulnerability-scanner 的作用

substrate-vulnerability-scanner 技能可帮助你审计 Substrate 和 FRAME 代码中七类高风险、平台特定的漏洞，这些问题可能导致崩溃、拒绝服务或未授权的状态变更。它最适合你需要的是面向 Security Audit 工作流的、聚焦型的 substrate-vulnerability-scanner，而不是通用 Rust 代码审查的时候。

适合谁使用

如果你正在审查 Polkadot 平行链或独立 Substrate 链中的自定义 pallet、runtime extrinsic、weight 逻辑，或无签名交易校验，这个技能就很合适。它也很适合安全工程师、协议开发者，以及需要在深入人工分析之前先做一轮快速安全筛查的审查人员。

最擅长发现什么

这个仓库针对的，是那些在普通代码审查中很容易漏掉的模式：算术溢出、panic 触发的 DoS、错误的 origin 检查、不正确的 weight、危险的无签名 extrinsic，以及相关的 FRAME 特有错误。它的核心价值不在于广泛理解代码，而在于识别 Substrate runtime 代码里最关键的安全类别。

如何使用 substrate-vulnerability-scanner 技能

安装并限定审查范围

先用 trailofbits skills package 运行 substrate-vulnerability-scanner install 流程，然后把审查对象限定在 runtime 或 pallet 边界，而不是整个 monorepo。最好在输入里明确说明正在审计什么、范围内是哪一个 pallet 或链，以及你更关心可利用性、修复建议，还是清单式扫描结果。

先阅读这些文件

先看 SKILL.md，了解检测逻辑；再读 resources/VULNERABILITY_PATTERNS.md，查看实际的检查模式和缓解方式。如果仓库里有多个 pallet，优先检查 pallet 的 lib.rs 或 mod.rs 文件，再看 weight 文件和任何无签名交易校验代码，因为这些地方最可能体现出这个技能的价值。

给技能一个完整的提示词

弱提示词会说：“扫描这个 pallet 看看有没有问题。” 更强的提示词会说：“审查 pallet_balances 中与 Substrate 特定漏洞相关的问题。重点关注 extrinsic、storage mutation、weight 计算和 origin 检查。标出任何未做检查的算术、任何可由用户输入触发的 panic 路径，以及任何无签名 extrinsic 验证缺口。返回结果时包含文件路径、受影响的函数名、利用影响和修复建议。” 这种提示词能让 substrate-vulnerability-scanner usage 更稳定，因为它明确告诉模型该优先看什么，以及你希望输出成什么格式。

能提升信号的工作流建议

把这个技能当作结构化的第一轮筛查，然后再结合 runtime 上下文逐一验证所有被标记的路径。粘贴代码时，连同相关的类型定义和辅助函数一起给出，因为很多 Substrate 漏洞都依赖 config traits、origin 类型或 weight 假设，而这些信息单看一个函数并不明显。如果仓库里有多个 pallet，建议按 pallet 分别运行这个技能，而不是要求给出一个全局结论。

substrate-vulnerability-scanner 技能常见问题

substrate-vulnerability-scanner 只适用于 Substrate 吗？

是的，它是为 Substrate/FRAME 模式设计的，不是给通用 Rust 应用准备的。普通提示词也能发现一些代码异味，但当你需要的是与 pallet 语义和 dispatchable 行为绑定的链上 runtime 安全判断时，substrate-vulnerability-scanner 会更合适。

我需要是 Substrate 专家吗？

不需要，但如果你能分辨哪些代码是 runtime 逻辑，哪些是链下工具，结果会更好。即使是新手，只要提供准确的 pallet 路径，并要求具体发现而不是泛泛建议，也能使用这个技能。

什么时候不该用这个技能？

不要把它当作业务逻辑、密码学或链下服务的唯一审计方法。如果风险点不在 runtime pallet 里，这个技能可能会漏掉真正的问题，因为它的检测规则是针对 FRAME 和 dispatchable 函数优化的。

它和通用安全提示词有什么不同？

通用提示词可能会给出较宽泛的审查笔记，而这个技能则锚定在一组经过筛选的 Substrate 漏洞模式，以及这些模式通常出现的位置上。对于需要对 runtime 代码进行安全导向筛查、又希望少一些猜测的场景来说，这让 substrate-vulnerability-scanner guide 更便于决策。

如何改进 substrate-vulnerability-scanner 技能

先把上下文提供到位

最好的输入会明确写出 pallet、链类型，以及你最关心的代码路径。还要说明代码处理的是余额、奖励、手续费、治理、无签名交易，还是仅 root 可调用的函数，因为这些细节会直接影响哪些漏洞最重要。

要求说明可利用路径，而不只是匹配结果

常见失败模式是只列出一些可疑行，却没有安全意义。你应该要求技能说明某个模式是否真的可达、由什么输入触发、影响是什么，以及这个问题是否因为 config traits 或上游不变量而属于误报。这样 substrate-vulnerability-scanner usage 在分流和初筛时会更有操作性。

第一轮之后收紧审查范围

如果第一轮输出噪音太多，就把范围收窄到一个 pallet、一个 extrinsic，或者一个具体关注点，比如 ensure_* 检查、weight 数学运算或 storage 算术。如果第一轮输出太浅，就要求第二轮把被标记代码与 resources/VULNERABILITY_PATTERNS.md 中的模式以及周围的 trait bounds 对照起来，因为这些细节往往正是区分真实漏洞和安全抽象的关键。