智慧合約審計中的危險訊號：購買前如何閱讀安全報告

更新於2026年9月14日。智能合約審計可以提供有用的證據，但它並非安全證書。最重要的問題不是“這個專案是否經過審計？”，而是“究竟審計了哪些內容？審查了哪個版本？還有哪些問題尚未解決？已部署的程式碼是否仍然與審查過的系統相符？”

以太坊的安全指南明確指出，審計並非萬能靈藥，無法發現所有漏洞。 OpenZeppelin 的稽核工作流程同樣將範圍、發現、嚴重程度、修復狀態和修復審查視為安全評估的不同組成部分。因此，對於購買者而言，實際的目標是將報告視為風險評估文件，而不是行銷宣傳品。

快速危險訊號檢查清單

第一步：確認報告真實有效且出自審計師之手

標題：在閱讀具體調查結果之前，請先查看報告的身份、日期、審核員和嚴重性摘要。

經核實：信譽良好的審計報告通常會明確指出專案、評估週期、審計員以及被審查的代碼。 OpenZeppelin 發布的報告和 Consensys 的盡職調查報告通常包含範圍部分和程式碼版本資訊。例如，Consensys 的 USDKG 報告會指出被審查的特定提交雜湊值，而 OpenZeppelin 的報告則會明確指出審查範圍內的程式碼庫以及特定的提交或拉取請求。

迷思：項目上傳的PDF檔案因為包含審核員的標誌就自動可信。但這並不足以保證其可靠性。文件可能已過時、被修改或脫離了其原始上下文。

行動：盡可能透過審計機構的網站或儲存庫查找報告。將項目名稱、報告日期、URL 和版本資訊與代幣團隊共享的副本進行比較。

主要參考資料：OpenZeppelin 審計文件和Consensys Diligence USDKG 審計。

步驟二：在得出調查結果之前，先閱讀範圍說明

標題：審計徽章不如審計範圍重要：要明確指出審查了哪些合約和組成部分。

審計僅涵蓋範圍之內的內容。一份報告可能審查代幣合約，但不包括質押、橋接、金庫、治理、前端基礎設施、外部依賴項或後續升級。

經核實： OpenZeppelin 的 Panoptic 審計報告列出了審計範圍，並指出修復程序分佈在不同的程式碼倉庫中。另一份關於 EVM 模擬器的 OpenZeppelin 報告明確指出，審計僅針對特定拉取請求中的更改，而非所有文件。這些例子表明，「專案已進行審計」可能是一個過於寬泛的結論。

誤解：如果對生態系統中的合約進行審計，就意味著整個協議都受到了影響。事實並非如此。

操作：列出所有可以持有資金、轉移資金、設定價格、更改權限、鑄造代幣或升級合約的組件。然後標記每個組件是否在審計範圍內。任何重要的空白處都應作為後續問題。

參考範例：OpenZeppelin Panoptic 審核和OpenZeppelin EVM Emulator 審核。

步驟 3：將提交哈希值與實際部署的程式碼進行匹配

標題：報告與代碼版本相關聯；請驗證經審計的版本是否仍與已部署的合約相符。

這是最容易被忽略的檢查之一。即使審計工作做得非常出色，專案方之後也可能修改了程式碼。

已驗證： OpenZeppelin 的程式碼檢查器文件指出，報告與特定的提交相關聯，而以太坊的合約驗證指南解釋說，經過驗證的原始程式碼可以幫助用戶確定已發布的原始程式碼與已部署的字節碼相對應。

誤解：「上個月審計過」就意味著今天部署的合約就是經過審計的合約。單憑時間並不能證明這一點。

操作：在報表中找到提交雜湊值、標籤或拉取請求。然後檢查專案的部署文件以及相關程式碼區塊瀏覽器上的已驗證原始程式碼。如果已部署的實作較新，請尋找後續審核或已記錄的差異審查。

主要參考資料：OpenZeppelin 程式碼檢視器文件和Ethereum.org 合約驗證指南。

第四步：像重視病情嚴重程度一樣重視病情發現狀態

標題：「嚴重」、「高」或「中」只是問題的一半；請檢查每個問題是否已解決、部分解決或仍未解決。

嚴重性表示發現問題的潛在重要性。狀態表示後續處理結果。 OpenZeppelin 的審計工具區分了已解決、部分解決、已確認但未解決以及無回應等狀態。

誤解：「審計完成」表示專案已經解決了所有問題。事實並非如此。即使審計已經完成，但仍可能存在一些尚未解決的問題。

行動：列出所有嚴重和高優先級問題，然後記錄其最終狀態和修復審查的證據。對於中等優先順序的問題，如果多個問題指向相同設計缺陷，例如門禁控制、價格操縱或會計錯誤，則需格外注意。

也不要輕易忽略低嚴重性問題。它們的重要性取決於系統情境、與其他問題的組合，以及特權使用者如何使用受影響的功能。

第五步：閱讀調查結果、影響、前提條件和解決方案——而不僅僅是標題。

標題：嚴重性標籤只是一個起點；了解漏洞利用條件、受影響的資產以及審計人員的理由。

有用的安全發現通常會解釋可能出現的問題、其重要性、相關程式碼路徑、前提條件以及建議。需要管理員權限才能觸發的「高風險」安全性發現，可能代表與任何使用者都能觸發的無需許可的漏洞利用不同的實際風險。

經核實： OpenZeppelin 將問題嚴重性描述為反映了影響範圍、可能性和利用難度等因素。 Trail of Bits 對 246 個智慧合約漏洞的分析也發現，嚴重問題出現在多個類別中，而不僅僅是常見的重入漏洞類型。他們的資料集強調了存取控制、身份驗證、時序、數值計算、驗證和其他類別都是重要的風險來源。

誤解：重入漏洞是唯一值得關注的智慧合約漏洞。事實並非如此。業務邏輯、存取控制、驗證、預言機設計和記帳同樣重要。

行動：針對每一項嚴重發現，回答以下四個問題：誰會觸發該問題？他們會獲得什麼或造成什麼損失？需要哪些假設？是否審查過具體的解決方案？

主要參考資料：OpenZeppelin 審計問題模型、Trail of Bits 對審計結果的分析以及Solidity 安全考量。

步驟 6：檢查特權角色、管理員金鑰、暫停、鑄造和升級權限

標題：特權函數值得特別關注，因為安全的程式碼路徑仍然可能帶來治理或金鑰管理風險。

許多協議都特意設定了特權角色。這並不意味著它們一定不安全，但確實改變了信任模型。

經核實：以太坊智能合約安全指南警告稱，單一所有者可能成為中心故障點。指南指出，基於角色的存取控制和多重簽章控制是降低這種風險的方法。 OpenZeppelin 的時間鎖定文件解釋說，延遲執行可以讓使用者有時間審查維護操作並在適當的時候退出。

誤解：「沒有嚴重漏洞」意味著管理員不能損害使用者利益。審計的嚴格程度和治理權限是兩個不同的問題。

操作：在報告中搜尋諸如owner、、、、、、、、、、和之類的詞語。然後確定目前每個角色由誰擔任，以及該角色可以多快採取行動。adminrolemultisigtimelockpausemintupgradeblacklistwithdraw

主要參考資料：以太坊智能合約安全指南和OpenZeppelin 存取控製文件。

步驟 7：檢查可升級性、Oracle、橋接器和其他外部信任假設

標題：審核信任邊界，而不僅僅是 Solidity 檔案——代理、預言機、橋接器和外部依賴項可能會改變實際風險。

可升級代理程式可以在更改實現邏輯的同時保持相同的公鑰位址。預言機可以提供決定清算的價格。橋接器可以引入獨立的託管或驗證器假設。外部函式庫和協定可以獨立失效。

經核實： OpenZeppelin 的文檔指出，基於代理的系統會將穩定的代理位址與可更改的實作程式碼分離。其文件還警告說，升級需要經過嚴格的授權。以太坊的安全指南解釋了預言機操縱的風險，並指出錯誤的價格輸入可能導致合約使用錯誤資料執行。

