智慧合約安全初篩系統 (SCSA)
以 Slither AST 靜態分析與 SQLite 資料儲存為核心，限制 LLM 解釋範圍的 Solidity 初篩工具。
目前進度與實測現況
- Slither 靜態分析引擎 AST 解析，涵蓋 27 條已對應的偵測規則
- 對應至標準 CWE 與 SWC 弱點分類識別碼
- SQLite 證據圖譜（Evidence Graph）記錄規則代碼、AST 節點與行號範圍
- React 審查介面支援雙欄對照與弱點過濾
- LLM 說明嚴格綁定已確認的 AST 節點，禁止自由推測弱點
- Slither50 v2 基準測試中仍有 4 筆誤報（重入攻擊與 delegatecall 判斷）
- 為防止惡意程式碼執行，預設關閉編譯器原生建置腳本
- 僅為輔助初篩工具，無法取代人工安全審計或形式化驗證
01 · 想要解決的問題
直接用生成式 AI 分析智慧合約安全時，模型常常出現幻覺：例如憑空捏造不存在的重入漏洞或亂編 CVE 編號。另一方面，傳統靜態分析工具（如 Slither）直接跑出來的日誌往往過於冗長雜亂，初學者很難一眼看出重點。
做 SCSA 是想把兩者的優勢結合：由靜態分析器負責找出確切的程式碼依據，存入本機 SQLite；再由本機 LLM 只針對這些已經找出的問題點進行說明與提供修補建議，避免模型隨意發揮。
02 · 實作前提與限制
LLM 不能自行新增合約漏洞。報告中列出的所有問題，都必須有 Slither 語法樹上的明確偵測紀錄。
分析外部未經檢驗的專案時，預設不執行其 Makefile 或 npm 安裝腳本，防止惡意腳本在本機跑起來。
報告裡的每個項目都能對應到檔案路徑、AST 節點、具體行號與使用的偵測規則。
03 · 分析流程與模型限制
未受信任的合約原始碼透過防護層進入 Slither 分析，整理後的結果存入 SQLite，成為 LLM 解釋時的唯一上下文。
靜態分析與限制範圍的解釋機制
01. 匯入防護：匯入未受信任的 Solidity 程式碼時做路徑檢查，預設不執行專案自帶的編譯腳本以策安全。
02. 語法樹分析：執行 27 項已對應的 Slither 偵測規則，產出精確的程式碼行號與呼叫關係。
03. 格式整理：將不同偵測器的輸出轉換成統一資料結構，並對照 CWE/SWC 分類。
04. 資料儲存：將抓到的問題點存入本機 SQLite，作為後續說明的唯一依據。
05. 輔助說明：LLM 只能根據 SQLite 裡的紀錄解釋問題與建議改法，不允許額外發揮。
04 · 三項主要技術取捨
1. 以分析器結果為準，LLM 只負責說明
控制模型範圍評估考量：直接把整份合約丟給 LLM 判斷安全性，誤報率非常高，而且容易虛構問題。
採用的做法：只挑選 27 項對應清楚的 Slither 偵測器納入正式初篩報告。其他未對應的輸出先留在 SQLite 當原始日誌。模型只負責解釋這些已經找出的問題。
結果與取捨：在 50 個合約的 Slither50 測試中，成功抓出所有預期漏洞（召回率 100%），且每條問題都有具體程式碼依據。
2. 預設停用本機編譯腳本
安全性評估考量：直接編譯外部下載的 Foundry 或 Hardhat 專案，可能會不小心執行到專案裡的惡意腳本。
採用的做法：預設只用 solc-select 做單檔語法解析，不執行專案自帶的建構指令。只有在使用者明確加上 --allow-native-builds 時才開放完整編譯。
結果與取捨：避免了在初篩外部合約時，本機環境遭受惡意程式碼執行的風險。
3. 沒有本機模型時也能正常運作
降級備援評估考量：使用者的電腦不一定有高階 GPU 或 Apple Silicon，不一定跑得動本機語言模型。
採用的做法：如果本機有裝 Apple MLX 則產出輔助解說；若沒有模型環境或在離線狀態，系統就直接顯示內建的靜態安全規則說明與 CWE 參考文件。
結果與取捨：即便完全不接任何 LLM，CLI 工具與網頁介面依然能完整檢視所有靜態分析結果。
05 · 遇過最棘手的問題
把格式各異的 Slither AST 輸出整理成統一結構
問題原因：Slither 內部各個偵測器輸出的 JSON 結構很不一致：有些只指到單一表達式，有些指到變數，重入攻擊偵測器甚至會跨越多個合約的函式呼叫鏈。
解決方式：用 Python 寫了一套正規化解析器，把不同偵測器的資料統一轉換成 SecurityFinding 格式，提取對應的行號與程式碼片段並做雜湊去重，最後存入 SQLite。
測試結果：寫了 140 個 pytest 測試案例，包含鑽石代理合約（Diamond Proxy）與組合語言（Yul）等特殊寫法，確認資料都能正確解析。
06 · 測試表現與已知限制
任何工具都有極限。在公開的 Slither50 v2 測試中，這套系統抓出了全部已知漏洞（100% 召回率），但也產生了 4 起誤報。
07 · 測試與打包數據
測試後端 Slither 解析、solc 版本切換、SQLite 讀寫與 CLI 指令。
測試 React 介面元件、問題篩選器與程式碼比對顯示。
透過 Hatchling 打包，驗證 source dist 與 binary wheel 能正常安裝。
在測試合約中，安全合約平均得分 8.2 分，有漏洞合約平均得分 53.25 分。
08 · 專案回顧
專案心得：做智慧合約安全工具，最忌諱的是給人一種「AI 說沒問題就真的沒問題」的虛假安全感。把「確定性工具（Slither）」與「語言模型」清楚切開，讓靜態分析器負責抓問題、模型只負責講清楚原因，這樣既安全又實用。
如果重做會做的調整：如果重新規劃，我會想在初期就加入形式化驗證工具（如 Halmos），在靜態分析器報出可疑問題後，先用約束求解自動篩掉一部分誤報，減少人工複查的時間。