什麼是區塊鏈滲透測試？定義與界限

上一篇文章《從事件到監管：加密機構為何需要區塊鏈滲透測試》闡述了區塊鏈滲透測試為何必要。本文則轉向探討「它是什麼」，更詳細地審視區塊鏈滲透測試的定義與邊界。

目前尚不存在廣為接受的區塊鏈滲透測試正式定義，而許多提出的定義將其與其他緩解措施混為一談，因此像審計、掃描和漏洞賞金這類標籤有時被納入滲透測試的一部分，儘管每一項服務的目標各不相同。這使得人們更難確知某次評估實際驗證了什麼。我們的出發點取自學界與業界的實務經驗，刻意保持簡單：區塊鏈滲透測試，正如其名所示，就是滲透測試——這是一門已經定義數十年的學科——應用於 web3 生態系統，以對抗性、全系統評估的方式，針對運行中的 web3 環境進行。從這門熟悉的學科出發，接著探討 web3 為威脅模型以及測試人員所需的判斷力增添了什麼。

**區塊鏈滲透測試是對運行中系統的對抗性、實作評估，在雙方約定的環境與交戰規則下進行，以驗證可利用的路徑與控制鏈。**它是對程式碼層級安全審計的補充，也可以獨立委託進行 [1]。

它尋求的是路徑，而非孤立的弱點，並在明確的授權、範圍、存取假設與安全限制下運作。本文將回答三個問題：區塊鏈滲透測試是什麼、它能驗證什麼——尤其是超出審計通常提供的證據之外的部分——以及機構如何從高層次著手開始。

web3 增添了什麼：資金處理威脅模型

Web3 保留了傳統滲透測試的攻擊面：雲端基礎設施、網站、API、身份、特權存取、供應商以及運維工具。它並未以純區塊鏈的威脅模型取代這一套，而是將其延伸到那些相同立足點可能直接導向授權、記帳或轉移價值行動的系統之中。

Figure 1. The money-handling chain and its off-chain-to-on-chain handoff.

這種延伸由三項特性所塑造。

首先，數位資產可直接轉移。攻擊者若能到達正確的交易或提款路徑,便可能在不經過傳統支付所使用的相同撤銷與對帳機制的情況下轉移價值。
其次，簽署往往就是移動資金的行為。一個在密碼學上有效的簽名可以證明某把私鑰已授權某個負載（payload），但單憑此點並不能證明操作人員看到了正確的目的地、理解了該筆交易，或遵循了預定的核准政策。
第三，當機構部署自己的合約時——隨著產品加入更豐富的鏈上功能，這種情況越來越普遍——這些合約是公開可呼叫且可組合的。外部使用者及其他合約可以按機構無法控制的順序呼叫它們。因此，安全性不僅取決於每個組件本身，還取決於身份、應用程式、政策、簽署系統、記帳邏輯與合約之間如何互動。

我們將由此產生的暴露面建模為資金處理鏈——即通向鏈上交易（且愈來愈常涉及機構自行部署的合約）的鏈下簽署意圖、核准與資金邏輯控制——連同支撐這些步驟的雲端、網頁、API 與身份層 [1]。攻擊者可能從一個普通的立足點開始，逐步跨越多重控制：操縱呈現給簽署的內容、抵達某個特權工作流程、利用授權缺口，或使資金邏輯接受非預期的狀態轉換。

其中關鍵的組合缺口在於鏈下與鏈上之間的交接：即身份、介面、核准、簽署與資金邏輯控制，能否在某項行動轉化為鏈上交易時，仍保留其原本的意圖。並非每次攻擊都會貫穿整條鏈。重點在於，保證的目標是跨層的：單獨看來穩固的控制措施，仍可能組合成一條可穿透運行中資金處理系統的可利用路徑。

區塊鏈滲透測試做什麼

區塊鏈滲透測試將這種組合缺口轉化為證據。在授權範圍與約定規則之內，測試人員將跨層假設轉化為攻擊情境，針對運行中的環境演練這些情境，並判斷它們是否會產生可重現的路徑與具體影響。輸出結果將該路徑與支持證據、嚴重程度、修復建議以及對已商定修復措施的重新測試連結起來——而不僅止於一份互不相關的弱點清單。

Figure 2. From authorized scenario to reproducible path and evidence.

其差異化之處在於專業的 web3 安全判斷力，而非某種獨特的工具箱。測試人員必須解讀託管、交易意圖、核准政策、提款流程、資金記帳以及鏈上交易行為（包括已部署的合約），同時將來自傳統雲端、網頁、API、身份與特權存取層面的證據連結起來。工具可以協助發現或驗證，但要判斷所觀察到的情況是否構成一條可信的資金移動路徑，則需靠專家的判斷。

該評估是有條理、以證據為主導，且屬於特定時間點的。其結論僅適用於所測試的系統、版本、配置、存取假設與條件。潛在路徑會被審視；已確認的可利用路徑則會以可重現的證據記錄下來。

請注意，即使在約定的範圍內進行系統性的作業，也無法保證能發現每一個弱點或攻擊路徑，而一次負責任的評估也不保證測試人員能夠成功實現入侵。

在機構級的 web3 環境中，這種從情境到證據的過程貫穿五項相互連結的能力——同一資金處理鏈上可測試的各個層面。它們涵蓋支撐該鏈的基礎設施、其三項鏈下控制，以及其最終交接的鏈上交易；之所以相互連結，是因為單一路徑可能橫跨其中多項：

