cosmos-vulnerability-scanner

cosmos-vulnerability-scanner skill 概览

cosmos-vulnerability-scanner 能做什么

cosmos-vulnerability-scanner skill 主要用于发现 Cosmos SDK 代码、CosmWasm 合约、IBC 集成以及 Cosmos EVM 技术栈中的共识关键漏洞。它关注的是会导致链停摆、共识破坏、状态不同步或资金损失的问题，而不是泛泛的代码异味。如果你在做 cosmos-vulnerability-scanner for Security Audit 流程，那么当你的问题是“这条链会不会被利用或打崩？”而不是“代码写得干不干净？”时，它就是更合适的选择。

适合哪些人安装

如果你在审计自定义 x/ 模块、跨链桥或 IBC 逻辑、尚未上线的 app chain，或者处理有实际链上价值的 CosmWasm 合约，就应该使用 cosmos-vulnerability-scanner skill。它尤其适合需要对多类漏洞做结构化排查的团队，而不是依赖临时性的 prompt 逐段翻查。对于纯 Solidity 审计、通用 Go 代码审查，或应用层之外的链组件，它的价值就没那么大。

它的不同之处

这个 skill 不只是一个检查清单；它会按漏洞类别组织扫描，并输出分开的 markdown 发现项。这样做很重要，因为 Cosmos 漏洞往往同时横跨多个表面：状态记账、IBC packet 处理、模块权限，以及 EVM/Cosmos 原子性。配套的 resources/ 文件提供了更具体的模式家族，比一句笼统的“检查漏洞”更有可操作性。

如何使用 cosmos-vulnerability-scanner skill

安装并指向正确的仓库

在执行 cosmos-vulnerability-scanner install 时，先用你所在环境的标准 skills 命令把 skill 加到 agent workspace，然后在扫描目标仓库之前打开 skill 文件和关联的支持文档。实际使用中，最好的效果来自于你明确告诉它要分析哪个 codebase，以及结果要写到哪里。默认输出目录是 .bughunt_cosmos/，但如果你的工作流需要别的位置，就应该覆盖它。

给它正确的输入形态

高质量的 cosmos-vulnerability-scanner usage prompt 应该包含：repo 路径、链类型、应用用途，以及已知的高风险点。比如：“扫描这个 Cosmos SDK app chain 中自定义模块、IBC handlers 和 module-account 逻辑里的共识关键问题。重点看 pre-blockers、msg servers、keeper writes，以及任何会影响 supply、共识或跨链转账的代码。”这远比“review this repo”更有效，因为它会把扫描器引导到真正重要的代码路径上。

先读这些文件

先看 SKILL.md，再读 CHANGELOG.md 了解范围变化，然后查看 resources/ 里的相关模式文件：DISCOVERY.md、VULNERABILITY_PATTERNS.md、STATE_VULNERABILITY_PATTERNS.md、IBC_VULNERABILITY_PATTERNS.md、EVM_VULNERABILITY_PATTERNS.md 和 COSMWASM_VULNERABILITY_PATTERNS.md。如果目标是 Cosmos EVM 链，优先读 EVM 文件；如果合约占比很高，优先看 CosmWasm 文件。这些文件会告诉你这个 skill 到底检查什么，能避免漏掉整类漏洞。

使用更实用的审计流程

第一步，先给链分类：纯 Cosmos SDK、支持 IBC、CosmWasm，还是 Cosmos EVM。第二步，梳理自定义模块、ABCI hooks、keepers 和 message servers，因为这些决定了攻击面。第三步，先对高风险路径运行 skill：状态变更、权限校验、packet receive/acknowledgement handlers，以及任何会碰到 bank、staking、authz 或 module accounts 的代码。这样比按仓库文件顺序扫描更容易得到有效结果。

cosmos-vulnerability-scanner skill 常见问题

这只适合完整链审计吗？

不是。cosmos-vulnerability-scanner skill 也很适合局部审查，比如单个自定义模块、一个 IBC middleware stack，或者一个 CosmWasm 合约包。关键在于，这段代码必须会影响共识状态、代币流转或跨链行为。如果你的审查对象不在这条路径上，这个 skill 多半就不是合适的工具。

它和普通 prompt 相比有什么不同？

普通 prompt 也可以要求做安全审查，但 cosmos-vulnerability-scanner 提供的是领域化的结构、模式库和输出纪律。这样可以降低漏掉 Cosmos 特有故障模式的概率，比如 packet 信任错误、module-account 滥用，或者 EVM/Cosmos 状态不同步。它更适合你想要可重复的 cosmos-vulnerability-scanner guide 行为，而不是一次性的意见。

对新手友好吗？

如果你能识别链类型，以及定义状态转换的文件，它就算比较友好。用户在前置阶段多给一点上下文时，效果会更好：SDK 版本、IBC stack、是否有 EVM runtime，以及目标是上线前评审还是线上事故排查。新手常见的问题，是省略这些信息，却又期待 scanner 自己推断出审计边界。

什么时候不该用它？

不要把 cosmos-vulnerability-scanner 用在纯 EVM/Solidity 项目、没有 wasmd 的通用 Rust 合约，或者明显不影响共识的代码上。它也不适合只做文档工作，或者前端/客户端代码审查。如果你的目标是可用性测试而不是安全分析，应该换一条工作流。

如何改进 cosmos-vulnerability-scanner skill

提供链上下文，而不只是代码

最好的结果来自于你先告诉 skill 这条链是做什么的：DEX、staking、bridge、lending，还是通用 app chain。再补上 SDK 版本、ibc-go 版本，以及代码是否使用 x/evm、wasmd 或 ICA middleware。这样可以帮助 scanner 优先关注正确的漏洞家族，而不是把时间耗在无关项上。

直接点出高风险路径

如果你已经怀疑有 bug，直接说清楚要看哪里：keeper/msg_server.go、app.go、ante.go、IBC OnRecvPacket handlers、module account 逻辑，或者任何自定义的 BeginBlocker/EndBlocker。明确的输入通常比泛泛而谈更有效，因为它会逼着 skill 去检查 Cosmos 事故最常出问题的状态变更点。如果你知道具体功能区，也要直接说明。

从发现结果继续收窄问题

第一轮跑完后，挑出最危险的发现，再用更窄的问题重跑 skill。比如，让它重新检查某个模块是否破坏 invariant，或者某条 IBC 路径是否存在 channel trust 和 packet replay 问题。这是提升 cosmos-vulnerability-scanner usage 精度最快的方法，也能避免重复输出把你淹没。

留意常见漏检场景

最常见的失败模式，是对状态转换描述不足：代码表面上看似无害，直到它碰到 mint/burn authority、escrow、跨链回调或 precompile 边界。另一个漏检场景，是把非共识代码误认为安全，只因为它不是 handler；但如果某个 module helper 会喂给共识路径，它照样可能有危险。这个 skill 最适合在你明确告诉它状态在哪里会变化、以及是谁能触发这种变化时使用。