SEAL Certifications는 Security Alliance(SEAL)가 공개한 오픈소스 운영 보안 인증 프로그램입니다. 현재 기준에는 암호화폐 프로토콜과 관련된 인력, 계정, 서명자, 도메인, 인프라, 트레저리 프로세스 및 대응 역량을 다루는 6개 모듈에 걸쳐 통제 항목이라고 부르는 구체적인 운영 요건 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의 요건을 충족했다는 것 | 명시되지 않은 모듈이나 운영 시스템도 평가되었다는 것 |
| 범위에 포함된 운영 통제 항목과 뒷받침하는 증거에 대한 독립적인 제3자 검토가 이루어졌다는 것 | 소스 코드의 구현 결함을 검토했거나 공격 경로를 테스트했다는 것, 또는 프로토콜에 취약점이 없다는 것 |
| 합의된 범위 전반에서 각 통제 항목의 적합성이 확인되었다는 것 | 보안 점수, 성숙도 등급, 코드 품질에 대한 의견 또는 규제 당국의 승인 |
| 재평가가 필요한, 특정 시점에 유효기간이 제한된 인증이라는 것 | 지속적인 요건 준수 또는 사고가 발생하지 않을 것이라는 보장 |
이러한 한계는 발급 후에도 계속 적용됩니다. SEAL 증명은 프로토콜에 보안 문제가 없음을 의미하지 않습니다 [1]. 유효기간이 제한되어 있고 정기적인 재평가가 필요하며, 요건 미준수가 지속되면 철회될 수 있습니다. SEAL은 고정된 유효기간을 공개하지 않습니다 [1].
3. 프레임워크가 다루는 범위
6개 모듈은 개별적으로 또는 함께 평가할 수 있습니다. 현재 기준에는 통제 항목 99개가 포함되어 있습니다 [1, 2]. When it may apply 열은 모듈 정의를 바탕으로 작성한 설명용 안내이며, SEAL의 공식 범위 설정 규칙이 아닙니다. 최종 범위는 평가 업무 중 고객과 확인합니다.
| 모듈 | 다루는 내용 | 적용될 수 있는 경우 |
|---|---|---|
| 멀티시그 운영(통제 항목 24개) | 서명자 설정, 트랜잭션 실행, 조정, 연속성 및 비상 절차 | 멀티시그 지갑, 서명자 그룹 또는 조율된 트랜잭션 승인 |
| 트레저리 운영(통제 항목 23개) | 수탁 구조, 자산 관리, 트랜잭션 거버넌스, 대사, 모니터링, 공급업체 관리, 보험 및 트레저리 대응 | 트레저리 자산, 자산 배분, 수탁 관계 또는 자금 이동 |
| 사고 대응(통제 항목 13개) | 준비, 에스컬레이션, 커뮤니케이션, 대응 절차서, 훈련 및 공동 대응 | 보안 사고를 탐지하고, 확산을 막고, 소통하며, 복구해야 하는 팀 |
| DevOps 및 인프라(통제 항목 15개) | 저장소 거버넌스, 코드 리뷰 및 스캔 통제, CI/CD, 공급망 관리, 인프라 접근, 모니터링 및 복원력 | 코드 저장소, 배포 파이프라인, 클라우드 인프라 또는 프로덕션 환경 관리 |
| DNS 및 등록기관(통제 항목 16개) | 도메인 소유권, 등록기관 접근, DNS 구성, 모니터링, 복구 및 탈취 대응 | 핵심 도메인, 등록기관 계정, DNS 레코드 또는 이메일 인증 |
| ID 및 계정(통제 항목 8개) | 계정 목록, 소유권, 피싱 방지 인증, 자격 증명 관리, 복구, 접근 권한 검토, 수명주기 관리, 모니터링 및 제3자 접근 | 저장소, 클라우드 플랫폼, 등록기관, 수탁 시스템 또는 내부 도구 전반의 사용자 계정, 서비스 계정 또는 권한 있는 계정 |
DNS 및 등록기관 모듈에 관한 자세한 내용은 스마트 컨트랙트를 넘어: Web3의 도메인 및 DNS 운영 보안을 참조하세요.
모듈을 개별적으로 평가하더라도 운영상으로는 서로 연결되어 있습니다. DevOps 및 인프라와 DNS 및 등록기관의 일부 통제 항목은 ID 및 계정에서 정의한 계정 보안 관행에 의존합니다. 사고 중 멀티시그 서명자를 조율하거나 계정을 복구하는 것처럼 사고 대응 요건도 여러 모듈에 나타납니다 [2].
이러한 모듈 간 참조는 범위에 포함된 통제 항목에 필요한 증거에 영향을 미치지만, 참조된 모듈을 자동으로 인증하거나 필수 인증 순서를 만들거나 평가 업무의 범위를 확대하지는 않습니다. DNS 통제 항목이 계정 보안 관행에 의존한다는 이유만으로 DNS 및 등록기관 증명이 ID 및 계정 증명이 되지는 않습니다. 증명은 해당 범위에 명시된 모듈과 경계에만 적용됩니다 [1, 6].
4. 평가 진행 방식
SEAL은 프레임워크를 유지 관리하고 인증 프로그램을 운영합니다. SEAL 인가 평가 기관으로서 저희는 각 고객 평가를 5단계로 진행합니다 [1, 4]:
그림 1. SEAL 인증 평가 업무는 합의된 범위 설정에서 시작해 증거 검토, 개선 및 재평가를 거친 후 증명 발급으로 이어집니다.
-
범위 설정. 저희는 고객과 협의하여 어떤 모듈, 통제 항목, 시스템, 운영 활동 및 조직 경계를 범위에 포함할지 합의합니다.
-
증거 수집. 고객은 범위에 포함된 통제 항목이 어떻게 설계되고, 담당자가 지정되며, 운영되고, 검토되는지 보여주는 자료를 제공합니다.
-
평가. 저희는 해당 증거를 SEAL이 공개한 요건에 비추어 평가하고, 누락되거나 불충분한 증빙을 파악합니다.
-
개선 및 재평가. 합의된 범위가 기준을 충족하지 못하면 저희는 미충족 사항 보고서를 제공합니다. 고객은 확인된 미충족 사항을 개선하고 재평가를 위해 갱신된 증거를 제출합니다.
-
인증. 합의된 범위가 기준을 충족하면 저희는 SEAL 인가에 따라 공식 온체인 증명을 발급합니다.
증거 수집과 평가는 함께 이루어집니다. 고객이 증빙 자료를 제공하면 BlockSec은 그 자료가 각 통제 항목이 실제로 운영되고 있음을 보여주는지 평가합니다. SEAL의 인증 지침은 증빙 자료를 5가지 범주로 분류합니다. 아래 표에는 지침과 모듈 기준의 예시를 함께 요약했습니다 [2, 3, 7]:
| 증거 범주 | 입증하는 데 도움이 되는 내용 |
|---|---|
| 절차 문서 | 정책, 버전 및 승인 날짜를 포함한 통제 항목의 의도된 내용 |
| 운영 증빙 | 로그, 기록, 티켓 또는 팀원 인터뷰를 통해 해당 프로세스가 실제로 사용되고 있다는 것 |
| 테스트/검증 | 보호 조치나 대응 프로세스를 연습하거나 점검했다는 것 |
| 담당 정보 | 통제 항목의 유지 관리 담당자, 검토 주기 및 마지막 갱신 시점 |
| 기술 자료 | 저장소 및 CI/CD 설정, 클라우드 구성, 등록기관 또는 DNS 내보내기 자료와 그 밖에 범위에 포함된 기술 증거를 비롯한 구성, 스크린샷 또는 시스템 내보내기 자료 |
이러한 증거를 바탕으로 BlockSec은 범위에 포함된 각 통제 항목의 상태를 구현됨(Implemented), 부분적으로 구현됨(Partially Implemented), 구현되지 않음(Not Implemented) 또는 적용 대상 아님(N/A)으로 기록하고 근거를 제시합니다. 공식 인증을 받으려면 합의된 범위 내 통제 항목이 구현됨으로 평가되거나 적용 대상 아님으로 분류할 정당한 근거가 있어야 하며, 이를 뒷받침하는 증거도 필요합니다. 따라서 세부 평가는 통제 항목별로 이루어지지만, 전체 인증 결정은 합의된 범위 전체에 대해 통과 또는 미통과로 내려집니다 [3, 6].
5. 준비 방법
SEAL 인증 평가 업무를 시작하기 전에 다음 4가지를 준비하세요.
-
제안 범위: 의도하는 인증 주장에 중요한 모듈, 시스템, 법인, 팀 및 경계.
-
통제 항목별 자체 평가: 각 요건이 구현됨(Implemented), 부분적으로 구현됨(Partially Implemented), 구현되지 않음(Not Implemented) 또는 적용 대상 아님(N/A) 중 어디에 해당하는지와 각 답변의 근거.
-
증거 목록: 제안 범위에 맞춰 정리한 기존 절차, 운영 기록, 테스트 결과, 담당 기록 및 기술 자료.
-
지정된 참여자: 범위 결정, 증거 수집 및 개선 작업 조율을 담당하는 사람.
프레임워크와 체크리스트가 공개되어 있으므로 팀은 공식 평가 업무를 시작하기 전에도 이 작업을 시작할 수 있습니다. 자체 평가는 문서화되지 않은 프로세스, 누락된 운영 증거, 담당자가 지정되지 않은 통제 항목 및 이미 파악된 개선 작업을 찾는 데 유용합니다. 다만 이는 내부 점검 단계일 뿐입니다. 독립적인 검증을 거치지 않으며 SEAL 증명을 생성하지도 않습니다 [1, 3].
이 4가지 항목은 초기 범위 설정에 도움이 되며, 구체적으로 요청되는 자료는 선정한 모듈에 따라 달라집니다. 위 모듈명은 주제 영역을 정의할 뿐, 필수 인증 순서를 뜻하지 않습니다. 모듈별 통제 항목 안내는 별도 글이 게시되는 대로 제공될 예정입니다. 모듈 선정, 증거 준비 상태 및 평가 업무 범위를 논의하려면 [email protected]으로 문의해 주세요.
참고 자료
- Security Alliance, SEAL 인증 프레임워크: 개요.
- Security Alliance, 모든 인증 내보내기(XLSX), 프레임워크 개요에서 제공. 통제 항목 수와 모듈 간 참조도 2026년 10월에 공개된 6개 모듈 페이지와 대조하여 확인했습니다.
- 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 및 인프라.
