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

對於加密機構和服務提供商——包括加密貨幣交易所、支付公司、數位資產託管機構,以及託管與非託管錢包提供商——區塊鏈滲透測試對於納入範圍的機構而言,並非可有可無的預防措施。當入侵可能觸及簽名或資金,或適用規則要求進行對抗性驗證時,這就是保障體系中不可或缺的一環。這一論點建立在兩個支柱之上:超越合約程式碼的風險來源,以及監管機構對對抗性驗證的要求或期望。

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

本文開啟了我們的 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 約 9,000 萬美元為經鏈上驗證的最低估計值(約 1,405 枚 BTC);私下估算最高可達約 1.3 億美元。

將這些事件與滲透測試連結起來的原因,不僅在於它們發生在合約範圍之外,更在於它們能否被利用,往往取決於已部署的各個環節——身分、依賴項、簽名控制、核准與資金邏輯——是否串連成一條攻擊者能夠從入口點一路走到資金端的完整路徑。

1.2 程式碼層級稽核與交易層級監控:必要但有限

現有每一種知名的 web3 安全解決方案都在特定層級上發揮作用。程式碼層級稽核(程式碼稽核)檢視程式碼——合約、錢包或服務邏輯。交易層級監控(監控)檢視交易到達鏈上時的狀態;例如,Phalcon Security [11] 能在執行期間偵測、警示並封鎖惡意活動。

這些解決方案雖然有用,但在應對加密機構的資金處理鏈——即價值從入口點流向資金移動動作所經過的、彼此相連的身分、雲端基礎設施、簽名工作流程、核准鏈、錢包、供應商及操作員控制台——方面卻有其局限性。攻擊者可觸及的路徑,就是穿越這條鏈的一條路線:它可以從網頁、去中心化應用程式(dApp)、行動應用程式、API、雲端或身分入口點出發,經過簽名、核准與資金邏輯,並可能涉及合約在該實際情境下的行為表現,最終抵達另一端的資金移動動作。審查程式碼並不能拼湊出這條路徑,監看交易也無法預見它。即便兩者同時使用,仍可能留下組合上的缺口:稽核只能證明程式碼在撰寫時是健全的,並不能證明已部署的身分、核准與簽署者仍然貫徹該邏輯;而監控可能放行一筆在技術上有效、但實際上從未獲操作員本意授權的轉帳。彌補這一缺口的,是獨立的對抗性驗證,用以確認各項控制措施在實際運行系統中能否正確組合運作。

區塊鏈滲透測試對整套已部署、正在運行的系統進行實測,以在事件暴露問題之前,發現並證明此類路徑是否真能觸及資金。Bybit 事件的模式正好凸顯了這一問題的本質:一個遭入侵的簽名介面,將操作員自身的核准動作轉變為他們從未打算進行的轉帳——而這樣的結果,無論是合約本身、對其進行的稽核,還是交易監控,都可能將其判讀為合法操作。Web3 滲透測試正是直接針對這種組合問題:以遭入侵的供應商、操作員或介面的立場出發,測試這樣的立足點能否將一個看似有效的核准轉變為未經授權的資金轉移,以及哪些已部署的控制措施——身分、核准步驟、簽名檢查——真正能夠阻止這種情況發生。合約層級的程式碼保障仍屬於稽核的職責範圍;web3 滲透測試只有在合約的即時行為構成機構層級通往資金的路徑的一部分時,才會透過其實際運行行為與已部署的合約互動——這兩者是側重點不同、互補而非硬性劃分的範疇。第二部分 將定義 web3 滲透測試所驗證的內容,以及其範圍的邊界所在。

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

傳統滲透測試在雲端、網頁與 API、身分,以及特權存取等層面仍然具有價值。其局限在於範圍與領域背景:傳統測試工作可能無法涵蓋加密貨幣特有的業務語意,以及緊密結合的安全與合規模型。

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

區塊鏈滲透測試將既有的對抗性技術應用於傳統攻擊面,再加上整個運行系統中 web3 特有的簽名、核准、資金邏輯與合約動態層面。其差異化之處在於專業的 web3 安全判斷力,而非新的工具:測試人員以攻擊者的視角來解讀託管、交易意圖、資金流向與合規控制。兩者的差異在於目標不同:傳統測試通常著重證明 IT 控制層面的影響——例如管理員工作階段遭劫持、伺服器被攻陷——而 web3 測試則將價值的移動視為最終判準。它會進一步深入:在合法的簽名請求內部竄改收款人或金額,並檢視核准者所看到的內容、核准政策,以及實際移動的資金是否仍然相符一致。

總而言之,這是一種互補性的保障,而非靜態與動態測試之間的一道壁壘。程式碼層級稽核、交易層級監控與傳統滲透測試依然是必要的。Web3 滲透測試透過驗證可觸及的路徑將它們串聯起來;它並不能取代這些方法,也不能保證發現入侵事件,或保證能夠加以阻止。

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

各司法管轄區的要求各不相同,對特定實體與系統形成了涵蓋執照核發、持續性義務,以及監管機構觸發式義務的一系列規範光譜。

這些範例僅供說明之用,並非法律意見。機構應就其自身狀態、豁免情形、系統與義務向法律顧問確認。

• 美國紐約州:明確要求,附有限豁免。 根據紐約州金融服務署(NYDFS)23 NYCRR 第 500 條 [12] 規範的受管實體,包括獲 DFS 核發執照的虛擬貨幣業務,必須根據風險評估,至少每年一次從內部與外部對資訊系統進行測試。合格的內部或外部單位皆可執行測試。符合資格的小型實體可就此測試規定獲得有限豁免,但仍須遵守第 500 條其他適用條款。

