블록체인 사업을 처음 맡은 기업 보안팀은 외부 웹3 보안 감사 결과를 단독 산출물로 보관하지 말고, 사내 위험관리 체계의 통제 항목과 하나씩 대응시켜야 합니다. 이를 위해 보고서의 감사 범위와 커밋 해시, 발견사항의 조치 상태를 먼저 확인합니다. 그다음 기존 정보보호 관리체계의 통제 항목과 대조하여 공백이 남는 부분을 운영 통제나 기업용 웹3 보안 솔루션으로 보완하는 순서로 진행합니다.
웹3 보안 감사는 기존 정보보안 점검과 무엇이 다른가요?
기존 정보보안 점검은 서버, 네트워크, 웹 애플리케이션, 접근권한처럼 기업이 통제하는 자산을 대상으로 합니다. 반면 웹3 보안 감사는 블록체인에 배포되어 누구나 호출할 수 있는 스마트컨트랙트를 주로 다룹니다. 배포 이후에는 수정이 어렵거나 업그레이드 절차를 별도로 거쳐야 한다는 점이 가장 큰 차이입니다. 취약점이 발견되었을 때 패치를 바로 적용하는 방식이 통하지 않기 때문에, 배포 전 검증의 비중이 훨씬 높습니다.
점검 관점도 다릅니다. 기존 점검이 인증 우회나 입력값 검증 누락을 주로 찾는다면, 스마트컨트랙트 감사는 재진입, 권한 함수의 오남용, 가격 오라클 조작, 산술 처리 오류, 토큰 경제 설계상의 논리 결함까지 살핍니다. 코드가 의도대로 동작하더라도 경제적 유인 구조 때문에 자산이 유출될 수 있으므로, 비즈니스 로직 검토가 감사의 핵심 비중을 차지합니다.
국내에서 한국인터넷진흥원(KISA)이 운영하는 정보보호 및 개인정보보호 관리체계(ISMS-P) 인증은 관리체계 수립과 보호대책 요구사항을 기준으로 조직의 보안 수준을 심사하는 제도입니다. 이 인증은 조직 단위의 관리체계를 다루므로, 개별 스마트컨트랙트의 코드 결함까지 직접 검증하지는 않습니다. 따라서 기업은 두 영역을 대체 관계가 아니라 보완 관계로 이해해야 합니다.
웹3 보안 감사보고서에서 기업 보안팀이 먼저 읽어야 할 항목은 무엇인가요?
웹3 보안 감사보고서를 받으면 요약 페이지의 등급이나 점수보다 감사 범위를 먼저 확인해야 합니다. 보고서가 어떤 저장소, 어떤 커밋, 어떤 파일을 대상으로 했는지가 명시되어 있지 않다면, 실제 배포된 코드와 감사된 코드가 같은지 확인할 방법이 없습니다. 기업 보안팀은 아래 항목을 순서대로 점검하는 것이 효율적입니다.
| 확인 항목 | 보고서에서 볼 부분 | 사내 판단 기준 |
|---|---|---|
| 감사 범위 | 대상 저장소, 커밋 해시, 파일 목록 | 배포된 바이트코드와 감사 대상이 일치하는지 검증 가능해야 함 |
| 범위 제외 항목 | 외부 라이브러리, 오라클, 프런트엔드, 운영 키 | 제외된 영역은 별도 통제 또는 추가 점검 대상으로 등록 |
| 발견사항 심각도 | Critical, High, Medium, Low, Informational 분류 | 사내 위험 등급표로 재분류하여 위험 등록부에 기록 |
| 조치 상태 | Resolved, Acknowledged, Partially Resolved | 미해결·수용 항목은 위험 수용 승인 절차를 거쳐야 함 |
| 중앙화 위험 | 관리자 권한, 업그레이드 권한, 일시중지 기능 | 권한 보유 주체와 키 관리 방식이 내부 규정에 맞는지 확인 |
특히 조치 상태가 Acknowledged로 표시된 항목은 개발팀이 문제를 인지했지만 수정하지 않았다는 뜻인 경우가 많습니다. 기업 환경에서는 이 항목을 그대로 넘기지 않고, 위험 소유자를 지정한 뒤 수용 사유와 보완 통제를 문서로 남겨야 감사 대응이 가능합니다. 재감사 여부와 재감사 범위도 함께 확인합니다. 최초 감사 후 코드가 수정되었다면 수정분이 다시 검토되었는지가 보고서의 실효성을 좌우합니다.
감사 결과를 사내 통제 기준과 어떻게 연결하나요?
연결 작업의 기준 틀로는 국제적으로 통용되는 프레임워크를 활용하는 방법이 무난합니다. 미국 국립표준기술연구소(NIST)가 2024년 발표한 사이버보안 프레임워크(CSF) 2.0은 거버넌스(Govern), 식별(Identify), 보호(Protect), 탐지(Detect), 대응(Respond), 복구(Recover)의 여섯 가지 기능으로 보안 활동을 구분합니다. 감사 발견사항을 이 기능별로 분류하면, 코드 결함은 보호 영역으로, 관리자 키 문제는 거버넌스 영역으로, 이상 거래 감시 공백은 탐지 영역으로 정리됩니다.
개발 단계의 통제는 NIST가 발간한 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)를 참고할 수 있습니다. 이 문서는 각 소프트웨어 개발 수명주기(SDLC)에 통합할 수 있는 상위 수준의 보안 개발 관행을 제시합니다. 필자는 이러한 관행을 개발 과정에 반영하면 외부 감사를 개발 마지막 단계의 일회성 행사로 두지 않는 데 도움이 된다고 봅니다. 실무에서는 다음 순서로 연결 작업을 진행합니다.
- 감사 발견사항 전체를 사내 위험 등록부 양식으로 옮기고 고유 번호를 부여합니다.
- 각 항목을 사내 통제 항목(접근통제, 변경관리, 키 관리, 로그 관리 등)과 대응시킵니다.
- 대응되는 통제가 없는 항목은 신규 통제 후보로 분류하고 담당 부서를 지정합니다.
- 미해결 항목은 위험 수용, 위험 완화, 위험 회피 중 처리 방침을 정하고 승인권자의 결재를 받습니다.
- 배포 전 최종 점검표에 감사 범위와 배포 코드의 일치 여부 확인 절차를 포함합니다.
사업 형태가 가상자산 보관이나 거래 중개에 해당한다면 법적 요건도 함께 검토해야 합니다. 특정 금융거래정보의 보고 및 이용 등에 관한 법률 제7조는 가상자산사업자의 신고 요건으로 정보보호 관리체계(ISMS) 인증 획득을 정하고 있습니다. 또한 가상자산 이용자 보호 등에 관한 법률은 가상자산사업자가 자기의 가상자산과 이용자의 가상자산을 분리하여 보관하도록 정하고 있습니다. 사업 구조가 이러한 규제 대상에 해당하는지는 개별 사실관계에 따라 달라지므로, 판단이 필요한 경우 관련 분야의 법률 전문가와 상담하는 것이 바람직합니다.
기업용 웹3 보안 솔루션은 감사 이후 어떤 공백을 메워야 하나요?
감사는 특정 시점의 특정 코드를 검토한 결과이므로, 배포 이후의 운영 위험까지 보장하지 않습니다. 기업용 웹3 보안 솔루션을 검토할 때는 감사가 다루지 못한 영역을 기준으로 필요 기능을 정하는 것이 합리적입니다. 대표적인 공백은 다음과 같습니다.
- 운영 키 관리: 관리자 권한과 업그레이드 권한을 다중서명이나 하드웨어 보안 모듈로 분산 보관하는 체계가 필요합니다.
- 실시간 온체인 모니터링: 대량 출금, 권한 변경, 비정상적인 함수 호출을 탐지하고 담당자에게 즉시 알리는 기능이 필요합니다.
- 비상 대응 절차: 일시중지 기능을 누가, 어떤 조건에서 실행하는지 사전에 정하고 정기적으로 모의훈련을 진행해야 합니다.
- 외부 의존성 관리: 오라클, 브리지, 외부 라이브러리의 변경 사항을 추적하고 영향도를 평가하는 절차가 필요합니다.
- 변경관리 연계: 컨트랙트 업그레이드가 사내 변경관리 승인 절차를 거치도록 배포 파이프라인과 연결해야 합니다.
솔루션 도입 여부를 판단할 때는 기능 목록보다 기존 보안관제 체계와의 연동 가능성을 우선 확인합니다. 온체인 경보가 별도 화면에만 표시되고 기존 보안 이벤트 관리 체계나 대응 절차와 분리되어 있다면, 경보가 발생해도 책임 소재가 불분명해집니다. 경보 등급, 담당자, 대응 시한을 사내 침해사고 대응 절차에 포함시키는 것이 운영 단계의 핵심입니다.
자주 묻는 질문
외부 감사를 한 번 받으면 이후에는 추가 감사가 필요 없습니까?
감사는 특정 커밋 기준의 검토이므로 코드가 변경되면 효력이 그대로 유지된다고 보기 어렵습니다. 업그레이드나 기능 추가, 외부 의존성 변경이 있을 때는 변경분에 대한 재검토 여부를 판단해야 합니다. 변경 규모와 자산 노출 수준을 기준으로 재감사 범위를 정하는 것이 일반적입니다.
ISMS-P 인증을 받은 기업이라면 스마트컨트랙트 감사를 생략해도 되나요?
ISMS-P 인증은 조직의 관리체계와 보호대책을 심사하는 제도이며, 개별 스마트컨트랙트 코드의 논리 결함을 검증하는 절차가 아닙니다. 두 영역은 점검 대상과 방법이 다르므로 서로 대체하기 어렵습니다. 관리체계 안에 컨트랙트 감사와 재감사 절차를 포함시키는 방식으로 함께 운영하는 것이 바람직합니다.
감사보고서의 미해결 항목은 내부에서 어떻게 처리해야 하나요?
미해결 항목은 위험 등록부에 기록하고 위험 소유자와 처리 방침을 지정해야 합니다. 수정하지 않기로 결정했다면 수용 사유, 보완 통제, 승인권자를 문서로 남겨야 이후 내부감사나 외부 실사에서 설명할 수 있습니다. 해당 항목이 이용자 자산에 직접 영향을 준다면 배포 일정을 조정하는 방안도 함께 검토합니다.