**正式運行環境與自動化運維：**測試人員驗證存取、部署、密鑰或運維控制是否可被串連為一項資金處理行動，從而產生將運維立足點與其可觸及影響連結起來的證據。
**網頁與 dApp 前端、授權與簽署意圖：**測試人員驗證呈現給使用者或操作人員的交易是否可能偏離最終獲授權的行動，並記錄被操縱的流程及其最終被簽署或提交的行為。
**簽署、核准與提款授權鏈：**測試人員驗證身份、角色、政策檢查或核准步驟是否可被繞過或組合利用，並記錄該序列及其所促成的未經授權行動。
**資金業務邏輯：**測試人員驗證餘額、限額、對帳、提款規則或狀態轉換是否會接受非預期的條件，捕捉可重現的業務影響路徑，而不僅是技術缺陷。
**鏈上交易與已部署合約：**測試人員驗證機構的鏈上互動在對抗性運行條件下的行為；對於機構自行部署的合約，測試人員會演練這些合約的運行時行為，並保留觀察結果在交易層級上的證據。程式碼層級的保證仍屬於對應的 Code Audit 的職責範圍。

第四篇：Web3 攻擊面：滲透測試概覽對這些攻擊面及其連結進行了梳理，但核心目標不變：確定約定的運行環境中的各項條件是否會串連成可重現的影響。

它與其他保證措施的關係

最清晰的比較方式是依保證目標：也就是該項工作旨在支持的決策，以及預期產生的證據。如下圖所示，方法可以重疊，各學科可以協作，任何有意義的界線都不應建立在「某團隊純屬靜態、另一團隊純屬動態」這種假設之上。同一個目標——一份已部署的合約、一個雲端或 RPC 攻擊面、一套簽署系統——可能同時屬於不止一門學科；不同的是每門學科所側重的保證目標，而非對該系統的獨佔性主張。

Figure 3. Blockchain Penetration Testing, Code Audit, and Blockchain Security Testing on two axes.

滲透測試與程式碼層級審計

Code Audit——即程式碼層級審計的正式名稱——主要在程式碼（也包括設計、架構與協議假設）方面建立保證。它結合了專家審查與檢測工具，可能包含動態技術，並針對約定的審計範圍出具一份簽署的報告。對於合約、鏈、橋接、rollup、錢包或其他實作，審計要問的是：其設計與程式碼是否滿足預期的安全屬性。

滲透測試主要確立的是：跨越約定、運行中的機構環境的真實條件，是否能夠被串連成可重現的影響。它跟蹤已部署應用程式、身份、配置、工作流程、業務邏輯、簽署系統與合約呼叫之間的互動，然後記錄重現與修復該路徑所需的證據。

這是目標與證據上的差異，而非能力上的禁區。審計人員可能會執行測試、對組件進行模糊測試（fuzz），並調查運行時行為；滲透測試人員也可能審查配置、應用程式邏輯與實作細節，以理解某條路徑。方法可以重疊，團隊也可以合作。這兩項服務是互補而非替代關係：單靠審計通常無法提供這種涵蓋整個機構的運行時可利用性證據，而滲透測試也無法取代審計所涵蓋的、關於實作與協議屬性的程式碼層級保證。

因此，某份合約在實際機構路徑中的對抗性行為可能屬於滲透測試的範疇，而關於該合約程式碼本身的保證，則歸屬於對應的 Code Audit。

掃描、漏洞賞金與專項測試

漏洞掃描針對已知特徵、暴露的服務、缺失的修補程式以及常見的配置問題，提供自動化的廣泛覆蓋。它有助於實現可重複的可見性，並能對偵察工作有所貢獻，而滲透測試則增添由專家主導的深度分析，並判斷各項條件能否串連成一條有意義的路徑。

漏洞賞金邀請獨立研究人員依照公開規則回報符合資格的發現。其持續性、群眾外包的模式能夠揭露長尾問題，而一次滲透測試委託則指派一個團隊，有條理地檢視約定的環境，並提交彙整後的證據、嚴重程度、修復建議與重新測試結果。這兩種模式互為補充，且都無法保證發現全部問題。

舉例而言，BlockSec 的 Blockchain Security Testing 是一項並行項目，而非滲透測試的上位或子集。它使用專門的引擎——包括差異測試、模糊測試、私有部署、大規模 RPC 阻斷服務測試，以及節點或叢集基礎設施測試——來驗證客製化基礎設施的實作正確性與韌性 [2]。區塊鏈滲透測試則聚焦於機構層級、貫穿運行中資金處理系統的跨層路徑。應用程式託管與應用程式 CI/CD 歸屬於滲透測試的範疇；節點與叢集基礎設施以及大規模 RPC 韌性則歸屬於 Blockchain Security Testing。某個架構可能兩者皆需要。

相近的保證目標同樣需要精確歸類。合約程式碼層級的保證歸屬於對應的 Code Audit。密鑰託管實作（包括 MPC、TSS 與 TEE 設計）的密碼學正確性歸屬於 Wallet Security Audit。支付端的代理系統（agentic systems）歸屬於 Agentic Payment Security [1]。當周邊的簽署工作流程、運維代理或應用程式路徑構成約定的機構範圍的一部分時，滲透測試仍可能對其進行檢視。

保證目標	對應方法
驗證可利用路徑是否貫穿運行中機構的應用程式、身份、核准控制、資金邏輯與鏈上交易（包括已部署的合約）	Blockchain Penetration Testing
評估程式碼、設計、架構或協議假設	Code Audit
評估 MPC、TSS、TEE 或密鑰託管實作中的密碼學正確性	Wallet Security Audit
驗證客製化節點、叢集、EVM、資料庫、MPT 或大規模 RPC 基礎設施的實作正確性與韌性	Blockchain Security Testing
維持對已知特徵與配置問題的廣泛、自動化可見性	Vulnerability Scanning
針對公開的合格範圍，邀請持續性、以獎勵驅動的研究	Bug Bounty
評估支付端的代理系統及其安全假設	Agentic Payment Security