從事件到監管：加密機構為何需要區塊鏈滲透測試

對於加密貨幣機構和服務提供商——包括加密貨幣交易所、支付公司、數字資產託管機構,以及託管和非託管錢包提供商——區塊鏈滲透測試對於在範圍內的機構而言,並非可選的預防措施。當漏洞可能波及簽名或資金,或適用規則要求進行對抗性驗證時,這是一道必要的保障層。這一論點基於兩個支柱:超越合約代碼的風險來源,以及對對抗性驗證的監管要求或期望。

機構面臨的風險不僅限於合約漏洞,還延伸至簽名、託管、金鑰、人員、供應鏈和基礎設施 [1]。因此,這一攻擊面並未被人們熟悉的 web3 安全解決方案——代碼層審計和交易層監控——或傳統滲透測試單獨完全覆蓋。這適用於任何機構,只要有人員、供應商、介面或應用程式能夠影響簽署、批准、入帳或轉移的內容——包括託管外包的情況。同時,多個市場的監管機構施加了不同範圍、頻率和獨立性規則的要求、附帶義務或監管期望。

本文開啟我們的區塊鏈滲透測試系列。在整個系列中,區塊鏈滲透測試和 web3 滲透測試指的是同一學科:我們使用前者作為主要術語,後者作為其常見的行業同義詞。本文提出了關於必要性的宏觀、全局性論證;後續文章將詳細定義該學科、其操作邊界以及機構攻擊面。

第一部分:風險來自何處

1.1 智能合約之外的風險

智能合約漏洞仍然重要,但近期許多最大規模的損失源於其他地方,尤其是金鑰、簽名系統和運營基礎設施。2024年,攻擊者通過入侵錢包軟體供應商並操縱一項合法交易請求,從 DMM Bitcoin 竊取了約3.05億美元 [2]。2025年,Bybit 因供應鏈入侵操縱其簽名介面而損失約15億美元 [3],而 BtcTurk 的熱錢包損失同樣源於私鑰洩露 [4]。我們的研究指向同一方向:在我們追踪的2026年損失超過10萬美元的事件中,鏈下失誤約佔八分之一的事件數,但佔總損失的四分之三以上。截至2026年8月,rekt.news公開排行榜上排名前十的最大黑客事件中(不包括詐騙和其他非黑客事件),有七件屬於鏈下入侵,無論按事件數量還是按美元價值計算,均佔約70% [5]。

錢包和託管系統將這一模式具體化,而錢包安全在近年來一直是事件高發領域。我們的調查將失誤分為金鑰管理、交易簽名流程、供應鏈與依賴項、敏感數據暴露以及密碼學實現。

* Coldcard 的約9000萬美元是經驗證的鏈上下限(約1,405 BTC);私人估計高達約1.3億美元。

將這些事件與滲透測試聯繫起來的原因,不僅僅是因為它們發生在合約之外,而是它們能否被利用,往往取決於已部署的各個部分——身份、依賴項、簽名控制、審批和資金邏輯——是否組合成一條攻擊者能夠端到端走通的路徑——從入口點通往資金。

1.2 代碼層審計與交易層監控:必要但有限

現有的知名 web3 安全解決方案各自在特定層級發揮作用。代碼層審計(代碼審計)檢視代碼——合約、錢包或服務邏輯。交易層監控(監控)在交易到達鏈上時進行檢視;例如 Phalcon [11] 在運行時檢測、警示並攔截惡意活動。

這些解決方案雖然有用,但在面對加密貨幣機構的資金處理鏈時仍有局限——這條鏈由相互關聯的身份、雲端基礎設施、簽名工作流程、審批鏈、錢包、供應商和操作員控制台組成,價值通過它們從入口點流向資金轉移動作。攻擊者可觸及的路徑,是穿越這整條鏈的一條路線:它可以從網頁、dApp、移動端、API、雲端或身份入口點,經過簽名、審批和資金邏輯,並可能經過合約在該實時環境中的行為方式,最終到達另一端的資金轉移動作。審查代碼並不能拼合出這條路徑,監視交易也無法預見到它。即使兩者結合使用,仍可能留下一個組合缺口:審計顯示代碼按書面設計是穩健的,但不代表已部署的身份、審批和簽署者仍在執行該設計;而監控可能放行一筆技術上有效,但從未符合操作員真實意圖的轉帳。彌合這一缺口的,是對系統在實際運行中控制措施是否正確組合所進行的獨立對抗性驗證。

