Web3 보안 감사 보고서를 공개하기 전에는 모든 발견사항을 해결 완료, 부분 해결, 위험 수용, 미해결의 네 가지 상태로 나누어야 합니다. 그런 다음 해결되지 않은 항목마다 영향 범위, 보완 통제, 조치 예정 시점을 문서로 정리해 두어야 합니다. 이렇게 준비하면 보고서 수치만 보고 생길 수 있는 오해를 줄이고, 투자자와 거래소, 커뮤니티가 같은 기준으로 위험을 판단할 수 있습니다.
감사보고서를 공개하기 전에 미해결 발견사항을 따로 정리해야 하는 이유는 무엇입니까?
보안감사보고서는 특정 시점에 특정 코드 버전을 검토한 결과입니다. 그런데 외부 독자는 보고서 요약 표에 나온 심각도별 건수와 "해결됨" 또는 "인지함" 같은 짧은 상태 표시만 보고 프로젝트를 평가하는 경우가 많습니다. 높은 심각도의 항목이 "인지함"으로만 남아 있으면 설계상 의도된 동작인지, 조치를 미룬 것인지 독자가 구분하기 어렵습니다.
Web3 프로젝트의 보안 감사는 한 번 배포된 컨트랙트를 고치기 어렵고, 자산이 컨트랙트 안에 직접 예치된다는 점에서 일반 소프트웨어 점검과 다릅니다. 그래서 공개 전에 프로젝트 팀이 항목별 판단 근거를 먼저 정리해야 커뮤니티 질문이나 상장 심사 요청에 일관되게 답할 수 있습니다. 국내에서는 금융위원회가 「가상자산 이용자 보호 등에 관한 법률」이 2024년 7월 19일부터 시행된다고 발표했습니다. 보고서를 외부에 내놓을 때 표현 하나하나가 이용자의 판단에 영향을 줄 수 있으므로, 법적 해석이 필요한 대목은 관련 분야 전문가의 검토를 받는 것이 바람직합니다.
발견사항의 해결 상태는 어떤 기준으로 분류합니까?
상태 분류는 감사인이 보고서에 적은 표기를 그대로 옮기는 데서 끝나지 않습니다. 프로젝트 팀이 실제 배포 코드와 대조해 다시 확인해야 합니다. 감사인이 "해결됨"으로 표시했더라도 그 수정 커밋이 실제 배포 버전에 들어가지 않았다면 외부 설명에서는 해결 완료로 볼 수 없습니다. 아래 표는 내부 정리에 쓸 수 있는 분류 기준입니다.
| 상태 | 판단 기준 | 공개 시 함께 밝힐 내용 |
|---|---|---|
| 해결 완료 | 수정 커밋을 감사인이 재검토했고, 그 커밋이 배포 바이트코드에 반영됨 | 수정 커밋 식별자, 재검토 일자, 배포 주소 |
| 부분 해결 | 공격 경로 일부는 차단했지만 잔여 조건이 남아 있음 | 남은 조건, 악용에 필요한 전제, 추가 조치 계획 |
| 위험 수용 | 설계상 의도된 동작이거나, 비용 대비 효과를 따져 수정하지 않기로 결정함 | 수용 사유, 결정 주체, 보완 통제 수단 |
| 미해결 | 조치 계획은 있으나 아직 코드에 반영되지 않음 | 예상 조치 시점, 그 사이 적용하는 임시 통제 |
심각도 표기 방식은 감사인마다 다를 수 있습니다. 내부적으로는 공통 기준으로 다시 정리해 두는 편이 좋습니다. 미국 국립표준기술연구소(NIST)가 운영하는 국가 취약점 데이터베이스(NVD)는 공통 취약점 점수 체계(CVSS)를 사용해 취약점의 심각도를 표시합니다. 이 체계의 공격 경로, 공격 복잡도, 필요 권한 같은 평가 요소를 참고하면 감사인별 등급 차이를 줄일 수 있습니다. 다만 컨트랙트 취약점은 자산 손실 규모와 직접 연결되므로, 점수만으로 판단하지 말고 예치 자산 규모와 권한 구조를 함께 고려해야 합니다.
미해결 항목 설명서에는 무엇을 담아야 합니까?
미해결 항목이나 위험 수용 항목에는 보고서와 별도로 프로젝트 측 설명 문서를 붙이는 것이 일반적입니다. 이 문서에는 다음 요소가 빠짐없이 들어가야 합니다.
- 약점 유형: 재진입, 접근 제어 누락, 가격 조작 등 어떤 범주의 문제인지 밝힙니다.
- 영향 범위: 어느 컨트랙트와 함수가 관련되는지, 최대 어느 정도의 자산이 위험에 노출되는지 씁니다.
- 악용 전제 조건: 관리자 키 탈취가 필요한지, 외부 오라클 조작이 필요한지 등 공격이 성립하는 조건을 적습니다.
- 보완 통제: 다중서명, 타임락, 일시 중지 기능, 예치 한도 같은 임시 방어 수단을 밝힙니다.
- 조치 일정과 책임자: 코드 수정 예정 시점, 재감사 여부, 내부 담당 조직을 명시합니다.
약점 유형을 쓸 때는 공개 분류 체계를 함께 표기하면 설명의 객관성이 높아집니다. 미국 비영리 연구기관 MITRE가 관리하는 CWE(Common Weakness Enumeration)는 소프트웨어와 하드웨어의 약점 유형을 식별 번호로 정리한 공개 목록입니다. 재진입이나 부적절한 접근 제어처럼 컨트랙트에서 자주 나오는 문제도 해당 범주의 번호로 연결해 둘 수 있습니다. 이렇게 하면 외부 보안 연구자가 문서를 검토할 때 같은 용어로 의견을 주고받을 수 있습니다.
공개 시점과 배포 버전은 어떻게 맞춥니까?
보안감사보고서 공개에서 가장 흔한 문제는 보고서에 적힌 커밋과 실제 메인넷 배포 코드가 서로 다른 경우입니다. 감사 이후 기능을 추가하거나 매개변수를 바꾼 뒤 그대로 배포했다면, 보고서는 현재 운영 중인 컨트랙트를 설명하지 못합니다. 공개 전 점검은 다음 순서로 진행하는 것이 안전합니다.
- 보고서에 기재된 최종 검토 커밋 식별자를 확인합니다.
- 해당 커밋을 같은 컴파일러 버전과 최적화 설정으로 다시 빌드합니다.
- 재빌드한 바이트코드가 블록 탐색기에 검증된 배포 코드와 일치하는지 대조합니다.
- 프록시 구조라면 구현 컨트랙트 주소와 업그레이드 권한 보유 주소를 따로 기록합니다.
- 차이가 있으면 차이 부분만 추가 검토를 받거나, 보고서 범위 밖의 변경임을 공개 문서에 밝힙니다.
점검 절차를 문서로 남겨 두는 일도 중요합니다. NIST가 발간한 특별간행물 SP 800-115는 정보보안 기술 시험·평가의 계획과 수행, 발견사항 분석을 돕기 위한 기술 지침입니다. 이 구성을 참고하면 내부 검증 기록을 감사인의 보고서와 같은 흐름으로 정리할 수 있습니다. 감사 업체의 스마트 컨트랙트 감사 안내 예시로는 web3보안감사보고서 관련 페이지가 있으며, 이를 참고해 범위 설정과 재검토 절차를 내부 체크리스트와 비교해 볼 수 있습니다.
보고서를 공개한 뒤에는 무엇을 계속 관리해야 합니까?
보안감사보고서는 공개한 날부터 시간이 지날수록 현재 상태와 멀어집니다. 새로운 공격 기법이 알려지거나 의존하는 외부 라이브러리와 오라클에서 취약점이 발견되면, 당시 "해결 완료"였던 판단도 다시 살펴야 합니다. 공개 이후에는 최소한 아래 항목을 정기적으로 관리하는 것이 좋습니다.
- 미해결 및 위험 수용 항목의 상태 변경 이력과 갱신 일자
- 컨트랙트 업그레이드가 있을 때 해당 변경분의 감사 여부
- 의존 라이브러리와 외부 프로토콜의 보안 공지 확인
- 관리자 키와 다중서명 서명자 구성의 변경 기록
외부에서 실제로 악용되는 취약점 정보를 챙기는 것도 도움이 됩니다. 미국 사이버보안·인프라보안청(CISA)은 실제 악용이 확인된 취약점을 모은 KEV(Known Exploited Vulnerabilities) 목록을 공개하고 있습니다. 이 목록은 주로 일반 소프트웨어와 인프라를 다루지만, 프로젝트의 프런트엔드 서버, 노드 운영 환경, 개발 도구 공급망을 점검할 때 참고할 수 있습니다. 컨트랙트 자체가 안전하더라도 서명 인터페이스나 배포 파이프라인이 침해되면 자산 손실로 이어질 수 있으므로, 보고서 범위 밖의 영역도 별도로 관리해야 합니다.
자주 묻는 질문
미해결 항목이 남아 있는 보고서를 공개해도 됩니까?
미해결 항목이 있다는 사실만으로 공개가 불가능한 것은 아닙니다. 다만 각 항목의 영향 범위, 보완 통제, 조치 일정을 함께 밝혀야 독자가 위험을 정확히 판단할 수 있습니다. 공개 범위나 표현이 규제 요건에 해당하는지 판단이 필요하다면 법률 전문가와 상의하는 것이 바람직합니다.
감사인이 "인지함"으로 표시한 항목은 위험 수용으로 봐도 됩니까?
그대로 위험 수용으로 분류하는 것은 적절하지 않습니다. "인지함"은 프로젝트 팀이 내용을 확인했다는 뜻일 뿐, 수정하지 않기로 결정한 근거까지 담고 있지는 않기 때문입니다. 내부에서 수용 사유와 결정 주체를 문서로 남긴 뒤에 위험 수용으로 분류해야 합니다.
감사 후 코드를 일부 수정했다면 보고서를 다시 받아야 합니까?
수정 범위에 따라 다르지만, 자산 이동, 권한 검사, 가격 계산과 관련된 로직이 바뀌었다면 변경분에 대한 추가 검토를 받는 것이 일반적입니다. 주석이나 이벤트 정도만 바뀌었다면 바이트코드 대조 결과와 변경 내역을 공개 문서에 기록하는 방식으로 대신할 수 있습니다. 어느 경우든 보고서의 검토 커밋과 배포 코드의 관계를 명확히 밝혀야 합니다.