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

對於加密機構及服務提供商——包括加密貨幣交易所、支付公司、數位資產託管機構，以及託管與非託管錢包提供商——區塊鏈滲透測試對於在範圍內的機構而言，並非可有可無的預防措施。當入侵可能觸及簽署或資金，或適用規則要求對抗性驗證時，這便是不可或缺的保障層。此論點立基於兩大支柱：超越合約程式碼的風險來源，以及對抗性驗證的監管要求或期望。

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

本文開啟我們的區塊鏈滲透測試系列文章。在整個系列中，blockchain penetration testing 與 blockchain penetration testing 指的是同一門學科：我們以前者作為主要用詞，後者則作為業界常見的同義詞。本文提出關於必要性的高層次、全面性論述；後續文章將詳細定義此學科、其運作邊界，以及機構層面的攻擊面。

第一部分：風險來自何處

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 安全解決方案，各自運作於特定層級。程式碼層級稽核（Code-level audit）檢視程式碼（code audit）檢視程式碼——合約、錢包或服務邏輯。交易層級監控（monitoring）則在交易上鏈時進行檢視；例如，Phalcon Security [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]。這屬於不具約束力的監理指引，並不要求須由獨立第三方執行。具約束力、僅適用於銀行的《網路衛生通知》（Cyber Hygiene Notice）並未明確規定滲透測試。而具約束力的支付或數位支付代幣相關通知則不在本文討論範圍之內。

綜觀而言，這些法規制度要求或期望進行滲透測試——而非某種標榜為「web3」的特定類別。web3 專業版本的必要性，源自於受規範系統本身的性質：只要這些系統涉及加密資產的授權、簽署、託管或記帳，妥善測試它們便需要第一部分所述的簽署與資金流向專業知識。

結論相當明確：在特定司法管轄區內，相當數量的持牌實體已經面臨某種要求或監理期望——但這並非在每個市場中都是相同的強制規定。這些差異決定了測試的範圍、頻率、測試人員的獨立性、補救措施、證據要求，以及測試是用於支援發照、持續合規，抑或是監管機構觸發的專項行動。

結論：兩大支柱的匯合

風險來源與監管要求或期望共同指向同一個結論：對於範圍內的機構而言，區塊鏈滲透測試是不可或缺的保障層。它驗證了橫跨存取、核准、簽署及資金各環節中可觸及的路徑，同時與既有的控管措施相輔相成。它無法保證能夠防範一切，也無法證明它必然能阻止任何特定的過往事件，更無法保證能找出所有可被利用的路徑。其目標在於於發布、營運、偵測、應變及監管佐證等各個階段提供持續性的保障——而非一次性的報告。

繼續閱讀本系列文章：

• 第二部分：什麼是區塊鏈滲透測試？定義與範圍界限

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

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

本系列後續文章，即將發布：

• 第五部分：授權與簽署安全：Web、dApps 及
• 第六部分：雲端與 CI/CD 安全：自動化運作攻擊面
• 第七部分：財庫控制平面安全：簽署與提款核准
• 第八部分：交易所帳本安全：資產竊取路徑與資料平面邏輯

BlockSec 協助機構精準部署這一保障層：盤點資產、資金流向、信任邊界及既有保障措施；確認法律顧問所述適用之義務；接著界定測試目標、範圍、存取權限、生產環境防護措施、補救證據及重新測試計畫。若要找出您機構的保障缺口，請聯繫我們的區塊鏈滲透測試團隊；委託範圍與報價可依需求提供。從資金流動之處開始著手。

參考資料

依首次出現順序編號。

參考資料

依首次出現順序編號。

1. BlockSec, 加密支付安全指南 (Crypto Payment Security Playbook).
2. 美國聯邦調查局（FBI）、DC3 及日本國家警察廳, 識別對 Bitcoin.DMM.com 3.08 億美元竊案負責的北韓網路行為者（TraderTraitor） (2024 年 12 月).
3. BlockSec, Bybit 15 億美元駭客事件：惡意 Safe{Wallet} 升級攻擊深度解析.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, 排行榜.
6. SwissBorg, SwissBorg 安全更新：Kiln 資安漏洞事件.
7. BlockSec, TrustWallet 事件：遭竊的 API 金鑰將官方更新管道變成後門.
8. Slope, Slope Wallet Sentry 漏洞：數位鑑識與事件應變報告.
9. BlockSec, 我們對 Profanity 工具漏洞的簡短分析.
10. BlockSec, Coldcard 熵值失效與種子金鑰救援.
11. BlockSec, Phalcon Security.
12. 紐約州金融服務署 (New York State Department of Financial Services), 23 NYCRR Part 500 — 金融服務公司網路安全要求.
13. 杜拜虛擬資產監管局 (Dubai Virtual Assets Regulatory Authority), 科技與資訊規則手冊 (Technology and Information Rulebook), Part I, Section E.
14. 香港證券及期貨事務監察委員會, 通函 24EC65 (2024 年 12 月 18 日, PDF).
15. 歐盟, (EU) 2022/2554 號規則 — 數位營運韌性法案 (DORA), 第 24–27 條.
16. 新加坡金融管理局 (Monetary Authority of Singapore), 技術風險管理指引 (Technology Risk Management Guidelines) (2021 年 1 月), 第 2 及 13 節; Notice FSM-N06: 網路衛生通知 (2024 年).