DeFi Security Summit 2023 - Session 17: Focused Talks 3 - Felix Wegener
三句話摘要
100%測試覆蓋率無法保證智能合約安全，需要採用「exploit POC」驅動的安全測試策略。 --- 要實現智能合約真正的安全性，必須從測試「功能存在」轉向測試「不當功能不存在」，並將exploit驅動的安全測試融入開發流程。 功能測試與安全測試本質差異
重點整理
重點- 1
功能測試與安全測試本質差異
- 2
功能測試衡量代碼「做了什麼」（如代碼覆蓋率），而安全測試必須驗證代碼「沒有做什麼」。講者以ERC20代幣為例，儘管達到100%測試覆蓋率且三個基本功能（鑄造、燒毀、轉移）都能正常工作，卻存在任何人可燒毀他人代幣的重大漏洞——這是典型的缺失負測試案例（驗證非授權調用應被拒絕）。
- 3
採用駭客思維進行安全測試
- 4
開發者應在迭代循環中創意性地編寫exploit POC，嘗試攻擊自身協議，驗證漏洞，修復後再驗證，最後將POC永久轉化為測試案例。這使安全測試變得更吸引人，因為它本質上就是「有目的的駭客活動」，比傳統單元測試更富有挑戰性。
- 5
經濟學支持早期測試投入
- 6
IBM研究表明，設計與實現階段發現缺陷成本最低，部署後修復成本呈指數增長。區塊鏈系統因涉及巨額資金（TVL），成本差距更加懸殊，使系統化安全測試成為必要投資。
- 7
簡化安全測試度量指標
- 8
高層決策者應採用單一指標：統計測試套件中基於exploit POC的有趣測試案例數量，而非盲目追求代碼覆蓋率百分比。
- 9
--
實用技巧與重點
乾貨- 測試覆蓋率類型：line coverage、branch coverage（功能指標，非安全指標）
- 安全測試焦點：absence of functionality（測試未授權調用、不合規操作能否執行）
- 2025年數據：代碼漏洞已造成2.5億美元損失
- IBM成本模型：設計→實現→測試→部署各階段發現缺陷的成本差異
- 測試方法論循環：while true → creative POC exploit → verify failure → integrate as test case
- 範例工具：Foundry框架（語法：test_fail 進行負測試）
- 決策指標：基於exploit POC的測試案例數量
- --
結論
結論“要實現智能合約真正的安全性，必須從測試「功能存在」轉向測試「不當功能不存在」，並將exploit驅動的安全測試融入開發流程。”
完整解析
詳細區塊鏈生態中普遍存在一個根本誤區：開發者將100%代碼測試覆蓋率等同於安全性。Felix用一個簡單ERC20代幣合約揭示了這個謬論。該合約在Foundry驗證下達到100%測試覆蓋率，包括鑄造、燒毀、轉移三個標準功能都能正常運作。然而它存在致命漏洞——任何人都可燒毀任意用戶的代幣，這是典型未授權訪問漏洞，實際安全性評分為零。缺失的是一個負測試案例：驗證非持有者無法燒毀他人代幣。
Felix進一步區分了測試的兩個維度。功能測試關注「代碼做了什麼」，用代碼覆蓋率衡量；安全測試則需驗證「代碼沒有做什麼」，即不應被執行的操作確實無法執行。大多數開發團隊停留在功能測試，真正安全測試需轉換思維——用駭客思維編寫exploit POC並嘗試攻擊自身協議。
他提出可迭代的方法論：創意性設計exploit POC → 驗證漏洞 → 修復並重新驗證 → 將POC永久化為測試案例。這使安全測試更吸引人，因為本質上就是「有目的的駭客活動」，比傳統單元測試更有趣。經濟學數據支持此做法：IBM研究表明，設計和實現階段發現缺陷成本遠低於部署後修復。在區塊鏈領域，由於涉及巨額資金，成本差異更懸殊。
過去一年已有2.5億美元因代碼漏洞被盜，這些漏洞都可透過系統化安全測試預防。Felix建議決策層用單一指標——統計測試套件中基於exploit POC的有趣案例數量，作為安全測試質量衡量標準。他也強調沒有銀彈方案，建議項目內部開始實施此方法，並與專業安全審計夥伴合作進一步強化策略。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
