파트너십 제안을 받은 사업개발 담당자는 상대 프로젝트의 보안스코어를 출발점으로 삼되, 점수 하나만으로 판단해서는 안 됩니다. 블록체인보안감사 보고서의 범위, 발견사항 해결 상태, 실제 배포 코드와의 일치 여부를 차례로 확인해야 합니다. 점수는 현재 상태를 요약한 지표이고 감사보고서는 특정 시점의 특정 코드를 검토한 기록이므로, 두 자료가 서로 맞물리는지 확인하는 것이 검토의 핵심입니다.
사업개발 담당자가 상대 프로젝트의 보안까지 확인해야 하는 이유는 무엇입니까?
웹3 분야의 파트너십은 공동 마케팅에 그치지 않고 토큰 상호 연동, 유동성 공급, 브리지 연결, 지갑 통합처럼 기술적으로 결합하는 경우가 많습니다. 이때 상대 프로젝트의 스마트컨트랙트에 취약점이 있으면 자사 이용자의 자산과 평판까지 함께 위험에 노출됩니다. 따라서 협업 검토 단계에서 보안 상태를 확인하는 일은 기술팀만의 업무가 아니라 계약을 주도하는 사업개발 담당자의 기본 실사 항목에 포함됩니다.
미국 국립표준기술연구소(NIST)가 발표한 사이버보안 프레임워크 2.0은 식별·보호·탐지·대응·복구의 기존 다섯 기능에 거버넌스(Govern)를 더해 여섯 가지 핵심 기능으로 구성됩니다. 외부 프로젝트와의 기술 연동은 사실상 공급망을 확장하는 일이므로, 파트너의 보안 수준을 조직 차원의 위험으로 관리할 필요가 있습니다.
보안스코어는 무엇을 보여주고 무엇을 보여주지 않습니까?
보안스코어는 여러 범주의 공개 정보를 종합해 프로젝트의 보안 상태를 요약한 지표입니다. 여러 프로젝트를 빠르게 비교하거나 시간에 따른 변화를 추적할 때 유용하며, 사업개발 담당자가 1차로 걸러낼 대상을 정하는 데 도움이 됩니다.
반면 점수는 개별 함수의 논리 오류나 특정 연동 방식에서 생기는 위험까지 설명하지는 않습니다. 감사 이후 업그레이드된 코드, 아직 공개되지 않은 관리자 권한 변경, 자사와의 연동에서만 나타나는 위험은 점수에 바로 반영되지 않을 수 있습니다. 따라서 점수가 높으면 검토를 끝내는 것이 아니라, 감사보고서를 확인하는 단계로 넘어가는 신호로 받아들이는 것이 적절합니다.
블록체인보안감사프로세스는 어떤 단계로 진행됩니까?
감사보고서를 제대로 읽으려면 그 보고서가 어떤 절차를 거쳐 만들어졌는지 알아야 합니다. 일반적인 블록체인보안감사프로세스와 단계별 확인 포인트는 다음과 같습니다.
| 단계 | 주요 활동 | 사업개발 담당자 확인 포인트 |
|---|---|---|
| 범위 확정 | 감사 대상 저장소, 커밋 해시, 컨트랙트 목록 확정 | 자사와 연동할 컨트랙트가 범위에 포함되어 있는지 |
| 자동 분석 | 정적 분석 도구로 알려진 취약 패턴 탐지 | 도구 분석만으로 끝난 감사인지, 수동 검토가 뒤따랐는지 |
| 수동 검토 | 감사인이 비즈니스 로직, 권한 구조, 경제 모델 검토 | 관리자 권한, 업그레이드 권한, 오라클 의존성 관련 지적 여부 |
| 발견사항 분류 | 심각도(치명·높음·중간·낮음·정보)별로 정리 | 높은 심각도 항목의 개수와 내용 |
| 수정·재검토 | 프로젝트 팀이 수정하고 감사인이 다시 확인 | 해결, 부분 해결, 위험 인지(수용) 등 상태 표기 |
| 최종 보고서 공개 | 최종 커밋 기준 보고서 발행 | 보고서의 커밋과 실제 배포 코드의 일치 여부 |
표에서 가장 자주 놓치는 항목은 범위와 배포 코드의 일치 여부입니다. 감사가 완료되었다는 사실보다, 자사가 연결할 바로 그 코드가 감사를 받았는지가 더 중요합니다.
점수와 감사보고서는 어떤 순서로 교차 확인해야 합니까?
기술 배경이 깊지 않더라도 아래 순서를 따르면 확인할 질문 목록을 체계적으로 만들 수 있습니다.
- 점수와 추이 확인: 현재 점수뿐 아니라 최근 몇 달간 급격한 하락이 있었는지 확인하고, 하락했다면 어느 범주에서 하락했는지 기록합니다.
- 감사 이력 목록화: 감사 기관, 감사 일자, 대상 컨트랙트, 보고서 버전을 표로 정리합니다.
- 범위 대조: 연동 예정 컨트랙트 주소를 상대 팀에 요청하고, 보고서의 감사 범위와 대조합니다.
- 미해결 항목 검토: 높은 심각도 이상의 항목 가운데 해결되지 않았거나 위험 수용으로 처리된 항목이 있는지 확인하고, 그 사유를 서면으로 요청합니다.
- 배포 이후 변경 확인: 감사 이후 업그레이드나 권한 이전이 있었는지 상대 팀에 확인하고, 있었다면 재감사 여부를 묻습니다.
- 자사 기술팀 검토 요청: 위 결과를 정리해 자사 개발·보안 담당자에게 연동 위험 검토를 요청합니다.
국내 사업자라면 규제 환경도 함께 고려해야 합니다. 금융위원회 소관의 「가상자산 이용자 보호 등에 관한 법률」은 2024년 7월 19일부터 시행되었으며 시세조종 등 불공정거래행위에 대한 조사 및 처벌 근거를 마련했습니다. 협업 형태에 따라 적용 여부가 달라질 수 있으므로, 구체적인 판단은 법률 전문가와 상담하는 것이 바람직합니다.
확인 결과는 협업 조건에 어떻게 반영합니까?
검토 결과는 단순히 진행 여부를 결정하는 데 그치지 않고, 계약 조건과 연동 방식에 구체적으로 반영되어야 합니다. 대표적인 반영 방법은 다음과 같습니다.
- 미해결 항목이 있으면 해결 및 재검토 완료를 연동 개시의 선행 조건으로 둡니다.
- 연동 초기에는 예치 한도나 거래 한도를 낮게 설정하고 단계적으로 늘립니다.
- 컨트랙트 업그레이드나 관리자 권한 변경 시 사전 통지 의무를 계약에 넣습니다.
- 보안 사고 발생 시 연락 창구, 대응 절차, 연동 중단 권한을 미리 합의합니다.
위험 수준에 비례해 관리 강도를 정하는 위험기반 접근법은 자금세탁방지 분야 등에서 널리 쓰이는 일반 원칙입니다. 파트너 보안 검토에도 같은 원칙을 적용해, 연동 규모가 크고 자산 이동이 많을수록 확인 항목과 계약 조건을 더 엄격하게 설정하는 것이 합리적입니다.
자사 내부의 보안 관리 수준도 함께 점검해야 합니다. 개인정보보호위원회가 안내하는 정보보호 및 개인정보보호 관리체계(ISMS-P) 인증 제도는 관리체계 수립 및 운영, 보호대책 요구사항, 개인정보 처리 단계별 요구사항으로 인증 기준을 구분합니다. 외부 협력사 관리 역시 이러한 관리체계의 일부로 다룰 수 있으므로, 파트너 검토 기록을 문서로 남겨 두면 내부 감사나 인증 심사 대응에도 활용할 수 있습니다. 점수 산정 범주나 보고서 표기 방식이 불분명할 때에는 써틱처럼 해당 점수와 보고서를 발행한 기관에 직접 문의해 의미를 확인하는 것이 정확합니다.
자주 묻는 질문
보안스코어가 높으면 감사보고서를 따로 확인하지 않아도 됩니까?
그렇지 않습니다. 점수는 여러 범주를 종합한 요약 지표이므로, 자사와 연동할 특정 컨트랙트가 감사 범위에 포함되었는지는 보고서에서 별도로 확인해야 합니다. 점수는 검토의 출발점으로 활용하는 것이 적절합니다.
감사보고서에 위험 인지로 표기된 항목은 문제가 없다는 뜻인가요?
위험 인지는 프로젝트 팀이 지적 사항을 확인했으나 수정하지 않고 위험을 수용했다는 의미입니다. 수용 사유가 타당한지, 자사 연동에 영향을 주는지 상대 팀에 서면으로 확인하는 것이 좋습니다.
감사 이후 컨트랙트가 업그레이드되었다면 어떻게 해야 합니까?
업그레이드된 코드는 기존 감사 범위에 포함되지 않았을 수 있으므로 재감사 여부와 변경 내역을 요청해야 합니다. 재감사가 진행되지 않았다면 연동 한도를 낮추거나 재감사 완료를 협업 조건으로 두는 방안을 검토합니다. 법적·재무적 판단이 필요한 경우에는 해당 분야 전문가와 상담하는 것을 권합니다.