배포 후에 스마트컨트랙트를 업그레이드한다면, 바뀌는 코드가 자산 이동·권한·가격 산정에 영향을 주는지를 기준으로 재감사 여부를 정합니다. 시점은 업그레이드 코드를 동결한 뒤로 잡고, 메인넷 배포와 타임락 실행 전에 재감사를 마쳐야 합니다. 범위는 변경된 코드만으로 끝나지 않습니다. 변경분이 기존 코드와 맞물리는 상호작용 지점까지 넣어야 합니다. 이전 web3 보안 감사 보고서에서 조치하지 않은 항목과 감사 대상 커밋이 실제 배포 코드와 같은지도 함께 확인해야 재감사의 실효성이 생깁니다.
보안 감사 방법은 어떤 단계로 구성됩니까?
재감사 범위를 정하려면 먼저 일반적인 보안 감사 방법이 어떤 단계로 이루어지는지 알아야 합니다. 업체마다 이름은 다르지만 실무 흐름은 대체로 비슷합니다. 범위 확정, 자동화 분석, 수동 코드 리뷰, 테스트 기반 검증, 보고서 작성, 조치 검증의 순서로 진행됩니다.
- 범위 확정: 감사 대상 저장소, 커밋 해시, 컨트랙트 목록, 외부 의존 라이브러리, 배포 대상 체인을 문서로 정합니다.
- 자동화 분석: 정적 분석 도구로 재진입, 정수 처리, 접근 제어 누락 같은 알려진 취약 패턴을 먼저 찾습니다.
- 수동 코드 리뷰: 자동화 도구가 잡지 못하는 비즈니스 로직 오류, 경제적 공격 경로, 권한 설계 결함을 감사인이 직접 검토합니다.
- 테스트 기반 검증: 퍼징, 불변식 테스트, 메인넷 포크 환경 시뮬레이션으로 발견 사항이 실제로 공격 가능한지 확인합니다.
- 보고 및 조치 검증: 발견 사항을 심각도별로 정리하고, 개발팀이 수정한 코드를 다시 확인한 다음 최종 보고서를 냅니다.
이 흐름은 전통적인 정보보호 평가 방식과도 맞닿아 있습니다. NIST는 SP 800-115 문서에서 조직이 기술적 정보보안 시험·검사를 계획하고 수행하도록 돕는 지침을 제공합니다. 스마트컨트랙트 감사도 이러한 시험·검사 접근을 블록체인 환경에 맞게 옮긴 것으로 이해하면 됩니다.
배포 이후 언제 다시 web3 보안 감사를 받아야 합니까?
모든 코드 변경에 전체 감사를 다시 할 필요는 없습니다. 반대로 작은 변경이라도 자금 흐름에 닿는다면 재감사를 생략하면 안 됩니다. 재감사 여부는 변경 규모보다 변경이 미치는 영향으로 판단해야 합니다. 아래 표는 실무에서 자주 쓰는 판단 기준을 정리한 것입니다.
| 변경 유형 | 위험 판단 | 권장 대응 |
|---|---|---|
| 프록시 구현체 교체, 스토리지 레이아웃 변경 | 높음: 기존 상태 변수 충돌 가능 | 변경분과 스토리지 호환성을 포함한 재감사 |
| 입출금·청산·보상 계산 로직 수정 | 높음: 자산 손실과 직결 | 변경 함수와 호출 경로 전체를 재감사 |
| 오라클 교체 또는 가격 산정 방식 변경 | 높음: 가격 조작 공격 경로 발생 가능 | 경제적 공격 시나리오를 포함한 재감사 |
| 관리자 권한·멀티시그·타임락 구조 변경 | 중간~높음: 권한 탈취 시 피해 범위 확대 | 권한 모델 중심의 부분 감사 |
| 이벤트 로그 추가, 주석·가스 최적화 | 낮음: 동작이 바뀌지 않는 경우에 한함 | 내부 리뷰와 테스트로 대체 가능, 차이 검토 기록 보관 |
| 신규 체인 배포(동일 코드) | 중간: 체인별 동작 차이 존재 | 체인 특성(사전 컴파일, 가스 규칙, 브리지 연동) 검토 |
가스 최적화도 표에서는 낮은 위험으로 분류했지만 주의가 필요합니다. 인라인 어셈블리를 도입하거나 검사 로직을 없애는 방식이라면 높은 위험으로 다시 분류해야 합니다. 판단이 애매하면 위험을 높게 잡는 편이 안전합니다.
재감사 범위는 어떻게 정해야 합니까?
재감사는 흔히 차이 기반 감사로 진행합니다. 직전 감사 커밋과 새 커밋 사이의 변경분을 중심으로 보는 방식입니다. 다만 변경된 줄만 보면 결함을 놓치기 쉽습니다. 범위를 정할 때는 다음 항목을 함께 문서화해야 합니다.
- 기준 커밋과 대상 커밋: 직전 보고서가 다룬 커밋 해시와 이번에 배포할 커밋 해시를 함께 적습니다.
- 영향 함수 목록: 변경 함수를 호출하는 함수, 변경 함수가 읽고 쓰는 상태 변수를 추적해 범위에 넣습니다.
- 외부 의존성 변화: 라이브러리 버전, 컴파일러 버전, 연동 프로토콜 주소가 바뀌었는지 확인합니다.
- 미조치 항목 승계: 이전 보고서에서 위험을 인지만 하고 넘어간 항목이 이번 변경으로 악화되는지 검토를 요청합니다.
- 업그레이드 절차 자체: 초기화 함수 재호출 가능성, 마이그레이션 스크립트, 타임락 대기 시간도 감사 대상에 넣습니다.
범위 문서가 구체적일수록 감사 기간과 비용을 예측하기 쉽고, 결과 보고서의 신뢰도도 높아집니다.
web3 보안 감사 보고서에서 무엇을 확인해야 합니까?
보고서를 받으면 발견 건수보다 구조와 조치 상태를 먼저 봐야 합니다. 같은 양식으로 보이는 web3 보안 감사 보고서라도 아래 항목이 빠져 있으면 대외적으로 근거 자료로 쓰기 어렵습니다.
- 감사 범위와 커밋 해시: 보고서에 적힌 커밋과 실제 온체인 배포 바이트코드가 일치하는지 검증 가능한 형태여야 합니다.
- 심각도 분류 기준: 치명·높음·중간·낮음·정보 같은 등급을 어떤 기준(영향도와 발생 가능성)으로 매겼는지 설명이 있어야 합니다.
- 조치 상태: 수정 완료, 부분 수정, 위험 인지 후 유지 같은 상태가 항목별로 표시되고, 수정 커밋이 함께 기록되어야 합니다.
- 가정과 제외 범위: 오라클이 정상 동작한다는 가정, 관리자 키가 안전하게 관리된다는 가정처럼 감사가 전제로 삼은 조건을 명시해야 합니다.
- 중앙화 위험 언급: 관리자가 자금을 동결하거나 이동할 수 있는 권한이 있는지 별도로 정리되어 있는지 확인합니다.
특히 위험을 인지만 하고 유지한 항목에는 운영팀의 사유와 보완 통제(모니터링, 한도 설정 등)를 함께 기록해 두어야 합니다. 그래야 다음 재감사 때 판단 근거로 쓸 수 있습니다.
감사가 끝난 뒤 운영 단계에서는 무엇을 이어가야 합니까?
감사는 특정 시점의 코드를 검토한 결과일 뿐 배포 이후의 안전까지 보장하지는 않습니다. NIST가 2024년 발표한 사이버보안 프레임워크(CSF) 2.0은 보안 활동을 거버넌스, 식별, 보호, 탐지, 대응, 복구의 여섯 가지 기능으로 나눕니다. 감사는 주로 식별과 보호 단계에 해당하므로 탐지·대응·복구 체계를 따로 갖춰야 합니다.
탐지 단계에서는 대량 출금, 관리자 함수 호출, 가격 급변 같은 이상 징후를 실시간으로 감시합니다. 대응 단계에서는 일시 정지 권한을 누가 어떤 조건에서 행사할지를 사전에 정해 둡니다. 복구 단계에서는 사고 후 재배포와 이용자 공지 절차를 문서로 준비합니다. 버그 제보 창구를 열어 외부 연구자의 발견 사항을 받는 방식도 감사를 보완하는 수단이 됩니다.
국내에서 서비스를 운영한다면 조직 차원의 관리체계도 함께 점검해야 합니다. 한국인터넷진흥원(KISA) 또는 인증기관은 정보보호 및 개인정보보호 조치가 인증기준에 적합한지를 증명하는 정보보호 및 개인정보보호 관리체계 인증(ISMS-P) 제도를 운영합니다. 스마트컨트랙트 감사가 코드 수준의 점검이라면, 이러한 관리체계는 키 관리와 접근 통제, 사고 대응 같은 조직 운영 영역을 다룹니다.
가상자산을 다루는 사업이라면 규제 환경도 확인해야 합니다. 금융위원회 소관의 「가상자산 이용자 보호 등에 관한 법률」은 가상자산사업자의 이용자 예치금 보호, 이용자 가상자산 보관 의무, 불공정거래행위 규제 등을 규정하고 있습니다. 사업 형태에 따라 적용 범위가 다를 수 있습니다. 구체적인 해당 여부는 법률 전문가에게 상담받아 판단하는 것이 바람직합니다.
자주 묻는 질문
한 번 감사를 받은 컨트랙트도 업그레이드하면 보고서를 새로 받아야 합니까?
자산 이동, 권한, 가격 산정, 스토리지 구조에 영향을 주는 변경이라면 새 보고서나 추가 보고서를 받는 것이 바람직합니다. 기존 보고서는 기준 커밋의 코드에만 유효하기 때문입니다. 동작이 바뀌지 않는 경미한 변경이라면 내부 리뷰 기록으로 대신할 수 있습니다.
자동화 분석 도구만으로 보안 감사를 대신할 수 있나요?
자동화 도구는 알려진 취약 패턴을 빠르게 찾는 데는 효과적입니다. 하지만 비즈니스 로직 오류나 경제적 공격 경로는 잘 잡아내지 못합니다. 따라서 자동화 분석은 수동 리뷰를 보완하는 단계로 활용하는 것이 일반적입니다.
보고서의 위험 인지 후 유지 항목은 어떻게 관리해야 하나요?
항목마다 유지 사유, 보완 통제 수단, 재검토 시점을 기록해 두는 것이 좋습니다. 다음 업그레이드 때 해당 항목의 위험이 커지는지 재감사 범위에 넣어 확인을 요청하면 누적 위험을 관리할 수 있습니다.