블록체인 침투 테스트란 무엇인가? 정의와 범위

이전 아티클인 From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing에서는 블록체인 침투 테스트가 왜 필요한지를 설명했습니다. 이번 아티클에서는 침투 테스트가 무엇인지에 대해 다루며, 블록체인 침투 테스트의 정의와 범위를 더 자세히 살펴봅니다.

블록체인 침투 테스트에 대해 널리 인정되는 공식적인 정의는 존재하지 않으며, 제안된 많은 정의들이 다른 완화 조치들과 뒤섞여 있어서, 감사(audit), 스캔(scan), 버그 바운티(bug bounty)와 같은 용어들이 각각 다른 목적을 가지고 있음에도 침투 테스트의 일부로 포함되는 경우가 있습니다. 이는 특정 작업이 실제로 무엇을 검증했는지 알기 어렵게 만듭니다. 학계와 업계의 실무에서 도출한 우리의 출발점은 의도적으로 단순합니다: 블록체인 침투 테스트는 이름 그대로 수십 년간 정립된 분야인 침투 테스트를 web3 생태계에 적용한 것으로, 실행 중인 web3 환경에 대해 적대적 관점에서 전체 시스템을 평가하는 방식으로 수행됩니다. 이 익숙한 분야에서 시작하여, web3가 위협 모델과 테스터에게 요구되는 판단력에 무엇을 더하는지 살펴보겠습니다.

블록체인 침투 테스트는 합의된 환경과 교전 규칙(rules of engagement) 내에서, 실행 중인 시스템에 대해 적대적이고 실질적인 평가를 수행하여 악용 가능한 경로와 통제 체인을 검증하는 것입니다. 이는 코드 수준의 보안 감사를 보완하며, 독립적으로도 의뢰될 수 있습니다 [1].

이는 개별적인 취약점보다는 경로를 찾는 데 중점을 두며, 명확한 승인, 범위, 접근 가정, 안전 제약 조건 하에서 이루어집니다. 이 아티클은 세 가지 질문에 답합니다: 블록체인 침투 테스트란 무엇인가, 특히 감사가 일반적으로 제공하는 근거를 넘어 무엇을 검증할 수 있는가, 그리고 기관이 어떻게 높은 수준에서 시작할 수 있는가입니다.

web3가 더하는 것: 자금 처리 위협 모델

Web3는 클라우드 인프라, 웹사이트, API, 신원(identity), 권한이 있는 액세스, 벤더, 운영 도구 등 전통적인 침투 테스트 표면을 그대로 유지합니다. 이러한 위협 모델을 블록체인 전용 모델로 대체하는 것이 아니라, 동일한 침입 지점이 가치를 승인, 기록 또는 이동시키는 행위로 직접 이어질 수 있는 시스템으로 확장하는 것입니다.

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

이러한 확장을 형성하는 세 가지 특성이 있습니다.

첫째, 디지털 자산은 직접 이전이 가능합니다. 올바른 트랜잭션이나 출금 경로에 도달한 공격자는 전통적인 결제 시스템에서 사용되는 것과 같은 취소 및 조정 메커니즘을 거치지 않고 자산을 이동시킬 수 있습니다.
둘째, 서명은 종종 자금 이동 행위 자체입니다. 암호학적으로 유효한 서명은 키가 페이로드를 승인했음을 증명하지만, 그 자체로는 운영자가 올바른 대상을 확인했는지, 트랜잭션을 이해했는지, 의도된 승인 정책을 따랐는지를 증명하지는 않습니다.
셋째, 기관이 자체 계약을 배포하는 경우—제품이 더 풍부한 온체인 기능을 추가함에 따라 점점 더 흔해지고 있는—이러한 계약은 공개적으로 호출 가능하며 조합 가능(composable)합니다. 외부 사용자와 다른 계약들은 기관이 통제할 수 없는 순서로 이를 호출할 수 있습니다. 따라서 보안은 각 구성 요소뿐만 아니라, 신원, 애플리케이션, 정책, 서명 시스템, 회계 로직, 계약들이 상호작용하는 방식에도 의존합니다.

