What’s Broken In Web3 Security Today | Ben Sepanski
三句話摘要
Web3 專案的安全審計應從設計階段提前介入，由開發者主導自我驗證，再由第三方複核，而非完全仰賴末期外部審計。 --- Web3 安全不應是上線前最後一道關卡，而應由開發者持工具從設計階段主導驗證，第三方審計只負責複核，才能真正建立可擴展的系統信心。 審計時機過晚導致高風險決策環境：安全測試集中在開發末期，一旦發現嚴重問題，團隊在極度時間壓力下倉促決策，這是解決安全問題最糟糕的環境。
重點整理
重點- 1
審計時機過晚導致高風險決策環境：安全測試集中在開發末期，一旦發現嚴重問題，團隊在極度時間壓力下倉促決策，這是解決安全問題最糟糕的環境。
- 2
過度依賴第三方是結構性缺陷：將安全責任完全委託給外部審計員，本質上是把核心信任押注在一個對系統了解最少的組織身上，風險分佈極不合理。
- 3
開發者的知識未被充分利用：花費數月設計系統的人最了解其邏輯與邊界條件，但目前缺乏工具讓他們將這些知識轉化為可驗證的安全保證，導致審計員無法獲得最有效的測試資訊。
- 4
安全前移能帶來乘數效益：若安全意識提早進入設計生命週期，設計者會主動確保架構穩固，上線前的變更量減少，第三方審計也能更快、更有信心地完成複核。
- 5
--
實用技巧與重點
乾貨- 問題一：安全審計集中在「專案生涯最後階段」，時間壓力導致安全決策品質下降
- 問題二：安全責任轉移給第三方審計員，組織對單一外部機構信任過高
- 問題三：開發者缺乏工具，無法將系統知識轉化為審計員可用的有效測試基礎
- 解法：Security-by-Design，安全流程提前到設計階段
- 工具需求一：能幫助開發者「證明問題不存在」的自我驗證工具
- 工具需求二：讓開發者知道「已完成什麼、已預防什麼」的追蹤工具
- 測試哲學：應為「探索性測試（exploration）」而非「為測試而測試（testing for testing）」
- 最終模型：開發者提供工具 + 驗證流程 → 第三方負責複核，而非從頭發現
- 明確點名問題：不可能靠「兩人小團隊」維持整個系統的安全信心
- --
結論
結論“Web3 安全不應是上線前最後一道關卡，而應由開發者持工具從設計階段主導驗證，第三方審計只負責複核，才能真正建立可擴展的系統信心。”
完整解析
詳細Web3 生態中，安全審計普遍存在三個根本性缺陷，共同造成系統上線時的高風險狀態。第一個問題是時機：幾乎所有安全測試都集中在專案開發的最後階段。這個時間點最為危險，因為一旦審計員發現嚴重漏洞，整個團隊必須在極度時間壓力與疲憊狀態下倉促做出安全決策。這種環境幾乎是解決安全問題的最差條件。
第二個問題是信任的錯誤分佈。目前業界習慣將安全責任完整外包給第三方審計機構，等於是把整個系統的安全信心押注在一個對系統了解最淺的組織。開發者應該是最了解系統邊界、業務邏輯與設計意圖的人，但在現有流程中，他們的角色在安全驗證上幾乎缺席。第三個問題由此延伸：開發者缺乏適當工具將自身的知識轉化為可驗證的安全保證，審計員也因此拿不到最有價值的測試基礎，被迫從零開始探索，效率低落且容易遺漏。
解法是將安全流程前移至設計生命週期的早期階段，並分為兩個維度。第一個維度是時間：當安全討論提早發生，開發者在設計時就會主動思考穩健性，到上線前需要緊急修改的情況大幅減少，系統架構本身也會更安全。第二個維度是工具：開發者需要兩類工具，一是能主動驗證「特定漏洞不存在」的證明工具，二是能記錄「已測試什麼、已預防什麼」的追蹤工具，讓安全工作可被量化與傳遞。
在此框架下，第三方審計員的角色從「從頭發現所有問題」轉變為「驗證開發者已完成的工作與所提供的工具是否充分可信」。這種分工不僅讓審計更快速、成本更低，也讓整個系統的信心建立在多層次的相互驗證上，而非單靠一個外部機構的判斷。講者最後強調，沒有任何組織能靠少數人的小團隊維持一個完整系統的安全信心，結構性改變是唯一出路。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
