Cetus 安全問題啓示：DeFi 團隊要注意些什麼？

純技術背景的團隊嚴重缺乏基本的「金融風險嗅覺」。

撰文：Haotian

讀完 @CetusProtocol 的黑客攻擊安全「復盤」報告，你會發現一個「耐人尋味」的現象：技術細節披露得相當透明，應急響應也堪稱教科書級別，但在最關鍵的「爲什麼會被黑」這個靈魂拷問上，卻顯得避重就輕：

報告用大量篇幅解釋integer-mate庫的checked\_shlw函數檢查錯誤（應該≤2^192，實際≤2^256），並將此定性爲「語義誤解」。這種敘述雖然在技術上成立，但巧妙地將焦點引向了外部責任，仿佛 Cetus 也是這個技術缺陷的無辜受害者。

問題來了，既然integer-mate是一個開源且廣泛應用的數學庫，偏偏在你這發生了 1 個 token 便可獲得天價流動性份額的荒謬錯誤？

分析黑客攻擊路徑會發現，黑客要實現完美攻擊必須同時滿足四個條件：錯誤的溢出檢查、大幅位移運算、向上取整規則、缺乏經濟合理性驗證。

Cetus 恰恰在每一個「觸發」條件上都「疏忽大意」了，比如：接受用戶輸入 2^200 這樣的天文數字，採用極度危險的大幅位移運算，完全信任外部庫的檢查機制，最致命的是——當系統計算出「1 個 token 換天價份額」這種荒謬結果時，竟然沒有任何經濟常識檢查就直接執行了。

所以，Cetus 真正應該反思的點如下：

1）爲什麼採用通用外部庫沒做好安全測試？雖說integer-mate庫有開源、流行、廣泛使用等特性，Cetus 用它來管理上億美元的資產卻沒有充分了解這個庫的安全邊界在哪裏，如果庫作用失效有沒有合適的備選方案等等。顯然，Cetus 缺乏最基礎的供應鏈安全防護意識；

2）爲什麼會允許輸入天文數字而不設邊界？雖說 DeFi 協議應尋求去中心化，但一個成熟的金融系統越是開放卻越是需要明確的邊界。

當系統允許輸入攻擊者精心構造的天文數字時，團隊顯然沒思考過，這樣的流動性需求合理嗎？即使是全球最大的對沖基金，也不可能需要如此誇張的流動性份額。顯然，Cetus 團隊缺乏具備金融直覺的風險管理人才；

3）爲什麼經過多輪安全審計卻依然沒預先發現問題？這句話無意中暴露了一個致命的認知誤區：項目方將安全責任外包給安全公司，把審計當成了免責金牌。但現實很殘酷：安全審計工程師擅長發現代碼 Bug，誰會想到去測試系統算出天方夜譚般的交換比例時可能不對勁？

這種跨數學、密碼學、經濟學的邊界驗證，正是現代 DeFi 安全的最大盲區。審計公司會說「這是經濟模型設計缺陷，不是代碼邏輯問題」；項目方則抱怨「審計沒發現問題」；而用戶只知道自己的錢沒了！

你看，這歸根結底暴露的是 DeFi 行業的系統性安全短板：純技術背景的團隊嚴重缺乏基本的「金融風險嗅覺」。

而從 Cetus 這份報告來看，團隊顯然並沒有反思到位。

比起單純針對此次黑客攻擊上的技術性缺陷不足，我覺得從 Cetus 開始，所有的 DeFi 團隊都應該改掉純技術思維的局限性，真正培養起「金融工程師」的安全風險意識。

比如：引入金融風控專家，補足技術團隊的知識盲區；進行多方審計審查機制，不僅看代碼審計，必要的經濟模型審計也得補上；培養「金融嗅覺」，模擬各種攻擊場景和相應應對措施，對異常的操作時刻保持敏感等等。

這讓我想起之前安全公司的從業經驗，包括行業安全大佬們 @evilcos、@chiachih_wu、@yajinzhou、@mikelee205 們交流也有這樣的共識：

隨着行業的日趨成熟，代碼層面的技術 Bug 問題會日趨減少，而邊界不清、職責模糊的業務邏輯「意識 Bug」才是最大的挑戰。

審計公司只能確保代碼無 Bug，但如何才能做到「邏輯有邊界」需要項目團隊對業務本質有更深度理解和邊界把控能力。（之前很多安全審計後依然遭黑客攻擊的「甩鍋事件」根本原因都在於此）

DeFi 的未來，屬於那些代碼技術過硬，同時業務邏輯理解又深刻的團隊！