스테이킹 보상 컨트랙트에서 감사 전에 개발자가 직접 막아야 할 취약점은 크게 다섯 가지입니다. 보상 계산 오류, 재진입, 권한 관리 결함, 외부 토큰 처리 오류, 업그레이드·초기화 결함입니다. 이 다섯 유형을 정해진 순서대로 점검하고 결과를 문서로 정리해 두면 외부 스마트컨트랙트감사가 핵심 로직 검증에 더 많은 시간을 쓸 수 있고, 수정과 재검토를 반복하는 횟수도 줄어듭니다.
스테이킹 컨트랙트에서 자주 발견되는 스마트컨트랙트취약점은 무엇입니까?
스테이킹 컨트랙트는 예치, 보상 누적, 인출, 긴급 출금처럼 자산이 움직이는 함수가 여럿이고 함수마다 상태 변수가 서로 얽혀 있습니다. 그래서 일반 토큰 컨트랙트보다 상태 불일치로 생기는 결함이 많습니다. 실무에서 자주 문제가 되는 유형은 다음과 같습니다.
- 보상 계산 오류: 누적 보상 지표(rewardPerToken 같은 값)를 갱신하지 않은 채 잔액을 바꾸면 보상이 과다 또는 과소 지급됩니다. 나눗셈을 곱셈보다 먼저 해 정밀도가 손실되는 경우도 흔합니다.
- 재진입: 외부 호출을 먼저 하고 상태를 나중에 갱신하면 인출 함수가 여러 번 실행될 수 있습니다. 콜백 기능이 있는 토큰 표준을 받는 경우 위험이 더 커집니다.
- 권한 관리 결함: 보상률 변경, 풀 추가, 자금 회수 같은 관리자 함수에 접근 제어가 빠졌거나 단일 키 하나에 모든 권한이 몰려 있는 경우입니다.
- 외부 토큰 처리 오류: 전송 수수료가 붙는 토큰이나 반환값이 없는 토큰을 그대로 받으면 기록된 예치액과 실제 잔액이 달라집니다.
- 업그레이드·초기화 결함: 프록시 구조에서 초기화 함수를 아무나 호출할 수 있거나, 버전을 올리면서 저장소 슬롯 배치가 바뀌어 기존 데이터가 손상되는 경우입니다.
유형별 정의와 실제 사례를 더 보고 싶다면 감사 절차를 소개한 스마트컨트랙트취약점 관련 설명 자료를 함께 읽는 것이 좋습니다. 감사 기관이 어떤 순서로 코드를 보는지 알면 사전 점검의 우선순위를 정하기가 쉬워집니다.
감사 제출 전에 개발자는 어떤 순서로 점검해야 합니까?
점검 순서는 자산 손실로 바로 이어지는 결함부터 운영상 위험 순으로 잡습니다. 아래 절차는 소규모 팀도 한두 번의 내부 검토 주기 안에 끝낼 수 있도록 구성했습니다.
- 자금이 들어오고 나가는 함수를 모두 나열하고, 함수마다 바뀌는 상태 변수를 표로 정리합니다.
- 모든 외부 호출 지점에 '검사-효과-상호작용' 순서가 지켜졌는지 확인하고, 필요한 곳에 재진입 방지 장치를 적용합니다.
- 관리자 함수 목록을 만들고 역할별 권한, 시간 지연(타임락), 다중 서명 적용 여부를 기록합니다.
- 보상 계산식은 손으로 계산한 기대값과 테스트 결과를 비교합니다. 예치 직후 인출, 보상률 변경 직후 인출 같은 경계 사례도 함께 확인합니다.
- 정적 분석 도구와 퍼징 테스트를 돌리고, 경고마다 '수정함', '오탐으로 판단', '의도된 설계' 가운데 하나로 분류합니다.
- 프록시를 쓴다면 초기화 보호 여부와 저장소 배치 호환성을 점검합니다.
| 점검 영역 | 확인 기준 | 남길 증빙 |
|---|---|---|
| 보상 계산 | 잔액을 바꾸기 전에 누적 지표를 갱신하는지, 정밀도 손실이 없는지 | 경계 사례 단위 테스트, 계산식 설명 문서 |
| 재진입 | 외부 호출 전에 상태 갱신을 마쳤는지, 방지 장치를 적용했는지 | 함수별 호출 흐름도, 공격 시나리오 테스트 |
| 권한 관리 | 관리자 함수마다 역할이 분리되고 타임락·다중 서명이 있는지 | 권한 매트릭스, 키 보관 정책 |
| 외부 토큰 | 실제 수령액 기준으로 기록하는지, 안전한 전송 래퍼를 쓰는지 | 수수료 토큰·비표준 토큰 테스트 결과 |
| 업그레이드 | 초기화가 한 번만 되도록 막혀 있는지, 저장소 배치가 호환되는지 | 저장소 배치 비교 결과, 배포 스크립트 |
스마트컨트랙트보안 기준은 어떤 공식 자료를 참고하면 됩니까?
스마트컨트랙트보안만 다루는 국가 표준은 아직 정리 단계에 있습니다. 대신 블록체인과 소프트웨어 보안에 관한 공공기관 자료를 기준으로 삼을 수 있습니다. 미국 국립표준기술연구소(NIST)는 보고서 NISTIR 8202에서 스마트컨트랙트를 블록체인에 배포되어 트랜잭션으로 실행되는 코드와 데이터의 모음으로 설명합니다. 이 정의를 따르면 배포된 코드가 곧 자산 관리 규칙이 되므로, 배포 전 검증이 특히 중요합니다.
개발 절차에는 NIST의 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)를 참고할 수 있습니다. 이 프레임워크는 보안 활동을 조직 준비, 소프트웨어 보호, 안전한 소프트웨어 생산, 취약점 대응의 네 그룹으로 나눕니다. 앞에서 정리한 사전 점검 절차는 이 가운데 '안전한 소프트웨어 생산' 단계에 해당합니다.
미국 사이버보안·인프라보안청(CISA)은 '설계 단계부터의 보안(Secure by Design)' 원칙을 통해 소프트웨어 제조사가 고객의 보안 결과에 책임을 지도록 권고합니다. 스테이킹 서비스에서는 이 원칙을 안전한 기본 설정, 관리자 권한 최소화, 투명한 취약점 공개 정책으로 옮겨 적용할 수 있습니다.
국내에서는 한국인터넷진흥원(KISA)이 소프트웨어 보안 취약점 신고 포상제를 운영하며, 외부 연구자의 취약점 제보를 받는 체계를 갖추고 있습니다. 프로젝트도 배포 후 취약점 제보 창구와 처리 절차를 미리 정해 두면 감사 이후의 대응 체계를 갖출 수 있습니다.
스마트컨트랙트감사를 맡길 때 사전 점검 결과는 어떻게 전달해야 합니까?
감사 기관에 코드 저장소 링크만 넘기면 감사인은 설계 의도를 파악하는 데부터 시간을 씁니다. 사전 점검 결과를 다음 형식으로 묶어 전달하면 감사 범위와 일정을 더 정확하게 합의할 수 있습니다.
- 범위 문서: 감사할 커밋 해시, 대상 파일 목록, 범위에서 뺀 외부 의존성을 적습니다.
- 설계 설명서: 보상 계산식, 역할별 권한, 업그레이드 정책을 한 문서에 정리합니다.
- 알려진 이슈 목록: 의도된 설계로 판단한 경고와 그 근거를 적어 두면 같은 지적이 반복되지 않습니다.
- 테스트 현황: 테스트 커버리지 결과와 퍼징 설정을 공유합니다.
감사 기관을 고를 때는 공개된 감사보고서의 형식, 발견사항 등급 기준, 재검토 절차를 비교하는 것이 좋습니다. 써틱처럼 감사 절차와 보고서 구성을 공개적으로 설명하는 기관의 자료를 참고하면 견적 요청서에 어떤 항목을 넣어야 할지 판단하는 데 도움이 됩니다. 감사가 끝난 뒤에는 발견사항마다 수정 커밋을 연결하고, 수정 내용에 대한 재검토까지 마쳐야 감사가 끝났다고 볼 수 있습니다.
스테이킹 서비스가 이용자 자산을 맡아 관리하는 구조라면 금융위원회가 소관하는 가상자산이용자보호법 등 관련 규제의 적용 여부도 검토해야 합니다. 적용 범위는 서비스 구조에 따라 달라지므로 법률 전문가와 상담하시기 바랍니다.
자주 묻는 질문
정적 분석 도구에서 경고가 나오지 않으면 감사를 생략해도 됩니까?
생략하지 않는 것이 좋습니다. 정적 분석 도구는 알려진 패턴을 찾는 데는 효과적이지만, 보상 계산식의 논리 오류나 경제적 공격 시나리오는 잘 찾지 못합니다. 도구 결과는 감사의 사전 자료로 쓰고, 핵심 로직은 사람이 검토하도록 해야 합니다.
감사를 받은 뒤 코드를 조금만 고쳐도 다시 감사를 받아야 합니까?
수정 범위가 자금 흐름, 권한, 보상 계산에 닿는다면 해당 부분은 재검토를 받는 것이 바람직합니다. 주석이나 이벤트 이름만 바꾼 경우처럼 실행 로직과 무관한 변경은 감사 기관과 협의해 간이 확인으로 대신할 수 있습니다. 어느 경우든 감사보고서에 적힌 커밋 해시와 실제 배포 코드가 같은지는 반드시 확인해야 합니다.
소규모 팀은 사전 점검에 시간을 얼마나 써야 합니까?
정해진 기준 시간은 없습니다. 위 표의 다섯 영역마다 증빙을 하나 이상 남기는 것을 완료 기준으로 삼는 것이 현실적입니다. 증빙을 남기기 어려운 영역이 있다면 그 영역을 감사 기관에 집중 검토 대상으로 요청하는 방법이 있습니다.