區塊鏈滲透測試對已組裝、運行中的系統進行實測,以在事件暴露之前發現並證明此類路徑是否可能通往資金。Bybit 的模式揭示了問題的形態:一個被入侵的簽名介面,將操作員自己的批准變成了他們從未打算進行的轉帳——這一結果,無論合約本身、對其的審計,還是交易監控,都可能將其判讀為合法。區塊鏈滲透測試直接針對這種組合問題:站在被入侵的供應商、操作員或介面的立場,測試這樣的立足點是否能將一個看似有效的批准,轉變為未經授權的資金轉移,以及哪些已部署的控制措施——身份、審批步驟、簽名檢查——真正能夠阻止它。合約代碼層面的保障仍是審計的職責;區塊鏈滲透測試僅通過已部署合約的實時行為與其接觸,前提是該行為構成機構層級通往資金路徑的一部分——這是以側重點區分的互補範圍,而非硬性界限。第二部分定義了區塊鏈滲透測試驗證的內容及其範圍終止之處。

1.3 傳統滲透測試:有用但不夠

傳統滲透測試在雲端、網頁與 API、身份及特權訪問等層面仍具價值。它的局限在於範圍和領域背景:一次常規測試可能無法涵蓋加密貨幣的業務語義或耦合的安全與合規模型。

在加密貨幣領域,一個簽名可以授權不可逆的價值轉移;提款批准是資金控制決策,而不僅僅是表單提交。存款入帳、餘額記帳和內部轉帳都是資金邏輯。地址和交易也可能帶有制裁或資金來源方面的含義。測試人員可能發現了身份驗證繞過漏洞,卻未能察覺它如何與簽名顯示不一致、審批策略薄弱或舍入缺陷結合,形成一條通往資金的路徑。

區塊鏈滲透測試將成熟的對抗性技術應用於傳統攻擊面,以及整個運行系統中特有的 web3 簽名、審批、資金邏輯和合約動態攻擊面。它的差異化之處在於專業的 web3 安全判斷力,而非新工具:測試人員以攻擊者的方式解讀託管、交易意圖、資金流向和合規控制措施。兩者的差異在於目標本身:常規測試通常證明的是 IT 控制層面的影響——被接管的管理員會話、被觸及的伺服器——而區塊鏈測試則將價值的轉移視為最終判定條件。它會繼續深入:在一個合法的簽名請求中修改收款人或金額,並檢查批准者看到的內容、審批策略以及實際轉移的資金三者是否仍然一致。

總而言之,這是一種互補性保障,而非靜態測試與動態測試之間的壁壘。代碼層審計、交易層監控和傳統滲透測試仍然必要。區塊鏈滲透測試通過驗證可觸及的路徑將它們聯繫起來;它並不取代它們,也不保證發現漏洞或保證防範漏洞。

第二部分:監管機構的要求

要求因司法管轄區而異,對特定實體和系統形成了從許可、持續性到監管觸發性義務的一系列光譜。

這些例子僅供說明,並非法律意見。機構應與法律顧問確認其地位、豁免情況、系統及義務。

• 美國紐約州:明確要求,附有限豁免。 根據 NYDFS 23 NYCRR Part 500 [12] 受監管的實體,包括獲得 DFS 許可的虛擬貨幣業務,必須根據風險評估,至少每年一次從系統內部和外部測試信息系統。可由合格的內部或外部方進行測試。符合條件的小型實體可獲得此測試條款的有限豁免,但仍須遵守 Part 500 的其他適用條款。

• 杜拜:年度及變更觸發的要求。 獲許可的 VASP 必須至少每年一次,以及在引入新系統、應用程式或產品之前,使用合格的獨立第三方進行漏洞評估和滲透測試 [13]。智能合約審計適用於與 VASP 業務和活動相關的情況。威脅導向滲透測試沒有統一的頻率:VARA 可根據風險判斷,在必要且合乎比例的情況下要求進行此類測試。