우리는 이렇게 발생하는 노출을 **자금 처리 체인(money-handling chain)**으로 모델링합니다—이는 온체인 트랜잭션으로 이어지는 오프체인 서명 의도, 승인, 자금 로직 통제(그리고 점점 더 많이, 기관 자체가 배포한 계약들)를 의미하며, 이러한 단계들을 지원하는 클라우드, 웹, API, 신원 계층들과 함께 존재합니다 [1]. 공격자는 일반적인 침입 지점에서 시작하여 여러 통제 단계를 거쳐 진행할 수 있습니다: 서명을 위해 제시된 내용을 조작하거나, 권한이 있는 워크플로우에 도달하거나, 승인 격차를 악용하거나, 자금 로직이 의도하지 않은 상태 전환을 받아들이게 만드는 것입니다.

핵심적인 조합 격차는 오프체인과 온체인 사이의 핸드오프입니다: 신원, 인터페이스, 승인, 서명, 자금 로직 통제가 행위가 온체인 트랜잭션이 될 때 의도된 행위를 보존하는지 여부입니다. 모든 공격이 전체 체인을 통과하는 것은 아닙니다. 핵심은 보증 대상이 계층을 넘나든다는 것입니다: 개별적으로는 견고해 보이는 통제들이 실행 중인 자금 처리 시스템을 통과하는 악용 가능한 경로로 결합될 수 있습니다.

블록체인 침투 테스트가 하는 일

블록체인 침투 테스트는 이러한 조합 격차를 근거로 전환합니다. 승인된 범위와 합의된 규칙 내에서, 테스터는 계층을 넘나드는 가정들을 공격 시나리오로 변환하고, 실행 중인 환경에 대해 해당 시나리오들을 실행하며, 이들이 재현 가능한 경로와 구체적인 영향을 만들어내는지 판단합니다. 결과물은 단순히 연결되지 않은 취약점 목록에서 멈추는 것이 아니라, 경로를 뒷받침하는 근거, 심각도, 개선 방안, 그리고 합의된 수정 사항에 대한 재테스트로 연결됩니다.

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

이것의 차별점은 독특한 도구가 아니라 전문적인 web3 보안 판단력입니다. 테스터는 관습적인 클라우드, 웹, API, 신원, 권한 있는 접근 표면에서 나온 근거를 연결하는 동시에, 수탁(custody), 트랜잭션 의도, 승인 정책, 출금 흐름, 자금 회계, 온체인 트랜잭션 동작(배포된 계약 포함)을 해석해야 합니다. 도구는 발견이나 검증을 지원할 수 있지만, 전문가의 판단이 관찰된 조건들이 신뢰할 수 있는 자금 이동 경로를 형성하는지를 결정합니다.

이 평가는 체계적이고, 근거 중심이며, 특정 시점을 기준으로 이루어집니다. 결론은 테스트된 시스템, 버전, 구성, 접근 가정, 조건에만 적용됩니다. 잠재적인 경로들은 조사되며, 확인된 악용 가능한 경로들은 재현 가능한 근거와 함께 문서화됩니다.

합의된 표면에 대한 체계적인 작업이 모든 취약점이나 공격 경로가 발견될 것을 보장할 수는 없으며, 책임 있는 작업이라 하더라도 테스터가 침해에 성공할 것을 보장하지는 않습니다.

기관의 web3 환경 내에서, 이러한 시나리오-근거 과정은 동일한 자금 처리 체인의 테스트 가능한 표면인 다섯 가지 연결된 역량에 걸쳐 실행됩니다. 이는 체인을 지원하는 인프라, 세 가지 오프체인 통제, 그리고 이들이 넘겨주는 온체인 트랜잭션에 걸쳐 있으며, 단일 경로가 이들 중 여러 개를 넘나들 수 있기 때문에 서로 연결되어 있습니다:

