Providing Ground Truth for LLM-Based Bug Detection Tools Using Slither MCP

Slither 是 Trail of Bits 在 2018 年開發的 Solidity 靜態分析工具，最初目的是自動偵測當時極為普遍的 re-entrancy 漏洞。然而它成了自身成功的受害者：正因為開發者普遍使用 Slither，這類漏洞在合約程式碼中幾乎消失，使得 bug detector 功能的邊際價值持續下滑。到了 2025 年，在審計中跑一次 Slither 已很難直接找到真正的漏洞，其價值逐漸轉移到「printer」功能——用來印出公開函式清單、儲存槽汙染關係等結構資訊。但整體而言，維護成本高、Solidity 語言又持續演進，Slither 的未來定位成了問題。

隨著 LLM 大量進入智能合約審計流程，一個新的痛點浮現：LLM 在面對 Solidity 程式碼庫時，可用的工具極為有限，基本上只有 ls、read file 和 grep。當要分析一個函式呼叫時，LLM 可能選擇 grep 搜尋函式名稱，但這無法正確解析繼承層次，可能分析到錯誤的實作；或者它追蹤 import 路徑逐層讀檔，但這樣做既耗費大量 token，路徑解析也容易出錯。更根本的問題在於：LLM 即使明確被告知「必須使用更精確的工具」，在實際操作中仍會倒退回 read file 和 grep，因為訓練資料強烈偏向這些工具的使用模式。結果是，每次任務的完成路徑都不同，成功率充滿不確定性。

Slither MCP 的核心思路是把 Slither 的靜態分析引擎包裝成 MCP 伺服器，將原本機率性的 LLM 程式碼導航問題，轉換成確定性的 API 呼叫。Slither 內部先將 Solidity 原始碼編譯成 SlithIR 中間格式，再轉成控制流圖與 SSA 形式，建立包含完整資料流與汙染分析的 slither analysis object。透過 MCP 暴露這個物件後，LLM 只需呼叫 `get_function_callers` 就能精確取得所有呼叫某函式的位置，呼叫 `list_functions` 就能知道部署後合約實際會有哪些函式（包含所有繼承與覆寫的解析結果）——這些答案來自靜態分析，而非 LLM 的推理，因此是 100% 確定的。Trail of Bits 實測發現，當只提供 Slither MCP 而移除 read file 和 grep 時，LLM 完成任務的成功率反而高於同時擁有三種工具的情況。

在 Q&A 環節，講者進一步表達了對「更大模型解決一切」的保守態度。他認為，當前 LLM 過度依賴訓練時習得的工具使用習慣，單純放大模型規模不太可能根本改變這種行為模式。他預測產業走向是更小的任務專用模型，而非持續擴大通用模型。至於 fine-tuning 小型模型（如 BERT、DistilBERT）的可行性，他承認資料不是問題（Solidit 等平台已有大量公開審計報告），但在工具集本身尚未穩定的階段投入 fine-tuning 成本，風險太高，Trail of Bits 目前內部主要仍依賴 GPT-4 mini 等小型通用模型。