What your auditor REALLY thinks but is afraid to tell you...

Web3 安全審計不是簽署報告就安全，而是項目方與審計公司間的長期責任分工。這場論壇由五家頂級安全公司代表闡述一個核心觀點：審計是項目準備狀況的鏡像，不是安全的保險。

問題的根源在於時間壓力與預算限制。Sigma Prime 的 Medi 分享了一個典型案例：某借貸協議提交審計時，提供了數千行 Solidity 代碼但幾乎沒有單元測試。他們按慣例在本地部署協議、執行基本的存取穩定幣操作，結果直接失敗。這表明項目方根本未進行最基礎的集成測試。類似情況屢見不鮮，暴露出開發團隊對「審計前準備」的誤解。

審計應該盡早進行，而非在部署前夕才倉促上馬。長期開發週期（如一年的協議）應每季進行安全諮詢，讓審計人員在設計階段提供反饋，而非等代碼凝固後才發現結構性缺陷。設計層面的問題（如重放攻擊防護缺失）無法通過編碼修補，只能重新設計。這就是為什麼項目方應在與投資者溝通、撰寫白皮書時就將安全納入考量。

常見的安全誤區包括多重簽名陷阱。許多項目假設 8/11 多重簽名很安全，卻忽略了 7 把密鑰可能存在同一個 AWS 實例上，或由不懂技術的董事會成員盲目簽署。真正的多重簽名安全需要簽名儀式與威脅建模：每位簽署人必須獨立持有密鑰，且難以被單一實體控制。次等的多重簽名不會帶來安全提升，反而增加複雜度。

依賴管理也被嚴重忽視。供應鏈攻擊曾一度被視為遠景風險，近年已多次發生。項目應識別所有外部依賴、監控其安全更新、並在集成新代幣（如 USDT）時進行文件記錄。當團隊人員流動時，這些文件能保護後來者免於重複犯錯。

審計公司無法承諾「安全」，只能說「基於現有反饋，已盡力提升安全水平」。時間限制是根本約束：給三週與給三個月的審計發現率差異巨大。若審計期間持續發現關鍵漏洞，這不代表審計人員不專業，而是項目方準備不足。責任在項目方決定何時上線，審計公司只提供訊息。

為填補行業知識空白，業界推出了 Frameworks（security alliance.org），一份涵蓋開發者、DevOps、社區經理等角色的 Markdown 最佳實踐指南。這試圖解決「應該做什麼」的困境，但最關鍵的仍是認知轉變：安全不是外部供應商的事，而是項目方的核心責任。