什麼是 SEAL 認證？加密貨幣的營運安全保障

SEAL Certifications 是由 Security Alliance (SEAL) 發布的開源營運安全認證計畫。其目前的 v0.0.1 基準將 99 項具體營運要求（稱為控制措施）分為六個模組，涵蓋加密貨幣協議相關的人員、帳戶、簽署者、網域、基礎設施、財務流程及應變能力 [1, 2]。

BlockSec 是該計畫首批獲認可的評估機構之一，也是目前唯一總部位於亞洲的獲認可評估機構。作為 SEAL 認可的評估機構，我們與客戶界定範圍、評估選定的控制措施及證據、記錄缺口，並判定範圍內的要求是否已獲滿足。若要求均已獲滿足，我們便以所獲得的 SEAL 認可資格核發鏈上證明 [4]。

本文說明組織為何可能尋求 SEAL 認證、認證結果代表什麼、哪些模組可能適用、我們如何進行評估，以及團隊如何為評估工作做好準備。

1. 為何尋求 SEAL 認證

SEAL 建立此框架的理由是，加密貨幣領域的主要漏洞利用來源已從智慧合約漏洞轉向營運失誤 [1]。因此，評估的關注點轉向簽署者、多重簽章、網域、憑證、基礎設施監控及事件應變相關的控制措施。SEAL 認證評估檢視這些控制措施是否在實務中運作，以及是否有證據佐證，讓加密貨幣組織能從獨立視角了解哪些控制措施符合基準、哪些仍存在缺口 [1, 3]。

SEAL 認證回答一個確信問題：約定範圍內的營運控制措施，是否已經過獨立評估，並確認符合一套公開、專為加密貨幣領域設計的營運安全基準？ 協議、交易所、支付平台及託管機構等加密貨幣組織，在投資人、上架審查團隊、合規利害關係人、內部治理機構、保險公司或盡職調查人員要求提供營運控制措施的獨立證據時，可能需要這類確信。認證結果會列明受評估的模組與邊界，並記錄該範圍是否符合基準 [5, 6]。

與其他相關安全活動比較，更能看清這類確信的範圍。評估可能檢視與程式碼相關的營運證據，以評估程式碼儲存庫、CI/CD 及基礎設施控制措施，包括權限、分支保護設定、程式碼審查紀錄、安全掃描結果、管線控制措施及基礎設施設定 [7]。評估不會審查原始碼以找出實作漏洞，也不會判定協議邏輯是否正確 [1]。其他安全活動則處理這些及相關目標：程式碼稽核評估原始碼中的實作漏洞與協議邏輯缺陷；滲透測試評估能否在約定環境中重現可利用的攻擊路徑；漏洞懸賞計畫提供持續接收外部發現的管道；持續監控則支援持續偵測與應變。

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]。何時可能適用 欄是根據模組定義編寫的參考指引，並非 SEAL 的正式範圍界定規則；我們會在評估工作期間與客戶確認最終範圍。

模組	涵蓋內容	何時可能適用
多重簽章營運（24 項控制措施）	簽署者設定、交易執行、協調、持續運作及緊急程序	多重簽章錢包、簽署者群組或需協調的交易核准
財務營運（23 項控制措施）	託管架構、資產管理、交易治理、對帳、監控、供應商管理、保險及財務應變	財務資產、資產配置、託管關係或資金流動
事件應變（13 項控制措施）	準備工作、通報升級、溝通、應變手冊、演練及協同應變	必須偵測、遏止、通報安全事件並從中復原的團隊
DevOps 與基礎設施（15 項控制措施）	程式碼儲存庫治理、程式碼審查及掃描控制措施、CI/CD、供應鏈管理、基礎設施存取、監控及韌性	程式碼儲存庫、部署管線、雲端基礎設施或正式環境管理
DNS 與註冊商（16 項控制措施）	網域所有權、註冊商存取、DNS 設定、監控、復原及網域接管應變	關鍵網域、註冊商帳戶、DNS 紀錄或電子郵件驗證
身分與帳戶（8 項控制措施）	帳戶盤點、所有權、抗網路釣魚驗證、憑證管理、復原、存取權限審查、生命週期管理、監控及第三方存取	涵蓋程式碼儲存庫、雲端平台、註冊商、託管系統或內部工具的人員、服務或特權帳戶

即使模組單獨接受評估，彼此在營運上仍有關聯。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]。

這四項準備工作有助於初步界定範圍；詳細的資料要求則取決於選定的模組。上述模組名稱界定的是主題領域，並非必須遵循的認證順序。各模組的控制措施指引將在專文發布時提供。若想討論模組選擇、證據準備情況及評估範圍，請聯絡我們 [需实证:CONTACT_OR_RELEVANT_PAGE_URL]。

參考資料

Security Alliance，SEAL 認證框架：概覽。框架緣由、模組、獨立界定範圍、評估流程、自評、證明與徽章、保密、重新評估及撤銷。https://frameworks.securityalliance.org/certs/overview/
Security Alliance，匯出所有認證資料（XLSX）。目前各模組的控制措施數量及跨模組參照，已對照 SEAL 認證框架概覽提供的官方匯出資料核實；存取於 2026 年 9 月。https://frameworks.securityalliance.org/certs/overview/
Security Alliance，認證指引。各項控制措施的狀態、認證標準及證據類別。https://frameworks.securityalliance.org/certs/certification-guidelines/
Security Alliance，評估機構認可；以及 SEAL 認證。認可程序、評估機構職責、計畫現況及目前公開的合作夥伴資訊。https://frameworks.securityalliance.org/certs/certified-partners/ 和 https://securityalliance.org/our-work/certifications
Security Alliance Radar，徵求意見：SEAL 認證。合約安全成熟度、SOC 2 與 ISO 27001 的定位、模組化及可驗證性的緣由。https://radar.securityalliance.org/request-for-comments-seal-certifications/
Security Alliance Radar，SEAL 認證：現已開放申請（Isaac Patka，2026 年 6 月 2 日）。六大領域概覽，以及針對整個約定範圍作出的單一通過／不通過決定。https://radar.securityalliance.org/seal-certifications-auditor-accreditations-protocol-assessments/
Security Alliance，SFC：DevOps 與基礎設施。程式碼儲存庫權限、分支保護、程式碼審查及掃描控制措施、CI/CD、供應鏈管理及基礎設施設定的公開基準。https://frameworks.securityalliance.org/certs/sfc-devops-infrastructure/