在區塊鏈世界，部署後的合約往往不可變；因此「上線前的審計」比任何時候都重要。
今天我們把安全審計（Security Audit）流程拆成可執行的步驟：從需求理解到工具掃描、手動 code review、測試、與最後的審計報告。目標是讓你把「審計」從抽象概念變成可複製的工作流程與檢查表。

🔹 審計的五大階段（Overview）
1. 需求理解（Scope & Threat Modeling）
2. 自動化掃描（Static Analysis）
3. 手動程式碼審查（Manual Code Review）
4. 動態測試與模糊測試（Unit tests, Integration, Fuzzing, Simulation）
5. 匯總報告與修正驗證（Report → Fix → Re-audit）

下面逐步說明每個階段的重點與可用方法。

1. 需求理解：定義範圍與威脅模型

目標：確認審計對象、邊界、重要資產與攻擊者模型。
包含內容：
• 列出要審計的合約檔案、版本、部署參數與依賴（library、proxy 佈局）。
• 明確資產（例如 ETH、USDC、ERC20、NFT）與數值敏感點（例如 reward pool、treasury）。
• 界定攻擊者類型（外部駭客、內部私鑰洩漏、validator collusion、MEV bot）。
• 產生威脅模型圖（assets / trust boundaries / attack vectors）。

輸出物：Scope 文件、Threat Model 圖、審計時間表。

2. 自動化掃描：靜態分析（Static Analysis）

目標：用工具快速找出明顯錯誤模式與常見高風險點。
常用方法/工具：
• 靜態掃描器：Slither、MythX、Securify、Manticore（部分為 dynamic / symbolic）、Echidna（fuzz）等。
• bytecode-level 檢查：查看是否有可疑的 delegatecall、selfdestruct、低等級 opcode 使用。
• 自動化報表：把工具發現的 issue 分級（高/中/低）以做優先級處理。

注意：工具能找常見模式，但會有 false positive/negative，不能替代手動審查。

3. 手動程式碼審查（Manual Code Review）

目標：由具經驗的安全工程師逐行閱讀、驗證設計與邏輯，找出工具看不到的商業邏輯錯誤與潛在攻擊面。
重點檢查清單（示例）：
• 權限邏輯是否封閉（onlyOwner / roles）？有無錯誤使用 tx.origin？
• 狀態變更順序是否遵守 Checks → Effects → Interactions？
• 是否存在未檢查的 call / delegatecall？返回值是否檢查？
• Storage layout 與 proxy 升級策略是否一致？
• 隨機數、Oracle 使用方式與防操控設計。
• 經濟模型是否可能因邊界條件被濫用（flash loan、oracle manipulaton）？
• 事件（emit）是否足夠支持事後稽核？
• 邊界條件（max/min value）、溢位風險、迴圈與 gas 限制。

技巧：多人交叉 review（pair review）、閱讀 commit 歷史、比對白皮書行為預期。

4. 動態測試（Unit / Integration / Fuzz / Simulation）

目標：在模擬環境下執行實際攻擊情境、驗證邏輯與極端條件下系統行為。
測試類型：
• 單元測試（Unit tests）：覆蓋正常與錯誤路徑，包含邊界值測試。
• 集成測試（Integration）：合約間互動、與 oracle、dex 的整合測試。
• Fuzz 測試：使用 Echidna、Foundry 的 fuzz 功能隨機生成輸入測試不變量（invariants）。
• 戰爭遊戲 / 攻擊模擬（Simulation）：模擬閃電貸 / oracle 操控 / MEV 行為（可用 Tenderly、Ganache 主幹快照、Fork mainnet）。
• Gas 與效能測試：測試在使用者規模擴大時是否會造成 DoS 或超出 block gas limit。

重點：將攻擊者視角加入測試案例（例如 “attacker tries to drain reward pool using flash loan”）。

5. 報告與修正（Audit Report → Fix → Re-audit）

目標：把發現的問題表格化、分級、建議修復方法，並在修復後驗證問題是否真正解決。
報告標準內容：
• Executive summary（高階摘要）
• Scope 與 Methodology（工具 + 人員 + 測試環境）
• Issue 列表（Severity：Critical / High / Medium / Low）
• 每個 issue 的描述、影響評估、重現步驟、修補建議與代碼片段（before/after）
• Remediation timeline（建議修復期限）
• 最後結論與 residual risk（剩餘風險）

流程：開發修正 → 安全團隊驗證（re-audit）→ 確認無重大遺留問題後發布最終報告。

🔧 可複製的審計 Checklist

Scope & Threat Modeling
• 列出待審計合約與依賴（合約地址 / repo / commit hash）
• 列出關鍵資產與最大風險面（treasury、reward pool、oracle）
• 產出威脅模型圖並標示信任邊界

Static Analysis
• Slither / MythX / Slither 輸出檢查並分類 false positives
• 檢查 bytecode 是否含有 selfdestruct / delegatecall 等危險操作

Manual Review
• 權限檢查（所有敏感函式是否有 modifier）
• Checks → Effects → Interactions 流程驗證
• Proxy storage layout / initializer 檢查
• Oracle / randomness / external call 驗證
• Event log 是否完整

Dynamic Testing
• 單元測試覆蓋率（目標 > 85% 關鍵邏輯）
• Fuzz 測試與 invariant 驗證（Echidna / Foundry）
• Fork mainnet 並在相同條件下模擬攻擊（若必要）
• Gas 與 DoS 情境測試

Reporting & Follow-up
• 撰寫分級 issue 清單並通知開發者
• 開發完成修補後做 re-audit（至少關閉所有 High/Critical）
• 最終報告包含高階摘要、修補清單與 residual risk

審計不是一次性的工作，而是「設計—驗證—改進」的循環。
最有價值的審計不是把每一個 bug 釘死，而是把風險管理能力留給團隊：知道哪些是關鍵、如何在有限時間內降低最大風險、以及在災難發生時的應變流程。
把審計流程標準化、把檢查表放入 CI、並養成在每次改動都跑自動化掃描的習慣，會讓你在面對不可逆的環境時更有底氣。