誤解：代理位址上的已驗證原始碼證明未來的行為不會改變。但對於可升級系統而言，情況並非總是如此。

行動：確定合約是否可升級、升級授權人是誰、升級是否會延遲以及目前實施方案是否經過驗證。然後列出所有可能導致用戶資金損失的外部系統。

主要參考資料：OpenZeppelin代理文件和以太坊智能合約安全指南。

步驟 8：根據剩餘風險做出買進/迴避/調查決策

標題：最終決定應反映修復後仍存在的風險，而不是是否存在審計徽章。

即使修復了漏洞，風險依然存在。 OpenZeppelin 在已發布的審計報告中明確指出，有時限的審查無法保證發現所有漏洞或風險。例如，在 Audius 審計中，審計人員在發現大量嚴重問題後建議進行 beta 測試、漏洞賞金計畫以及後續的重新審計。在 Panoptic 審計中，他們建議增加監控，並在程式碼發生重大變更後再次進行審計。

誤解：多次審計可以將智能合約風險降至零。事實並非如此。多次審計可以提高安全性，但安全性還取決於部署的準確性、維運、管理員金鑰的安全性、監控、事件回應、經濟假設以及未來的升級。

行動：將項目歸入以下三個類別之一：

• 購買/繼續研究：目前部署的程式碼符合審查範圍；嚴重發現的問題已解決並重新檢查；特權權限是可以接受和透明的；外部依賴關係已了解。
• 進一步調查：關鍵資訊缺失、審計早於重大升級，或某些中/高問題僅部分解決或確認。
• 目前應避免：嚴重/高風險問題仍未解決，部署與審計版本不符，核心合約超出範圍，或管理員對用戶資金的單方面控制揭露不充分。

如何解讀常見的審計術語

五種危險訊號，應立即停止

1. 此項目無法顯示審計師提供的原始報告。僅提供螢幕截圖或徽標是不夠的。
2. 該報告缺乏可複現的範圍或版本資訊。沒有提交記錄、標籤或具體文件，很難知道審查了哪些內容。
3. 關鍵或重要問題仍未充分論證，缺乏強有力的書面理由。
4. 該協議是可升級的，但報告幾乎沒有討論升級權限或特權角色。
5. 審計後部署情況發生了重大變化，且沒有後續審查報告可供查閱。

如果出現上述任何情況，最穩健的做法是不要試圖為其辯解，而應暫停投資決策並要求提供最新證據。

10分鐘購前審核報告流程

1. 開啟審計機構官方網站上的報告。
2. 記錄報告日期、儲存庫、範圍和提交雜湊值。
3. 確認已部署的合約和實施地址。
4. 閱讀所有關鍵和重要發現。
5. 檢查每個重大問題的最終狀態。
6. 尋找特權角色和緊急權力。
7. 找出代理升級及其控制者。
8. 識別預言機、橋樑、託管系統和外部依賴關係。
9. 尋找經審核的提交之後所做的變更。
10. 購買前請確定您能接受的剩餘風險。

結論

智能合約審計僅是審查的證據，而非安全性的證明。最有力的證據並非審計機構的標誌，而是連接清晰的審計範圍、精確的代碼修訂、重大發現、已驗證的修復、已部署的字節碼以及透明的運維控制的證據鏈。

最危險的閱讀誤解是止步於「已審核」。更有價值的問題是：審核之後還可能出現哪些問題？如果您能清楚地回答這個問題，並且對剩餘風險感到滿意，那麼您就做出了更明智的決定。如果範圍、修復狀態、管理員權限或部署版本不明確，正確的做法是在購買前進行調查。

原始資料

• Ethereum.org：智能合約安全
• Ethereum.org：驗證智能合約
• Solidity 文件：安全注意事項
• OpenZeppelin Defender：審核
• OpenZeppelin：什麼是智慧合約審計？
• OpenZeppelin 合約：代理文檔
• Consensys 盡職調查：USDKG 審計
• 智慧合約審計的 246 項發現：追蹤比特流

本文僅供參考，不構成財務建議。審計無法消除智能合約風險、治理風險、預言機風險、經濟風險、營運風險或市場風險。