SEAL Certifications 是由 Security Alliance (SEAL) 發布的開源營運安全認證計畫。其現行基準將 99 項具體營運要求（稱為控制措施）編排於六個模組，涵蓋加密貨幣協議相關的人員、帳戶、簽署者、網域、基礎設施、資金庫流程及應變能力 [1, 2]。
BlockSec 是該計畫首批獲認可的評估機構之一，目前也是唯一總部位於亞洲的獲認可評估機構。身為 SEAL 認可的評估機構，我們與客戶界定範圍、評估所選控制措施及證據、記錄缺口，並判定範圍內的要求是否已獲滿足。若已滿足，我們便以 SEAL 認可評估機構的身分，核發鏈上證明 [4]。
本文說明組織為何可能申請 SEAL 認證、取得認證代表什麼、哪些模組可能適用、我們如何進行評估，以及團隊如何為評估合作做好準備。
1. 為何申請 SEAL 認證
SEAL 制定此框架的理由是，加密貨幣領域遭受攻擊的主要成因，已從智能合約漏洞轉向營運失誤 [1]。因此，評估重點轉向簽署者、多重簽名、網域、憑證、基礎設施監控及事件應變相關的控制措施。SEAL 認證評估會檢視這些控制措施是否在實務中運作，以及能否提出證據佐證，讓加密貨幣組織獨立了解哪些控制措施符合基準、哪些仍有缺口 [1, 3]。
SEAL 認證回答一個關於保障程度的問題：約定範圍內的營運控制措施，是否已經過獨立評估，並被認定符合公開、專為加密貨幣領域制定的營運安全基準？ 協議、交易所、支付平台及託管機構等加密貨幣組織，在投資人、上架審查團隊、合規相關方、內部治理機構、保險公司或盡職調查審查人員要求提供營運控制措施的獨立證據時，可能需要這項保障。評估結果會列明受評估的模組與邊界，並記錄該範圍是否符合基準 [5, 6]。
與相近的安全活動比較，更能看清這項保障的範圍。評估可能檢視儲存庫、CI/CD 及基礎設施控制措施中與程式碼相關的營運證據，包括權限、分支保護設定、程式碼審查紀錄、安全掃描結果、管線控制措施及基礎設施設定 [7]。評估不會透過審查原始碼來尋找實作漏洞，或判定協議邏輯是否正確 [1]。下表比較 SEAL 認證、程式碼稽核及滲透測試。
| 比較項目 | SEAL 認證 | 程式碼稽核 | 滲透測試 |
|---|---|---|---|
| 主要評估對象 | 約定模組與邊界內的營運控制措施及佐證資料 | 約定稽核範圍內的原始碼與協議邏輯 | 約定環境與測試規則內的系統及攻擊面 |
| 核心問題 | 範圍內的營運控制措施是否符合 SEAL 的要求，且有充分證據佐證？ | 範圍內的程式碼是否存在實作漏洞或協議邏輯缺陷？ | 能否在約定環境中重現可利用的攻擊路徑？ |
| 評估方式 | 透過文件、營運紀錄、設定、訪談，以及適用時的測試證據，審查控制措施的實施情況 | 審查範圍內的原始碼及相關規格，尋找實作與邏輯缺陷 | 測試約定的攻擊面，並驗證已識別的弱點能否在測試規則內被利用 |
| 結果 | 範圍內要求獲得滿足時，核發認證及相應的鏈上證明；未獲滿足時，提出缺口發現事項 | 針對受稽核範圍提出安全發現事項及修復建議 | 針對受測範圍提出安全發現事項及修復建議 |
這些服務的評估目標各不相同。測試可以為部分 SEAL 控制措施提供證據，但稽核或滲透測試本身並不構成 SEAL 認證。
SEAL 認證是一項獨立的評估計畫。只有所選範圍符合 SEAL 的要求，才會核發認證 [6]。程式碼稽核與滲透測試是另外的活動，兩者都不是取得認證的先決條件。
同樣的區別也適用於範圍更廣的保障標準。根據 SEAL 的徵求意見文章，SOC 2 和 ISO 27001 仍有價值，對許多組織最終也會是必要的，但它們並非針對由小型分散式團隊控制大量鏈上價值等加密貨幣領域特有的營運模式而設計 [5]。SEAL 框架為加密貨幣營運控制措施提供更聚焦的起點，也可以與這些範圍更廣的標準並行。
2. 認證能證明什麼
SEAL 認證結果適用於該次合作所選定的營運控制措施、模組及邊界。當所選控制措施符合 SEAL 的要求時，BlockSec 等獲 SEAL 認可的評估公司，會以其認可資格透過 Ethereum Attestation Service 核發鏈上證明及適用的 SEAL 徽章 [4]。證明是公開的；詳細評估報告與證據則由評估公司和客戶保密 [1]。下表區分通過評估的結果所能支持的結論，以及仍在其範圍之外的主張。
| 通過 SEAL 認證評估可證明…… | 但無法證明…… |
|---|---|
| 受評估組織對約定範圍內的模組與邊界符合 SEAL 的要求 | 未列入的模組或營運系統也經過評估 |
| 範圍內的營運控制措施及佐證資料已經過獨立第三方審查 | 原始碼已經過實作缺陷審查、攻擊路徑已經過測試，或協議不存在漏洞 |
| 約定範圍內各項控制措施逐一符合要求 | 安全評分、成熟度等級、程式碼品質意見或監管核准 |
| 認證反映特定時間點的狀態、效期有限，且須重新評估 | 持續合規，或保證不會發生安全事件 |
認證核發後，這些限制仍然適用。SEAL 證明不表示協議不存在安全問題 [1]。認證效期有限，須定期重新評估，若持續不符合要求，可能遭到撤銷；SEAL 並未公布固定的有效期間 [1]。
3. 框架涵蓋哪些範圍
六個模組可單獨評估，也可一併評估。現行基準包含 99 項控制措施 [1, 2]。When it may apply 欄是根據模組定義編寫的參考指引，並非 SEAL 的正式範圍界定規則；我們會在合作期間與客戶確認最終範圍。
| 模組 | 涵蓋內容 | 可能適用的情況 |
|---|---|---|
| 多重簽名作業（24 項控制措施） | 簽署者設定、交易執行、協調、持續運作及緊急程序 | 多重簽名錢包、簽署者群組或協同交易核准 |
| 資金庫作業（23 項控制措施） | 託管架構、資產管理、交易治理、對帳、監控、供應商管理、保險及資金庫應變 | 資金庫資產、資產配置、託管關係或資金流動 |
| 事件應變（13 項控制措施） | 準備、升級處理、溝通、應變手冊、演練及協同應變 | 須偵測、控制、通報安全事件並從中復原的團隊 |
| DevOps 與基礎設施（15 項控制措施） | 儲存庫治理、程式碼審查與掃描控制措施、CI/CD、供應鏈管理、基礎設施存取、監控及韌性 | 程式碼儲存庫、部署管線、雲端基礎設施或正式環境管理 |
| DNS 與網域註冊商（16 項控制措施） | 網域所有權、註冊商存取、DNS 設定、監控、復原及接管事件應變 | 關鍵網域、註冊商帳戶、DNS 紀錄或電子郵件驗證 |
| 身分與帳戶（8 項控制措施） | 帳戶清冊、所有權、抗網路釣魚的身分驗證、憑證管理、復原、存取權限審查、生命週期管理、監控及第三方存取 | 橫跨儲存庫、雲端平台、註冊商、託管系統或內部工具的人員帳戶、服務帳戶或特權帳戶 |
如需進一步了解 DNS 與網域註冊商模組，請參閱智能合約之外：Web3 的網域與 DNS 營運安全。
即使單獨評估，各模組在營運上仍相互關聯。DevOps 與基礎設施及 DNS 與網域註冊商模組中的部分控制措施，仰賴身分與帳戶模組所定義的帳戶安全實務。事件應變要求也出現在數個模組中，例如安全事件期間協調多重簽名簽署者或復原帳戶 [2]。
這些跨模組參照會影響範圍內控制措施所需的證據，但不會使被參照的模組自動獲得認證、形成必須遵循的認證順序，或擴大合作範圍。DNS 與網域註冊商的證明，不會僅因某項 DNS 控制措施仰賴帳戶安全實務，就變成身分與帳戶的證明。證明僅適用於其範圍中列明的模組與邊界 [1, 6]。
4. 評估如何進行
SEAL 維護框架並運作認證計畫。身為 SEAL 認可的評估公司，我們依照五個步驟評估每位客戶 [1, 4]：
圖 1。SEAL 認證合作從約定範圍開始，經過證據審查、修復及重新評估後，才會核發證明。
-
界定範圍。 我們與客戶共同議定納入範圍的模組、控制措施、系統、作業及組織邊界。
-
蒐集證據。 客戶提供資料，說明範圍內的控制措施如何設計、分配責任、執行及審查。
-
評估。 我們依據 SEAL 公布的要求評估證據，並找出缺失或佐證不足之處。
-
修復與重新評估。 若約定範圍未符合基準，我們會提供缺口報告。客戶處理已識別的缺口，並提交更新後的證據供重新評估。
-
認證。 當約定範圍符合基準時，我們便以 SEAL 認可評估機構的身分核發正式的鏈上證明。
證據蒐集與評估相互配合：客戶提供佐證資料，BlockSec 則評估資料是否足以證明各項控制措施在實務中運作。SEAL 的認證指引將佐證資料分為五類；下表依據指引及模組基準中的例子加以概述 [2, 3, 7]：
| 證據類別 | 有助於證明的事項 |
|---|---|
| 程序文件 | 預定實施的控制措施，包括政策、版本及核准日期 |
| 營運佐證 | 透過日誌、紀錄、工單或團隊成員訪談，證明流程已在實務中使用 |
| 測試／驗證 | 防護措施或應變流程已經演練或檢查 |
| 權責資訊 | 由誰維護控制措施、審查頻率，以及上次更新時間 |
| 技術佐證資料 | 設定、截圖或系統匯出資料，包括儲存庫及 CI/CD 設定、雲端設定、註冊商或 DNS 匯出資料，以及其他範圍內的技術證據 |
根據這些證據，BlockSec 會將每項範圍內的控制措施記錄為「已實施」、「部分實施」、「未實施」，或附理由註明為「不適用」。正式認證要求約定範圍內的控制措施均為「已實施」，或有理由支持其為「不適用」，且各項主張均有證據佐證。因此，儘管底層評估仍逐項檢視控制措施，整個約定範圍的最終認證決定只有通過或不通過兩種結果 [3, 6]。
5. 如何準備
開始 SEAL 認證合作前，請準備以下四項：
-
**擬議範圍：**與預期認證主張相關的模組、系統、實體、團隊及邊界。
-
**逐項控制措施自評：**判斷各項要求看似屬於「已實施」、「部分實施」、「未實施」或「不適用」，並說明每項判斷的依據。
-
**證據清冊：**將現有程序、營運紀錄、測試結果、權責紀錄及技術佐證資料對應至擬議範圍。
-
**指定參與人員：**負責範圍決策、證據蒐集及修復協調的人員。
由於框架與檢查清單均公開，團隊可以在正式合作前著手準備。自評有助於找出未形成文件的流程、缺少的營運證據、未指定負責人的控制措施，以及已知的修復工作。但自評仍只是內部檢查點：它未經獨立驗證，也不會產生 SEAL 證明 [1, 3]。
這四項準備有助於初步界定範圍；詳細資料需求則取決於所選模組。上述模組名稱界定的是主題領域，而非必須遵循的認證順序。各模組專文發布後，將提供模組層級的控制措施指引。如欲討論模組選擇、證據準備情況及合作範圍，請透過 [email protected] 與我們聯絡。
參考資料
- Security Alliance，SEAL 認證框架：概覽。
- Security Alliance，匯出所有認證（XLSX），可從框架概覽取得。控制措施數量與跨模組參照也已於 2026 年 10 月對照六個已發布的模組頁面查核。
- Security Alliance，認證指引。
- Security Alliance，稽核機構認可；SEAL Certifications。
- Security Alliance Radar，徵求意見：SEAL Certifications。
- Isaac Patka，Security Alliance Radar，SEAL Certifications：正式開放申請（2026年6月2日）。
- Security Alliance，SFC：DevOps 與基礎設施。