• 杜拜:每年及變更觸發式要求。 持牌虛擬資產服務提供商(VASP)必須至少每年一次,並在導入新系統、應用程式或產品之前 [13],委託合格的獨立第三方進行漏洞評估與滲透測試。智能合約稽核則適用於與該 VASP 業務及活動相關的情況。威脅導向滲透測試並無統一的執行頻率:VARA 可根據風險判斷其必要性與相稱性後要求執行。

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

• 歐盟:比例原則框架;威脅導向滲透測試(TLPT)以識別結果為前提。 《數位營運韌性法案》(DORA)涵蓋金融實體,包括加密資產服務提供商 [15]。它要求對支援關鍵或重要功能的系統至少每年進行一次「適當測試」——而非特別指定滲透測試。滲透測試只是根據風險與比例原則所選擇的其中一種方法。威脅導向滲透測試僅適用於經主管機關認定的實體,須在實際生產系統上執行,一般要求至少每三年一次;主管機關可依風險考量調整此頻率。DORA 同時對測試人員的獨立性設有條件規範。微型企業不受此測試計畫規定約束。

• 新加坡:不具約束力的監管期望。 新加坡金融管理局(MAS)《科技風險管理指引》指出,金融機構應進行滲透測試,並期望可透過網際網路存取的系統至少每年一次,或在重大變更或更新後接受測試 [16]。這屬於不具約束力的監管指引,並未要求由獨立第三方執行。具約束力、僅適用於銀行的《網路衛生通知》並未明確規定滲透測試。具約束力的支付或數位支付代幣通知則不在本文討論範圍之內。

綜合來看,這些監管制度所要求或期望的是滲透測試——而非某種標榜為「web3」的專屬類別。web3 專業版本的必要性,源自於納入範圍的系統本身:當這些系統涉及加密貨幣價值的授權、簽署、託管或記帳時,妥善測試它們就需要具備第一部分所述的相同簽名與資金流動熟練度。

結論十分明確:在特定司法管轄區內,相當數量已獲執照的實體已面臨相關要求或監管期望——但這並非在每個市場都適用同一套強制規定。這些差異決定了範圍、頻率、測試人員獨立性、補救措施、佐證文件,以及測試究竟是用於支持執照核發、持續合規,還是監管機構觸發的專項作業。

結論:兩個支柱的匯聚

風險來源與監管要求或期望共同指向同一個結論:對於納入範圍的機構而言,web3 滲透測試是保障體系中不可或缺的一環。它驗證了跨越存取、核准、簽名與資金各環節的可觸及路徑,同時補強既有的控制措施。它無法保證能夠阻止入侵,無法證明它本可阻止任何一起具體的過往事件,也無法找出所有可被利用的路徑。其目標是在上線、運營、偵測、應變與監管佐證等各階段提供持續性的保障——而非一次性的報告。

繼續閱讀本系列文章:

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

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

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

本系列文章,即將發布:

• 第五部分:授權與簽名安全:網頁、去中心化應用程式與行動裝置
• 第六部分:雲端與 CI/CD 安全:自動化運營攻擊面
• 第七部分:資金管理控制平面安全:簽名與提款核准
• 第八部分:交易所帳本安全:盜竊路徑與資料平面邏輯

BlockSec 協助機構精準定位這一保障層級:繪製資產、資金流向、信任邊界與現有保障措施的全貌;確認法律顧問所指出的適用義務;接著界定測試目標、範圍、存取權限、生產環境防護措施、補救佐證,以及重測計畫。若要找出您的保障缺口,[請與我們的區塊鏈滲透測試團隊聯繫](https://blocksec.com/blockchain-penetration-testing) ;測試範圍與報價可依需求提供。從資金流動之處開始著手。

參考資料

依首次出現順序編號。

1. BlockSec, Crypto Payment Security Playbook. https://blocksec.com/crypto-payment-playbook

2. 美國聯邦調查局(FBI)、DC3 及日本警察廳, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (2024年12月). https://www.fbi.gov/news/press-releases/fbi-dc3-and-npa-identification-of-north-korean-cyber-actors-tracked-as-tradertraitor-responsible-for-theft-of-308-million-from-bitcoindmmcom

3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack. https://blocksec.com/blog/bybit-1-5-b-hack-in-depth-analysis-of-the-malicious-safe-wallet-upgrade-attack

4. rekt.news, BtcTurk — Rekt. https://rekt.news/btcturk-rekt

5. rekt.news, Leaderboard. https://rekt.news/leaderboard

6. SwissBorg, SwissBorg Security Update: Kiln Breach. https://swissborg.com/blog/swissborg-security-update-kiln-breach

7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor. https://blocksec.com/blog/trust-wallet-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. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39

9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability

10. BlockSec, Coldcard Entropy Failure and Seed Recovery (私鑰外洩事件). https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery

11. BlockSec, Phalcon Security (交易監控與封鎖). https://blocksec.com/phalcon/security

12. 紐約州金融服務署, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity

13. 杜拜虛擬資產監管局, Technology and Information Rulebook, Part I, Section E. https://rulebooks.vara.ae/rulebook/e-testing-and-audit

14. 香港證券及期貨事務監察委員會, Circular 24EC65, 18 December 2024. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65

15. 歐盟, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Articles 24-27. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng

16. 新加坡金融管理局, Technology Risk Management Guidelines (2021年1月), Sections 2 and 13, https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines; _Notice FSM-N06, Notice on Cyber Hygiene_ (2024), https://www.mas.gov.sg/regulation/notices/notice-fsm-n06