보안 감사 후 조치에서는 발견 건수보다 각 지적의 상태와 수정 근거를 확인해야 합니다. 해결, 부분 해결, 위험 수용은 같은 결과가 아닙니다. 감사 항목의 식별자에서 수정 커밋, 감사자의 재검토 설명, 실제 배포 버전까지 연결하고, 남은 조건과 감사 범위 밖의 부분을 별도로 기록합니다.
요약표의 해결 숫자부터 결론 내리지 않습니다
감사 보고서의 전체 지적 수는 검토 범위, 기간, 분류 방식과 코드의 규모에 영향을 받습니다. 어떤 보고서는 문서 개선까지 세고 다른 보고서는 보안 취약점만 요약할 수 있습니다. 숫자가 적다는 이유로 한 프로젝트를 다른 프로젝트보다 안전하다고 서열화하면 비교 조건을 빠뜨리게 됩니다.
OpenZeppelin의 2025년 5월 15일 EVM Emulator and Semi-abstracted Nonces Update Audit은 총 17개 항목 중 해결 15개, 부분 해결 1개를 표시합니다. 이 과거 사례에서 살펴볼 점은 점수 자체보다 각 항목 아래에 수정 상태와 근거가 이어진다는 구조입니다. 현재 배포의 안전성을 새로 평가한 결과로 인용하는 자료는 아닙니다.
해결률은 읽기 시작하는 색인이고, 남은 위험을 설명하는 결론은 항목별 기록에 있습니다.
JOBCOIN 검토 메모
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 요약표의 해결 숫자부터 결론 내리지 않습니다
감사 보고서의 전체 지적 수는 검토 범위, 기간, 분류 방식과 코드의 규모에 영향을 받습니다.
- 해결, 부분 해결, 수용은 다른 상태입니다
일반적으로 해결은 지적에 대한 수정이 반영됐다는 보고서의 판정입니다.
- 부분 해결의 이유를 읽으면 숫자의 의미가 달라집니다
앞의 EVM 감사 사례에서 인터페이스와 구현의 불일치 항목은 부분 해결로 표시됐습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
해결, 부분 해결, 수용은 다른 상태입니다
일반적으로 해결은 지적에 대한 수정이 반영됐다는 보고서의 판정입니다. 부분 해결은 권고 가운데 일부만 처리됐다는 뜻일 수 있습니다. 수용은 팀이 문제 또는 설계상 선택을 인지하면서 변경하지 않기로 했다는 기록일 수 있으므로, 단어만 보고 제거된 위험으로 합산하면 안 됩니다.
보고서마다 상태 정의와 검토 방식이 다를 수 있어 먼저 해당 문서의 설명을 읽습니다. 해결 표시가 있더라도 그 판단이 어느 커밋과 조건을 대상으로 하는지 찾아야 합니다. 같은 제목의 후속 보고서나 수정본이 있다면 문서 발행일과 업데이트 이력을 구분합니다.
| 표시 상태 | 확인할 근거 | 독자가 남길 질문 |
|---|---|---|
| 해결 | 수정 커밋과 재검토 문장 | 운영에 같은 수정이 반영됐는가 |
| 부분 해결 | 반영된 권고와 남은 권고 | 미반영 부분은 어떤 조건에서 중요한가 |
| 수용·미해결 | 팀의 이유와 감사자 설명 | 운영 통제나 사용자 제약이 있는가 |
| 범위 외 | 제외된 파일·의존성·가정 | 다른 감사 또는 검증 자료가 있는가 |
부분 해결의 이유를 읽으면 숫자의 의미가 달라집니다
앞의 EVM 감사 사례에서 인터페이스와 구현의 불일치 항목은 부분 해결로 표시됐습니다. 원문은 일부 인터페이스·문서 수정을 반영했지만 함수 선언 순서의 정렬은 병합 충돌과 가독성 개선의 균형을 이유로 남겼다는 팀 설명을 담고 있습니다. 부분 해결이라는 한 단어만으로 모든 미반영 사항의 심각도가 같다고 말할 수 없는 이유입니다.
같은 보고서의 상태 변경 이벤트 관련 권고에는 수용하되 해결하지 않았다는 기록이 있습니다. 두 사례는 상태 판정의 차이를 보여 주기 위해 인용한 것이며 독자가 기술적 위험을 독자적으로 재평가했다고 주장하는 것은 아닙니다. 보고서에 적힌 이유와 실제 운영에 요구되는 조건을 분리해서 읽어야 합니다.
가상 사례로 출금 함수의 접근 제한을 수정했지만 관리 키 보호는 운영 절차에 맡겼다고 해 보겠습니다. 코드 수정의 완료와 키 보관 통제의 적정성은 각각 다른 질문입니다. ‘수정됨’이라는 표시 하나가 프로젝트가 가진 모든 운영 위험을 제거했다는 문장으로 바뀌어서는 안 됩니다.
커밋과 시험 결과를 하나의 지적으로 연결합니다
조치 보고서를 읽는 순서는 지적 ID, 문제를 재현하는 조건, 수정된 위치, 재검토 설명입니다. 수정 커밋이 여러 개라면 어떤 커밋이 핵심 조건을 바꾸고 어떤 커밋이 문서나 시험만 보완했는지 구분합니다. 코드 링크가 있다는 사실과 그 변경이 문제를 해결한다는 판정은 서로 다른 근거입니다.
시험 통과 보고에는 시험한 환경과 실패 조건이 함께 있어야 해석할 수 있습니다. 정상 입출금만 통과한 시험이 권한 없는 호출, 경계값, 순서가 뒤바뀐 호출까지 확인했다고 볼 수는 없습니다. 독자는 전체 소스를 직접 감사하지 않더라도 조치 내역이 원래 지적 조건을 다시 다뤘는지 확인할 수 있습니다.
업그레이드 계약이라면 초기화와 기존 상태의 호환성도 읽어야 합니다. OpenZeppelin의 업그레이드 문서는 초기화 누락과 저장소 배치 변경이 별도의 문제를 만들 수 있음을 설명합니다. 저장소 배치 해설을 함께 보면 새 코드만 정상 작동하는 시험이 기존 운영 상태의 이전까지 증명하지는 않는다는 점을 이해하기 쉽습니다.
감사 결과와 운영 배포 사이의 연결을 확인합니다
감사자가 수정본을 검토한 뒤에도 프로젝트가 다른 빌드 설정이나 후속 커밋을 배포할 수 있습니다. 조치가 끝났다는 공지에서는 감사 대상 버전과 운영 계약 주소를 연결하는 배포 설명을 찾습니다. 프록시를 사용한다면 사용자에게 보이는 주소가 같아도 실제 구현은 바뀔 수 있습니다.
이 단계에서 독자가 확인하지 않은 사실을 ‘온체인 검증 완료’로 쓰면 안 됩니다. 탐색기에서 코드가 공개됐다는 표시, 프로젝트의 배포 공지, 감사자의 검토 범위는 각자 말하는 내용이 다릅니다. 프록시 구현 주소 변경의 확인 기준을 참고해 주소·네트워크·시각을 일치시킨 뒤 근거의 범위를 기록합니다.
- 원본 감사 문서의 기간·대상 저장소·기준 커밋을 저장합니다.
- 각 지적의 상태와 수정 커밋을 같은 행에 적습니다.
- 부분 해결 및 수용 항목의 남은 조건을 요약합니다.
- 재검토가 원래 실패 조건을 포함했는지 확인합니다.
- 감사한 수정본과 실제 배포 버전의 연결 자료를 찾습니다.
미해결 항목을 숨기지 않는 요약을 만듭니다
독자를 위한 요약에는 주요 수정 내용과 함께 미해결 항목, 팀의 수용 이유, 범위 밖 가정을 담습니다. 예를 들어 ‘특정 함수의 접근 제한을 보완했고 재검토 기록이 공개됐으나 운영 배포 버전의 일치는 별도 확인이 필요하다’처럼 확인과 미확인을 함께 쓰면 후속 공지에서 무엇을 찾아야 하는지 분명해집니다.
감사는 특정 기간과 범위의 검토이며 미래의 모든 결함을 없애는 보증이 아닙니다. 그렇다고 해결 기록의 가치가 없는 것도 아닙니다. 어떤 조건이 발견됐고 어떻게 수정됐는지를 추적할 수 있다는 점이 핵심입니다. 취약점 수를 홍보 점수로 바꾸기보다 재현 가능한 조치 이력을 읽는 자료로 사용합니다.
자주 묻는 질문
모든 항목이 해결이면 더 읽을 필요가 없나요?
대상 커밋과 배포 버전, 감사 범위와 운영 가정은 여전히 확인해야 합니다. 해결 표시는 그 보고서가 다룬 지적에 대한 상태이며 시스템 전체의 무결함을 뜻하지 않습니다.
위험 수용은 감사자가 안전하다고 승인한 것인가요?
그렇게 해석할 수 없습니다. 팀의 선택과 감사자의 평가가 어떻게 기록됐는지 읽어야 하며 변경하지 않은 이유와 남은 운영 조건을 별도로 남겨야 합니다.
여러 업체의 감사 지적 수를 합치면 품질 점수가 되나요?
범위와 분류가 달라 단순 합산은 부적절합니다. 같은 문제의 중복 지적도 있을 수 있어 대상 버전과 항목의 실질 내용을 먼저 대조해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
