cosmos-vulnerability-scanner

cosmos-vulnerability-scanner 技能概覽

cosmos-vulnerability-scanner 的用途

cosmos-vulnerability-scanner 技能專門用來找出 Cosmos SDK 程式碼、CosmWasm 合約、IBC 整合，以及 Cosmos EVM 堆疊中的共識關鍵漏洞。它聚焦的是會讓鏈停擺、破壞共識、造成狀態不同步或資金損失的問題，而不是一般性的程式碼異味。如果你是在做 cosmos-vulnerability-scanner for Security Audit 這類工作流程，當你的問題是「這條鏈會不會被利用或直接打掛？」而不是「程式碼乾不乾淨？」時，這個技能才是對的選擇。

適合安裝的人

如果你在審查自訂 x/ 模組、橋接或 IBC 邏輯、尚未上線的 app chain，或是具有明顯鏈上價值的 CosmWasm 合約，就很適合使用 cosmos-vulnerability-scanner 技能。當你的團隊需要有結構地掃過多種類型的漏洞，而不是靠臨時 prompt 逐段看碼時，它特別有幫助。相較之下，它對純 Solidity 稽核、一般 Go 程式碼審查，或是應用層以外的鏈元件就沒那麼有用。

這個技能有什麼不同

這個技能不只是檢查清單；它會依照漏洞類別來組織掃描，並輸出分開的 markdown 發現結果。這一點很重要，因為 Cosmos 的問題常常同時牽涉多個面向：狀態帳務、IBC 封包處理、模組權限，以及 EVM/Cosmos 的原子性。支援的 resources/ 檔案會提供具體的模式家族，這比單純一句「請檢查 bug」的提示更有可操作性。

如何使用 cosmos-vulnerability-scanner 技能

安裝並指向正確的 repo

在執行 cosmos-vulnerability-scanner install 時，先用你環境標準的 skills 指令把技能加入 agent workspace，然後在掃描目標 repo 之前，先打開技能檔與連結的支援文件。實務上，當你明確告訴它要分析哪個 codebase、以及輸出要寫到哪裡時，效果最好。預設輸出目錄是 .bughunt_cosmos/，但如果你的工作流程需要別的位置，應該自行覆寫。

提供正確的輸入形狀

一個好的 cosmos-vulnerability-scanner usage prompt 應該包含：repo 路徑、鏈類型、應用目的，以及任何已知的高風險熱點。舉例來說：「掃描這個 Cosmos SDK app chain，找出自訂模組、IBC handlers，以及 module-account 邏輯中的共識關鍵問題。重點放在 pre-blocker、msg servers、keeper 寫入，以及任何可能影響供應量、共識或跨鏈轉帳的程式碼。」這比「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 檔。這些檔案會告訴你這個技能實際在檢查什麼，避免漏掉整類 bug。

採用務實的稽核流程

先分類這條鏈：純 Cosmos SDK、支援 IBC、CosmWasm，或 Cosmos EVM。接著盤點自訂模組、ABCI hooks、keepers 和 message servers，因為這些元件決定攻擊面。然後優先跑最高風險路徑：狀態變更、權限檢查、封包接收／回覆處理器，以及任何碰到 bank、staking、authz 或 module accounts 的地方。這樣比照 repository 的檔案順序一路掃，結果會好得多。

cosmos-vulnerability-scanner 技能 FAQ

這只適合完整鏈的稽核嗎？

不是。cosmos-vulnerability-scanner 技能也很適合局部審查，例如單一自訂模組、單一 IBC middleware stack，或單一 CosmWasm 合約套件。關鍵是程式碼必須會影響共識狀態、代幣流動，或跨鏈行為。如果你的審查目標不在這條路徑上，這個技能大概率不是對的工具。

跟一般 prompt 比起來差在哪？

一般 prompt 可以要求安全審查，但 cosmos-vulnerability-scanner 會提供領域專屬的結構、模式庫與輸出規範。這能降低漏掉 Cosmos 特有失敗模式的機率，例如封包信任判斷錯誤、module-account 濫用，或 EVM/Cosmos 狀態不同步。當你想要的是可重複的 cosmos-vulnerability-scanner guide 行為，而不是一次性的主觀判斷時，它會更合適。

這個技能適合新手嗎？

可以，只要你能辨識鏈類型，以及定義狀態轉換的檔案。當使用者先提供一些背景資訊時，這個技能的價值更高：SDK 版本、IBC stack、是否有 EVM runtime，以及目標是上線前審查還是線上事故處理。新手常見的問題，是省略這些背景，卻期待掃描器自己推斷稽核邊界。

什麼情況下不該用？

不要把 cosmos-vulnerability-scanner 用在純 EVM/Solidity 專案、沒有 wasmd 的一般 Rust 合約，或明顯不會影響共識的程式碼上。它也不適合只做文件工作或前端／客戶端程式。如果你的目標是可用性測試，而不是安全分析，請改用其他工作流程。

如何改進 cosmos-vulnerability-scanner 技能

提供鏈的背景，而不只是程式碼

最好的結果，通常來自你先說清楚這條鏈是做什麼的：DEX、staking、bridge、lending，或通用 app chain。再補上 SDK 版本、ibc-go 版本，以及程式碼是否使用 x/evm、wasmd 或 ICA middleware。這樣掃描器就能優先處理正確的漏洞家族，而不是把時間花在無關的地方。

直接點名高風險路徑

如果你已經懷疑有 bug，直接說要看哪裡：keeper/msg_server.go、app.go、ante.go、IBC 的 OnRecvPacket handlers、module account 邏輯，或任何自訂的 BeginBlocker/EndBlocker。明確的輸入通常比籠統的描述更有效，因為它會逼技能去檢查 Cosmos 事故最常發生的狀態變更點。如果你知道某個功能區塊，也要直接講出來。

從發現結果迭代到更窄的提示

第一輪跑完後，把風險最高的發現拿去，再用更精準的問題重跑一次技能。比如，要求它重新檢查某個模組是否會破壞 invariant，或某條 IBC 路徑是否有 channel trust 與 packet replay 問題。這是提升 cosmos-vulnerability-scanner usage 精準度最快的方法，也能避免輸出一堆重複內容。

注意常見漏抓情況

最常見的失誤，是對狀態轉換描述得太少：程式碼乍看無害，但一旦碰到 mint/burn 權限、escrow、跨鏈 callback，或 precompile 邊界，就可能出問題。另一個漏抓情況，是把非共識程式碼直接視為安全，只因為它不是 handler；其實只要某個 module helper 會進到共識路徑，它仍然可能很危險。當你明確告訴技能哪裡會改狀態、誰能觸發那個變更時，效果最好。