운영 환경 및 자동화 작업: 테스터는 접근, 배포, 시크릿(secrets), 운영 통제가 자금 처리 행위로 연결될 수 있는지 검증하여, 운영상의 침입 지점을 도달 가능한 영향과 연결하는 근거를 만들어냅니다.
웹 및 dApp 프론트엔드, 권한 부여, 서명 의도: 테스터는 사용자나 운영자에게 제시된 트랜잭션이 최종적으로 승인된 행위와 다를 수 있는지 검증하고, 조작된 흐름과 그 결과로 나온 서명 또는 제출된 동작을 기록합니다.
서명, 승인, 출금 권한 체인: 테스터는 신원, 역할, 정책 검사, 승인 단계가 우회되거나 조합될 수 있는지 검증하고, 그 순서와 이로 인해 가능해지는 권한 없는 행위를 문서화합니다.
자금 비즈니스 로직: 테스터는 잔액, 한도, 정산, 출금 규칙, 상태 전환이 의도하지 않은 조건을 받아들이는지 검증하여, 단순한 기술적 결함이 아니라 재현 가능한 비즈니스 영향 경로를 포착합니다.
온체인 트랜잭션 및 배포된 계약: 테스터는 기관의 온체인 상호작용이 적대적 런타임 조건 하에서 어떻게 동작하는지 검증합니다. 기관이 자체 계약을 배포한 경우, 해당 계약의 런타임 동작을 실행해보고 관찰된 결과에 대한 트랜잭션 수준의 근거를 보존합니다. 코드 수준의 보증은 여전히 해당하는 Code Audit의 역할입니다.

Part 4: Web3 Attack Surfaces: A Penetration Testing Overview에서는 핵심 목표—합의된 실행 환경 전반의 조건들이 재현 가능한 영향으로 이어지는지 확인하는 것—를 바꾸지 않고 이러한 표면들과 그 연결 관계를 매핑합니다.

다른 보증 방식과의 관계

가장 명확한 비교 방법은 보증 목표에 따른 것입니다: 즉 해당 작업이 지원하려는 결정과 그로부터 나올 것으로 예상되는 근거입니다. 아래 도표에서 볼 수 있듯이, 방법론은 서로 겹칠 수 있고, 분야는 협업할 수 있으며, 한 팀은 오로지 정적(static)이고 다른 팀은 오로지 동적(dynamic)이라고 가정하는 것은 유용한 경계가 되지 못합니다. 배포된 계약, 클라우드나 RPC 표면, 서명 시스템과 같은 동일한 대상이 이러한 여러 분야에 걸쳐 해당될 수 있습니다. 다른 것은 각 분야가 강조하는 보증 목표이며, 시스템에 대한 독점적인 권리가 아닙니다.

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

침투 테스트와 코드 수준 감사

코드 수준 감사의 명명된 형태인 Code Audit은 주로 코드(설계, 아키텍처, 프로토콜 가정 포함)에 대한 보증을 구축합니다. 이는 전문가 검토와 탐지 도구를 결합하며, 동적 기법을 포함할 수도 있고, 합의된 감사 범위에 대해 서명된 보고서를 생성합니다. 계약, 체인, 브릿지, 롤업, 지갑 또는 기타 구현에 대해, 감사는 설계와 코드가 의도된 보안 속성을 충족하는지를 묻습니다.

침투 테스트는 주로 합의된, 실행 중인 기관 환경 전반의 실제 조건들이 재현 가능한 영향으로 연결될 수 있는지를 확립합니다. 이는 배포된 애플리케이션, 신원, 구성, 워크플로우, 비즈니스 로직, 서명 시스템, 계약 호출 간의 상호작용을 따라가며, 그 경로를 재현하고 개선하는 데 필요한 근거를 기록합니다.

이는 능력의 제한이 아니라 목표와 근거의 차이입니다. 감사자는 테스트를 실행하고, 컴포넌트를 퍼징하며, 런타임 동작을 조사할 수 있습니다. 침투 테스터는 경로를 이해하기 위해 구성, 애플리케이션 로직, 구현 세부 사항을 검토할 수 있습니다. 방법론은 겹칠 수 있고 팀들은 함께 작업할 수 있습니다. 이 서비스들은 서로 대체하는 것이 아니라 보완하는 관계입니다: 감사만으로는 일반적으로 기관 전체의 런타임 악용 가능성에 대한 이러한 근거를 제공하지 못하며, 침투 테스트는 감사가 다루는 구현 및 프로토콜 속성에 대한 코드 수준의 보증을 대체하지 않습니다.

