스마트 계약 감사 보고서 읽는 법: 범위·커밋·미해결 이슈

스마트 계약 감사 보고서는 정해진 기간과 범위의 코드·가정에서 발견한 문제와 시험 방법을 기록한 문서입니다. ‘감사 완료’는 취약점이 없다는 보증이 아니며, 독자는 감사 대상 커밋이 현재 배포 바이트코드와 같은지, 제외 범위와 미해결 이슈, 수정본 재검토, 관리자·오프체인 구성요소를 함께 확인해야 합니다.

표지의 audited보다 범위표를 먼저 본다

보고서 첫 페이지의 프로젝트 이름과 날짜만으로 현재 프로토콜을 평가할 수 없다. 저장소 URL, commit hash, 계약 파일 목록, 체인, 컴파일러·최적화 설정, 테스트한 배포 구성을 찾는다. 프런트엔드·오라클·브리지·거버넌스가 제외됐는지도 확인한다.

OWASP SCSVS Assessment는 보고서가 검토한 계약·구성요소와 제외 항목, 통과·실패 통제, 수정 지침을 명확히 해야 한다고 설명한다. 범위 밖 시스템의 안전을 감사가 대신하지 않는다.

여러 감사가 있어도 같은 오래된 커밋을 반복 검토했을 수 있다. 각 보고서의 대상과 현재 구현을 표로 연결하고 감사 이후 diff의 크기와 성격을 본다.

커밋에서 배포 바이트코드까지 연결한다

보고서의 commit을 체크아웃해 컴파일 설정과 의존성 버전을 확인한다. 탐색기의 verified source와 metadata, creation bytecode·runtime bytecode가 대응하는지 본다. immutable·constructor argument·라이브러리 링크 때문에 단순 소스 해시만 비교해서는 안 된다.

프록시라면 감사 대상이 프록시인지 구현인지 구분하고 현재 implementation 슬롯을 읽는다. 감사 후 업그레이드됐으면 새 구현이 같은 코드인지, storage migration과 initializer가 검토됐는지 확인한다.

심각도는 확률과 영향의 편집 결과다

Critical·High·Medium 같은 등급은 감사 회사의 기준과 프로젝트 가정에 따라 다르다. 낮은 확률의 전체 자금 손실과 높은 확률의 작은 장애를 어느 등급으로 두는지 기준표를 읽는다. Informational 항목도 권한 집중이나 운영 실수 단서일 수 있다.

발견 사항에서 공격 전제, 필요한 권한·자본, 영향 자산, 재현 단계, 권고, 팀 응답을 읽는다. ‘accepted risk’는 수정됐다는 뜻이 아니고 ‘acknowledged’도 안전하다는 판정이 아니다.

resolved 표시는 수정 커밋을 재검토했을 때만 강하다

프로젝트가 코드를 바꿨다고 답한 것과 감사자가 수정본을 다시 확인한 것은 다르다. fix commit, retest 날짜, status 설명을 찾는다. 수정이 새 분기나 권한을 추가해 다른 문제를 만들 수 있어 단순 한 줄 패치 여부만 보지 않는다.

일부 보고서는 특정 이슈의 위험을 팀이 수용했다고 적는다. 그 전제가 운영 중 유지되는지 확인한다. 예를 들어 관리자 멀티시그를 전제로 등급을 낮췄다면 현재 owner와 threshold가 같은지 온체인에서 본다.

• 보고서 commit·파일 목록 추출
• 현재 프록시 구현과 배포 bytecode 대조
• 미해결·accepted·acknowledged 이슈 모으기
• 각 resolved 이슈의 fix commit·retest 확인
• 감사 이후 업그레이드·권한 변경 이력 확인

자동 도구와 수동 검토는 서로 대체하지 않는다

정적 분석기는 알려진 패턴과 데이터 흐름을 빠르게 찾지만 경제 설계, 복잡한 권한 의도, 외부 프로토콜 조합을 완전히 이해하지 못한다. 수동 검토도 시간과 범위에 제한되고 사람이 놓칠 수 있다. 퍼징·불변식 테스트·형식 검증·통합 테스트를 위험에 맞게 결합한다.

OWASP SCSVS Preface는 설계·구현·테스트 전반의 살아 있는 검증 기준을 지향하며 문서가 alpha임도 밝힌다. 표준 이름이나 도구 배지가 공식 인증을 뜻하는지 별도로 확인해야 한다.

감사 보고서는 안전 인증서가 아니라 특정 코드와 가정에서 수행한 제한된 검사의 기록이다.

JOBCOIN 해설

감사 밖 운영 위험을 이어서 본다

관리자 키, 타임록, 오라클 보고자, keeper, 프런트엔드 DNS, 배포 스크립트, 클라우드 비밀은 코드 감사 범위 밖일 수 있다. 계약이 안전해도 잘못된 파라미터 설정과 악성 업그레이드로 손실이 생길 수 있다.

버그바운티 규모와 범위, 모니터링·pause 절차, 사고 대응 연락처, 이전 사고의 사후 보고서를 확인한다. 높은 현상금 숫자만보다 실제 지급 정책과 제외 조건, 공개된 대응 기록이 중요하다.

감사 시점 뒤 의존 프로토콜이 바뀌거나 체인 업그레이드가 발생하면 가정이 달라질 수 있다. 현재 운영 구성의 위협 모델을 주기적으로 갱신한다.

보고서 한 편을 15분에 읽는 순서

먼저 날짜·commit·scope·제외 항목을 표로 옮긴다. Executive summary보다 발견 사항 목록에서 미해결과 accepted risk를 표시한다. 가장 높은 영향 이슈 하나를 열어 전제, 코드 위치, 재현, 수정 커밋을 읽는다.

그다음 현재 탐색기 구현·관리자·업그레이드 이벤트를 확인한다. 감사 커밋 이후 diff가 크면 보고서의 직접 적용 범위를 낮게 평가하고 후속 감사나 릴리스 보안 노트를 찾는다.

마지막으로 결론을 ‘안전/위험’ 이분법으로 쓰지 않는다. 확인된 범위, 남은 미검증 영역, 현재 코드 일치 여부, 공개된 미해결 이슈와 운영 권한을 분리해 기록한다.

자주 묻는 질문