커뮤니티 매니저가 보안감사보고서를 설명할 때 가장 중요한 것은 "감사를 받았다"는 사실보다 감사 범위, 발견사항의 심각도와 해결 상태, 감사 대상 코드 버전을 원문 그대로 전달하는 것입니다. 감사 완료를 안전 보장처럼 표현하거나 미해결 항목을 빼고 설명하면 커뮤니티의 신뢰를 잃고 법적 문제가 될 소지가 있습니다. 이 글에서는 공지를 쓰기 전에 확인할 항목, 등급별 표현 기준, 질문에 답하는 절차를 차례로 정리합니다.
커뮤니티 매니저는 보안감사보고서에서 무엇을 먼저 확인해야 하나요?
블록체인보안감사 보고서는 감사기관마다 형식이 다르지만, 대체로 개요, 감사 범위, 방법론, 발견사항, 결론과 면책 조항으로 이루어집니다. 커뮤니티 매니저가 기술 내용을 모두 이해할 필요는 없지만, 아래 항목은 공지를 작성하기 전에 반드시 확인해야 합니다.
- 감사 대상 저장소와 커밋 해시: 보고서가 어느 시점의 코드를 검토했는지 보여주는 기준점입니다.
- 대상 컨트랙트 목록: 토큰, 스테이킹, 브리지 등 서비스 전체가 아니라 일부 컨트랙트만 범위에 들어간 경우가 많습니다.
- 감사 기간과 보고서 버전: 초안, 수정본, 최종본 중 어느 것인지 확인합니다.
- 발견사항 수와 심각도 분포: 등급별 개수와 각 항목의 처리 상태를 따로 정리합니다.
- 면책 조항: 감사가 무엇을 보장하지 않는지 적힌 부분으로, 공지 표현의 한계를 정해 줍니다.
감사는 보안 활동의 한 시점일 뿐입니다. 미국 국립표준기술연구소(NIST)는 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)를 따르면 출시된 소프트웨어의 취약점 수를 줄이는 데 도움이 된다고 설명합니다. 이 관점을 공지에 담으면 감사 이후의 모니터링과 버그 제보 창구 운영까지 함께 설명할 근거가 생깁니다.
심각도 등급과 해결 상태는 어떻게 풀어서 설명해야 하나요?
스마트컨트랙트 감사의 심각도 등급은 각 감사기관이 정한 기준을 따르므로, 같은 "High"라도 기관마다 정의가 조금씩 다릅니다. 일반 소프트웨어 분야에서는 NIST가 운영하는 국가취약점데이터베이스(NVD)가 공통 취약점 점수 체계(CVSS)로 취약점 심각도를 점수와 등급으로 제공합니다. 다만 컨트랙트 감사 등급은 이와 별개의 체계인 경우가 많으므로, 공지에서는 해당 보고서에 적힌 정의를 그대로 인용하는 편이 정확합니다.
| 보고서 표기 | 일반적 의미 | 권장 설명 방식 | 피해야 할 표현 |
|---|---|---|---|
| Critical·High, 해결(Resolved) | 자산 손실로 이어질 수 있는 문제를 수정했고 감사기관이 다시 확인함 | 발견된 항목 수와 수정 사실, 재검토 여부를 함께 밝힘 | "치명적 문제 없음" |
| Medium, 인지(Acknowledged) | 팀이 문제를 인정했지만 설계상 이유 등으로 수정하지 않음 | 수정하지 않은 이유와 대체 통제 수단을 개발팀 확인을 거쳐 설명함 | "사소한 지적이라 무시해도 됨" |
| 부분 해결(Partially Resolved) | 일부만 수정했거나 남은 위험이 있음 | 남은 위험의 범위와 후속 조치 일정을 밝힘 | "해결 완료" |
| 미해결(Pending·Unresolved) | 보고서 발행 시점까지 조치되지 않음 | 항목명과 현재 진행 상황을 숨기지 않고 공개함 | 항목 자체를 공지에서 빼는 것 |
| Informational·가스 최적화 | 보안 위험보다는 코드 품질이나 비용 효율 관련 제안 | 위험도가 낮은 제안이라는 점을 짧게 설명함 | 개수를 합쳐 "발견사항 0건"으로 표기 |
등급별 개수만 나열하기보다 "높은 등급 항목 몇 건은 모두 수정 후 재검토를 받았고, 중간 등급 1건은 관리자 권한 구조와 관련되어 인지 상태로 남아 있다"처럼 상태까지 함께 적으면 투자자가 스스로 판단할 정보를 얻을 수 있습니다.
"감사 통과"라는 표현은 왜 조심해야 하나요?
감사는 특정 시점의 특정 코드를 검토한 결과입니다. 실제로 배포된 컨트랙트가 보고서의 커밋과 다르거나, 업그레이드 가능한 프록시 구조여서 배포 후 로직이 바뀔 수 있다면 보고서 결론은 현재 상태를 보장하지 못합니다. 그래서 "감사 통과", "해킹 불가", "검증된 안전 프로젝트" 같은 표현 대신 "어느 감사기관이 어느 버전의 어떤 컨트랙트를 검토했다"는 사실 문장으로 쓰는 것이 기본입니다.
표현의 문제는 법적 문제로도 이어질 수 있습니다. 금융위원회 소관 「가상자산 이용자 보호 등에 관한 법률」은 미공개중요정보 이용, 시세조종과 함께 부정거래 행위를 금지하며, 위반 시 형사처벌 또는 과징금이 부과됩니다. 보안 상태를 사실과 다르게 알리는 공지가 어디에 해당하는지는 사안마다 다르므로, 민감한 공지는 사전에 법률 전문가의 검토를 받기를 권합니다.
금융감독원도 가상자산거래소 사칭 가짜 체인 사기 등 가상자산 관련 사기에 대해 소비자경보를 발령하며 이용자에게 주의를 당부해 왔습니다. 커뮤니티 공지가 이런 과장 홍보와 비슷하게 보이지 않도록 수익이나 가격 전망과 보안 설명을 한 문장에 섞지 않는 것이 좋습니다.
투자자 질문에는 어떤 순서로 답하는 것이 좋을까요?
보고서가 공개되면 디스코드나 텔레그램에 질문이 한꺼번에 몰립니다. 답변 품질을 일정하게 유지하려면 다음 순서를 미리 정해 두는 것이 효과적입니다.
- 원문 위치 안내: 감사기관 공식 페이지에서 보고서 원본을 확인하는 방법을 고정 메시지로 안내합니다.
- 질문 분류: 범위 관련, 특정 발견사항 관련, 배포 주소 일치 여부, 감사 이후 변경 사항으로 나눕니다.
- 개발팀 확인: 기술적 판단이 필요한 질문은 커뮤니티 매니저가 추측해서 답하지 않고, 개발팀이 확인한 답변만 전달합니다.
- 답변 기록: 같은 질문에 다른 답이 나가지 않도록 확정 답변을 내부 문서에 남깁니다.
- FAQ 갱신: 반복되는 질문은 공지나 FAQ에 반영하고, 갱신 날짜를 적습니다.
위조 보고서도 주의해야 합니다. 검색창에 web3보안감사보고서를 입력하면 프로젝트 이름만 바꾼 PDF나 감사기관 로고를 무단으로 쓴 이미지가 함께 나오는 경우가 있습니다. 예를 들어 써틱처럼 프로젝트별 보고서와 평가 페이지를 공개하는 감사기관이라면, 커뮤니티에 돌고 있는 파일과 공식 페이지의 보고서 내용, 컨트랙트 주소가 일치하는지 대조하도록 안내하는 것이 좋습니다.
보안 사고나 취약점 제보가 들어오면 커뮤니티는 어떻게 대응해야 하나요?
보고서 공개 후 커뮤니티에서 취약점 제보나 이상 거래 의심 글이 올라올 수 있습니다. 이때 커뮤니티 매니저의 역할은 기술 판단이 아니라, 제보를 정해진 창구로 빠르게 넘기고 확인되지 않은 정보가 퍼지는 것을 막는 것입니다.
- 공개 채널에 올라온 구체적 공격 방법은 숨김 처리하고, 제보자에게 비공개 제보 경로를 안내합니다.
- 사실이 확인되기 전에는 "문제없음"이나 "해킹 발생" 같은 단정적 공지를 내지 않고, 확인 중이라는 사실과 다음 안내 시점만 알립니다.
- 개발팀, 법무 담당, 감사기관에 동시에 전달할 연락 체계를 미리 정해 둡니다.
- 사후 공지에는 영향 범위, 조치 내용, 재감사 여부를 포함합니다.
국내 이용자 피해가 의심되는 침해사고라면 공공 신고 창구도 함께 고려할 수 있습니다. 한국인터넷진흥원(KISA)은 보호나라 누리집을 통해 침해사고 신고를 접수하고 원인 분석과 대응 조치를 지원합니다.
자주 묻는 질문
보고서에 미해결 항목이 있으면 공지를 미뤄야 하나요?
반드시 미룰 필요는 없지만, 미해결 항목의 존재와 진행 상황을 공지에 함께 밝혀야 합니다. 항목을 숨긴 채 공개하면 나중에 투자자가 원문과 대조했을 때 신뢰가 크게 떨어집니다. 공개 시점은 개발팀, 감사기관과 협의해 정하는 것이 좋습니다.
감사기관이 여러 곳이면 결과를 어떻게 정리해야 하나요?
기관별로 감사 범위, 대상 커밋, 등급 체계가 다르므로 결과를 합산하지 말고 기관별로 나누어 정리하는 것이 정확합니다. 같은 문제를 두 기관이 서로 다른 등급으로 분류했다면 각 보고서의 표기를 그대로 인용합니다. 범위가 겹치지 않는 컨트랙트가 있다면 그 사실도 함께 밝힙니다.
보안 점수나 등급 이미지를 홍보물에 써도 되나요?
점수와 등급은 시점에 따라 바뀔 수 있으므로 기준 날짜와 원문 확인 경로를 함께 표시하는 것이 바람직합니다. 감사기관의 로고나 명칭 사용 조건은 계약이나 공식 가이드에 따라 다를 수 있으니 사전에 확인해야 합니다. 투자 판단을 직접 유도하는 문구와 함께 쓰는 것은 피하고, 표현에 법적 우려가 있다면 전문가와 상담하기를 권합니다.