solana-vulnerability-scanner

solana-vulnerability-scanner skill 概览

solana-vulnerability-scanner 是一款面向 Solana 程序审计的专项 skill，专门用来检查那些在通用 Rust 代码审查里很容易漏掉的安全问题。它最适合工程师、审计人员和安全团队在部署前检查原生 Solana 或 Anchor 程序，尤其是代码中涉及 CPI、PDA 逻辑、signer 校验、账户所有权校验或 instruction introspection 时。

solana-vulnerability-scanner skill 不是一个泛用的智能合约 lint 工具；它的目标是快速揪出少数高影响的 Solana 特有错误，帮助你判断一个程序是否已经足够安全可以上线，还是还需要更深入的人工审查。

这个 skill 能捕捉什么

这个仓库围绕六类关键漏洞模式展开，包括 arbitrary CPI、不正确的 PDA 验证、缺失 signer 或 ownership 检查，以及 sysvar spoofing。这让 solana-vulnerability-scanner 在你的核心问题不是“代码能不能编译”，而是“攻击者能不能借助 Solana 的账户模型改写信任假设”时，尤其有用。

最适合的使用场景

在面向上线的程序、安全审计、升级审查、协议集成，以及任何依赖账户来代表特定 program、authority 或 sysvar 的代码路径中，都适合使用 solana-vulnerability-scanner。它对通用业务逻辑审查或非 Solana 的 Rust crate 帮助较小。

它和其他工具的区别

solana-vulnerability-scanner 的价值在于它的 Solana 特定判断逻辑。它会把注意力集中在账户校验和 CPI 这类真正决定可利用性的边界上，而不是让你把时间浪费在那些对任何 Rust 仓库都通用的建议上。

如何使用 solana-vulnerability-scanner skill

安装这个 skill

使用以下命令安装 solana-vulnerability-scanner：

npx skills add trailofbits/skills --skill solana-vulnerability-scanner

这个安装路径很重要，因为这个 skill 实际位于 trailofbits/skills 仓库中的 plugins/building-secure-contracts/skills/solana-vulnerability-scanner，所以你应该把它当作安全审计工作流来使用，而不是一个泛化的编码助手提示词。

先给它正确的目标和范围

solana-vulnerability-scanner 最好的使用方式，是先明确审计目标：仓库名称、程序入口点、框架类型，以及你关心的信任边界。高质量输入通常像这样：“审计这个 Anchor program 在 arbitrary CPI、PDA 派生错误，以及 initialize 和 withdraw 流程里是否缺少 signer 检查。”

而像“扫描这个 Solana app”这样的弱输入，往往会漏掉真正关键的具体 accounts 和 instructions。

先读对的文件

在安装和审查 solana-vulnerability-scanner 时，先看 SKILL.md，再检查 resources/VULNERABILITY_PATTERNS.md。这个资源文件给出了 skill 依据的具体检查项和示例，比只凭文件名猜测要有用得多。

同时也快速浏览定义以下内容的程序文件：

• 使用 invoke() 或 invoke_signed() 的 CPI 调用
• Anchor 中的 #[derive(Accounts)] 结构体
• PDA 派生和 seed 验证
• account ownership 和 signer 约束
• sysvar 或 program account 检查

一个实用的工作流

建议分两轮使用这个 skill。第一轮，让它识别可能的漏洞类别以及受影响的 instructions。第二轮，再让它按账户级细节逐条审查每条被标记的路径，比如哪些账户由用户控制、预期的 program ID 是什么，以及验证是在 CPI 之前还是在状态变更之前完成。

一个比较好的提示词结构是：
“审查这些 Solana/Anchor instructions 是否存在 solana-vulnerability-scanner 定义的六类关键漏洞。重点关注 account validation、CPI 目标、PDA seeds 和 sysvar 信任。按 instruction 返回 findings，解释可利用性，并标注 false positives。”

solana-vulnerability-scanner skill 常见问题

solana-vulnerability-scanner 只适用于 Anchor 吗？

不是。这个 skill 同时覆盖原生 Solana Rust 程序和基于 Anchor 的程序。不过，Anchor 代码通常把检查写得更声明式，所以审查重点会更多落在约束是否完整，以及 program 和 account 类型是否被正确限制上。

它和普通代码审查提示词有什么不同？

普通提示词可能会注意到可疑逻辑，但 solana-vulnerability-scanner 是针对 Solana 账户模型，以及攻击者如何滥用 CPI、PDA 处理和账户校验这些具体手法来设计的。因此，它对 Solana 安全审计中最重要的问题覆盖得更好。

对新手友好吗？

如果你能找到程序入口点和主要 instruction 的 accounts，那它就挺友好。新手最适合把 solana-vulnerability-scanner 当作带引导的检查清单来用，然后针对每个被标记的 instruction 继续追问，而不是一上来就试图把整个仓库一起审完。

什么时候不该用它？

不要把 solana-vulnerability-scanner 当成 tokenomics、业务逻辑或治理设计的唯一审查工具。它最擅长的是安全关键的 Solana 模式，而不是更广泛的协议正确性或经济模型分析。

如何改进 solana-vulnerability-scanner skill

给出精确的 instruction 路径

提升效果最明显的一步，是明确说明 instruction 名称、预期 authority 和各个 account 的角色。不要只说“检查我的程序”，而要指出你想审查哪个 handler，以及哪些 accounts 应该是可信的、可变的、受 signer 保护的，或者由 program 拥有。这样 solana-vulnerability-scanner 才能把真实风险和无害的配套逻辑区分开。

先把信任假设说清楚

如果某个 account 应该是 token program、system program、metadata program，或者某个特定的 PDA，就直接说明。若某个 account 可以由用户提供，也要明确写出来。清晰的信任假设会让 solana-vulnerability-scanner 的输出更精准，因为很多 Solana bug 本质上就是少了验证。

要求它说明可利用性，而不只是列问题

想把 solana-vulnerability-scanner 用得更好，就要让它给出攻击路径以及让问题可被利用的前置条件。这样输出就能区分“风格问题”和“安全漏洞”，这正是 Security Audit 工作流里真正需要的。

结合具体代码区域迭代

如果第一轮已经标出了某个 CPI 或 PDA 模式，就把审查范围收窄到具体函数和它对应的 Accounts 结构体上。最好的结果通常来自一次只看一个 instruction，然后再追问账户约束、program IDs 和 seeds 是否完全符合预期的信任模型。