• 香港:視為持牌申請人的牌照條件要求。 被視為持牌的虛擬資產交易平台申請人,必須在受限運營之前完成滲透測試和漏洞評估,並取得令人滿意的結果 [14]。新公司申請人適用另外的指引。獨立第三方必須覆蓋應用層和網路層的指定基礎設施和應用程式。在受限運營之前,管理層必須完成所有針對中高風險發現的重大及關鍵整改步驟。

• 歐盟:比例性框架;威脅導向滲透測試以識別為條件。 DORA 涵蓋金融實體,包括加密資產服務提供商 [15]。它要求對支持關鍵或重要功能的系統,至少每年進行一次適當的測試——並非特指滲透測試。滲透測試是根據風險和比例原則選擇的一種方法。威脅導向滲透測試僅適用於被主管機構認定的實體,在實際生產系統上進行,通常至少每三年要求一次;主管機構可根據風險理由調整該頻率。DORA 還規定了測試人員的獨立性條件。微型企業不在測試計劃要求的範圍之內。

• 新加坡:非強制性的監管期望。 MAS《技術風險管理指引》規定,金融機構應進行滲透測試,並期望可通過互聯網訪問的系統至少每年一次,或在重大變更或更新後接受測試 [16]。這是非強制性的監管指引,不要求獨立第三方進行測試。強制性、僅適用於銀行的《網絡安全衛生通知》並未明確規定滲透測試。強制性的支付或數字支付代幣通知不在本文討論範圍之內。

綜合來看,這些監管制度要求或期望進行滲透測試——而非某種帶品牌標籤的「web3」類別。web3 專業版本的必要性源於受測系統本身:當這些系統負責授權、簽署、託管或核算加密貨幣價值時,對其進行妥善測試,需要具備第一部分所述相同的簽名與資金流熟悉度。

結論是精確的:在特定司法管轄區內,大量持牌實體已經面臨某種要求或監管期望——但並非在每個市場中都是相同的強制規定。這些差異決定了範圍、頻率、測試人員獨立性、整改、證據,以及測試是支持許可、持續合規,還是監管觸發性的演練。

結論:兩大支柱的交匯

風險來源與監管要求或期望指向同一個結論:對於範圍內的機構而言,區塊鏈滲透測試是一道必要的保障層。它驗證了跨越訪問、審批、簽名和資金的可觸及路徑,同時對現有控制措施進行補充。它無法保證防範風險、無法證明它能阻止任何特定的過往事件,也無法找出每一條可利用的路徑。其目標是在上線、運營、檢測、應對和監管證據方面提供持續的保障——而不是一份一次性的報告。

繼續閱讀本系列:

• 第二部分:什麼是區塊鏈滲透測試?定義與邊界

• 第三部分:機構級區塊鏈滲透測試的交戰規則與生產環境安全

• 第四部分:Web3 攻擊面:滲透測試概覽

本系列即將發布的內容:

• 第五部分:授權與簽名安全:網頁、dApp 與行動端
• 第六部分:雲端與 CI/CD 安全:自動化運營攻擊面
• 第七部分:資金管理控制平面安全:簽名與提款批准
• 第八部分:交易所帳本安全:盜竊路徑與數據平面邏輯

BlockSec 協助機構精準定位這一保障層:繪製資產、資金流向、信任邊界及現有保障措施的地圖;確認法律顧問所指出適用的義務;然後界定測試目標、範圍、訪問權限、生產環境保障措施、整改證據及重新測試計劃。要識別您的保障缺口,請聯繫我們的區塊鏈滲透測試團隊;測試範圍與報價可依要求提供。從資金流動的地方開始。

參考文獻

依首次出現順序編號。

1. BlockSec, Crypto Payment Security Playbook.
2. U.S. Federal Bureau of Investigation, DC3, and Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (December 2024).
3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Leaderboard.
6. SwissBorg, SwissBorg Security Update: Kiln Breach.
7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
8. Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
10. BlockSec, Coldcard Entropy Failure and Seed Recovery.
11. BlockSec, Phalcon Security.
12. New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E.
14. Hong Kong Securities and Futures Commission, Circular 24EC65 (18 December 2024, PDF).
15. European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
16. Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).