따라서 실제 기관 경로에서의 계약의 적대적 동작은 침투 테스트의 범위에 속할 수 있지만, 계약 코드 자체에 대한 보증은 해당하는 Code Audit로 이어집니다.

스캐닝, 버그 바운티, 특화된 테스트

취약점 스캐닝은 알려진 시그니처, 노출된 서비스, 누락된 패치, 흔한 구성 문제들에 걸쳐 자동화된 폭넓은 커버리지를 제공합니다. 이는 반복 가능한 가시성을 지원하며 정찰(reconnaissance)에도 기여할 수 있는 반면, 침투 테스트는 전문가 주도의 깊이를 더하고 조건들이 의미 있는 경로로 연결될 수 있는지를 판단합니다.

버그 바운티는 독립적인 연구자들이 공개된 규칙에 따라 적격 발견 사항을 보고하도록 초청합니다. 이러한 지속적이고 크라우드소싱 방식의 모델은 롱테일(long-tail) 이슈들을 드러낼 수 있는 반면, 침투 테스트 작업은 팀을 배정하여 합의된 환경을 체계적으로 조사하고 통합된 근거, 심각도, 개선 방안, 재테스트를 제공합니다. 이 두 모델은 상호 보완적이며 어느 것도 완전한 발견을 보장하지는 않습니다.

예를 들어, BlockSec의 Blockchain Security Testing은 침투 테스트의 상위 또는 하위 개념이 아니라 형제 관계에 있는 프로그램입니다. 이는 차등 테스트(differential testing), 퍼징(fuzzing), 프라이빗 배포, 대규모 RPC 서비스 거부 테스트, 노드 또는 클러스터 인프라 테스트를 포함한 특화된 엔진을 사용하여 맞춤형 인프라의 구현 정확성과 복원력을 검증합니다 [2]. 블록체인 침투 테스트는 실행 중인 자금 처리 시스템을 통과하는 기관 수준의 계층 간 경로에 중점을 둡니다. 애플리케이션 호스팅과 애플리케이션 CI/CD는 침투 테스트 표면으로 이어지며, 노드 및 클러스터 인프라와 대규모 RPC 복원력은 Blockchain Security Testing으로 이어집니다. 아키텍처에는 둘 다 필요할 수 있습니다.

인접한 목표들 역시 정확한 경로 설정이 필요합니다. 계약 코드 수준의 보증은 해당하는 Code Audit로 이어집니다. MPC, TSS, TEE 설계를 포함한 키 수탁 구현의 암호학적 정확성은 Wallet Security Audit로 이어집니다. 결제 측 에이전틱 시스템은 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

이것은 순서가 아니라 경로 설정 가이드입니다. 단일 시스템이 여러 보증 목표를 만들어낼 수 있으며, 따라서 조율된 일련의 평가들을 필요로 할 수 있습니다. 이러한 라벨들은 상호 배타적이지 않습니다.

관할권과 기관 유형에 따라, 테스트는 규제 요건이거나 감독 기대 사항일 수 있으며, 일부 체제에서는 독립적인 제3자를 요구합니다. Part 1에서 이러한 구분들을 설명합니다 [3]. 규제 적용 여부는 법률 자문을 통해 확인해야 합니다.

시작하는 방법

의사결정에 앞서, 다음 세 가지 질문으로 시작할 수 있습니다: 어떤 시스템이 자금을 이동시키는가? 이미 존재하는 보증 근거는 무엇인가? 아직 적대적으로 검증되지 않은 통제 체인은 무엇인가? 이 질문들에 대한 답은 서비스를 이름으로 성급하게 선택하지 않고도 보증 격차를 식별하는 데 도움이 됩니다.

이후 범위 설정 논의를 통해 대상, 접근 가정, 안전장치, 예상 결과물을 조율할 수 있습니다. Part 3: Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing에서는 작업을 실행하는 데 필요한 승인, 안전, 조율에 대해 다룹니다 [4].

이를 실행할 준비가 되셨다면, 테스트 시작 전에 대상, 근거, 안전장치를 조율하기 위해 BlockSec과 함께 보증 격차를 정의해보세요.

공격 표면 가이드를 계속 살펴보세요: