암호화폐 프로젝트의 스마트 계약을 감사하는 단계별 가이드

스마트 계약 감사는 계약이 실패하거나 오용되거나 사용자가 예상치 못한 방식으로 제어될 수 있는 가능성을 체계적으로 파악하기 위한 시도입니다. 단순히 스캐너를 실행하거나 감사 배지를 읽거나 소스 코드 검증 여부를 확인하는 것과는 다릅니다. 아래 워크플로를 사용하여 배포된 EVM 계약 또는 코드베이스를 검토한 후 중요한 자금을 관리하십시오.

중요: 본 가이드는 실용적인 검토 프레임워크이며, 프로젝트의 안전성을 보장하거나 투자 조언을 제공하는 것이 아닙니다. 상당한 가치를 지닌 운영 프로토콜은 경험이 풍부한 보안 전문가의 독립적인 검토를 받아야 합니다. 본 가이드의 인터페이스 스타일 이미지는 예시일 뿐이며 특정 프로젝트 또는 배포에 대한 증거로 간주해서는 안 됩니다.

감사 체크리스트 요약

1단계: 범위 및 배포된 산출물을 확인합니다.

정확한 체인과 주소부터 시작하세요. 배포 주소, 트랜잭션 해시, 블록 번호, 컴파일러 버전, 최적화 설정, 생성자 인자, 그리고 팀에서 배포되었다고 밝힌 커밋 또는 릴리스를 기록하십시오. 프로젝트에는 토큰, 라우터, 볼트, 프록시, 구현, 오라클 또는 테스트 배포를 위한 여러 주소가 있을 수 있습니다. 잘못된 주소를 검토하는 것은 실질적인 가치가 없습니다.

탐색기에서 검증된 소스 코드가 배포된 바이트코드와 일치하는지 확인하십시오. 검증은 소스 코드와 ABI를 검사할 수 있게 해주므로 유용하지만, 단순히 신원 확인일 뿐 비즈니스 로직의 안전성을 보장하는 것은 아닙니다. 계약이 업그레이드 가능한 경우, 프록시와 현재 구현체를 모두 식별하십시오. 프록시의 문서화된 메커니즘 또는 탐색기 정보에서 구현체 주소를 읽어온 다음, 해당 구현체가 검토하려는 구현체인지 확인하십시오. Etherscan의 공식 Foundry 검증 가이드에는 신규 및 기존 계약에 대한 검증 방법이 자세히 설명되어 있습니다.

또한 검토 범위를 명확히 정의하십시오. 가져온 라이브러리, 상속된 컨트랙트, 연결된 라이브러리, 배포된 헬퍼 컨트랙트, 오라클 어댑터, 사용자로부터 받은 토큰, 그리고 권한이 부여된 오프체인 구성 요소를 포함해야 합니다. 검토 범위에서 제외되는 항목과 그 이유를 명시하십시오. 이렇게 하면 좁은 범위의 검토가 전체 시스템에 대한 검토로 오해되는 것을 방지할 수 있습니다.

2단계: 진입점 및 자산 맵 구축

상속된 함수, 대체 함수 또는 수신 핸들러를 포함하여 모든 공개 함수와 외부 함수를 나열하십시오. 각 함수에 대해 다음 사항을 기록하십시오.

• 현지 통화 또는 토큰을 이동시키세요.
• 주조, 소각, 차용, 청산 또는 회계 변경;
• 오라클, 수수료, 한도, 역할, 일시 중지 상태 또는 구현을 변경합니다.
• 외부 호출, 위임 호출 또는 하위 레벨 호출을 수행합니다.
• 다른 상태 변경 함수가 의존하는 데이터를 읽습니다.

다음으로 자산과 신뢰 경계를 매핑합니다. 사용자의 입금이 저장소에 저장되는 과정부터 가격 책정 및 지분 계산을 거쳐 출금에 이르기까지의 모든 경로를 추적합니다. 호출자가 제공한 모든 주소와 저장소에서 불러온 모든 주소를 식별합니다. 어떤 값이 정직한 것으로 간주되는지 질문합니다. 오라클, 토큰, 브리지 메시지, 키퍼, 콜백 수신자 또는 관리자 중 어떤 값이 정직한 것으로 간주되는지 확인합니다. 가장 중요한 검토 대상은 사용자 제어 입력, 특권 상태, 산술 연산 및 외부 호출이 결합된 기능입니다.

3단계: 컴파일이 정상적으로 완료되고 정적 분석이 실행됩니다.

명시된 Solidity 버전, 종속성 버전, 최적화 프로그램 구성 및 대상 체인 가정을 사용하여 프로젝트 빌드를 재현하십시오. 컴파일러 경고는 무해한 노이즈가 아니라 검토 항목으로 간주하십시오. Solidity의 보안 고려 사항에서는 경고를 심각하게 받아들이고, 계약을 이해하기 쉽게 유지하며, 알려진 컴파일러 문제를 확인하는 것을 권장합니다. 컴파일러 버전이나 영향을 받는 코드 패턴에 따라 관련성이 있는 경우, 알려진 Solidity 컴파일러 버그의 공식 목록을 참조하십시오 .

Hardhat, Foundry 또는 유사한 프로젝트의 경우 프로젝트 루트에서 Slither를 실행하세요. 공식 문서에서는 이 도구를 Solidity 및 Vyper 정적 분석기로 설명하며 일반적인 명령어를 제공합니다.

slither .

출력 결과를 저장하고 영향력과 신뢰도에 따라 각 결과를 분류하세요. 임의 토큰 전송, 보호되지 않은 업그레이드, 재진입, 검증되지 않은 반환 값, 위험한 delegatecall, tx.origin, 약한 난수성, 잘못된 인터페이스와 관련된 발견 사항을 특히 주의 깊게 살펴보세요. 탐지기는 오탐을 보고하거나, 프로젝트별 경제적 결함을 놓치거나, 다른 곳에서 의도적으로 제한된 코드를 플래그할 수 있습니다. 정적 분석은 검색 범위를 좁혀주지만, 수동 검토를 대체하는 것은 아닙니다. Slither 저장소와 문서에는 검토를 체계화하는 데 도움이 되는 진입점, 권한 부여, 호출 그래프 및 계약 요약을 출력할 수 있는 프린터 목록도 있습니다.

4단계: 외부 호출 및 재진입을 수동으로 추적합니다.

외부 호출이 발생할 때마다 호출 전, 호출 중, 호출 후 상태를 추적하십시오. 호출 대상은 악의적인 컨트랙트, 후크가 있는 토큰, 콜백 수신자 또는 공유 종속성을 변경하는 다른 프로토콜일 수 있습니다. Solidity 문서에서는 다른 컨트랙트와의 상호 작용으로 인해 해당 컨트랙트에 제어권이 넘어갈 수 있다고 설명하며, 검증-효과-상호 작용 패턴(먼저 유효성을 검사하고, 두 번째로 이 컨트랙트의 상태를 업데이트하고, 마지막으로 외부와 상호 작용)을 권장합니다.

명백한 이더리움 전송에만 검색 범위를 한정하지 마십시오. ERC-777 스타일 후크, ERC-1155 콜백, 플래시론 콜백, 임의의 라우터, 오라클 호출, 그리고 상속된 라이브러리를 통한 호출까지 확인하십시오. 함수 간 및 계약 간 재진입 가능성을 검토하십시오. 콜백이 중간 상태를 읽는 다른 함수로 진입할 수 있습니다. 모든 하위 수준 호출이 성공 결과를 확인하고 반환 값을 올바르게 처리하는지 확인하십시오. 수신자가 실패할 경우 인출이나 무한 루프를 영구적으로 차단할 수 있는지 여부를 검토하십시오.

발생 가능한 모든 문제에 대해 구체적인 공격 순서를 기록하십시오. 예를 들어, 공격자가 입금하고, 출금을 시작하고, 콜백을 받고, 두 번째 출금을 다시 시도한 후에야 첫 번째 호출이 완료되도록 하는 등의 순서를 기록합니다. 특정 불변 조건이나 보호 장치 때문에 해당 순서를 실행할 수 없는 경우, 그 이유를 기록하십시오. 이렇게 하면 결론이 추측에 그치지 않고 검증 가능해집니다.

5단계: 산술 및 비즈니스 불변 조건 테스트

모든 단위와 변환의 의미를 확인하세요. 웨이(wei)와 이더(ether)의 차이, 토큰 소수점 자릿수, 베이시스 포인트(basis points), 주식과 자산, 부호 있는 값, 시간 단위 등을 정확히 이해해야 합니다. 반올림 방향을 반드시 준수하세요. 예금자, 차용자, 청산자 또는 수수료 수령자에게 유리하게 반올림되는 나눗셈 연산은 반복될 경우 가치 손실을 초래할 수 있습니다. 나눗셈 전에 곱셈을 해야 하는지, 최소 및 최대 금액, 수수료 상한선, 오래된 가격, 공급량 0, 잔액 0, 최초 예금자 또는 마지막 인출자 등을 반드시 확인하세요.

Solidity 0.8 이상 버전은 일반적으로 산술 오버플로 및 언더플로를 감지하지만, unchecked블록 내부의 코드가 의도적으로 해당 동작을 변경하는 경우도 있습니다. 검사된 산술 연산은 제한이 제대로 설계되지 않으면 프로토콜을 원래대로 되돌리거나 사용할 수 없게 만들 수도 있습니다. 따라서 두 가지 결과, 즉 데이터 도용이나 잘못된 회계 처리, 그리고 처리 불가능한 값으로 인한 서비스 거부 공격을 모두 테스트해야 합니다.

테스트로 변환하기 전에 불변 조건을 명확한 언어로 작성하세요. 예를 들어, "총 주식 수는 명시된 반올림 규칙에 따른 자산과 일치한다", "사용자는 기록된 청구량보다 더 많이 인출할 수 없다", "해당 모델이 적용되는 경우 총 토큰 공급량은 잔액의 합계와 같다", "수수료는 설정된 한도를 초과할 수 없다" 등이 있습니다. 토큰은 컨트랙트로 직접 전송될 수도 있고, 가정된 ERC-20 구현과 다르게 동작할 수도 있으므로 저장소 잔액과 실제 토큰 잔액을 비교하세요.

6단계: 권한 및 업그레이드 가능성 검토

권한 매트릭스를 구축하십시오. 모든 관리 기능에 대해 필요한 역할, 현재 소유자, 전송 메커니즘, 지연 시간, 다중 서명 또는 거버넌스 제어, 비상 동작 등을 명시하십시오. 특히 토큰 발행, 일시 중지, 수수료 변경, 오라클 소스 변경, 자금 복구, 코드 업그레이드, 신뢰 토큰 또는 라우터 주소 변경 등에 주의를 기울이십시오. OpenZeppelin의 접근 제어 문서에서는 단순 소유권과 역할 기반 권한을 구분하고 최소 권한 원칙을 유용한 보안 관행으로 설명합니다.

"관리자가 이 작업을 수행할 수 있도록 코드가 허용하는 경우"와 "임의의 사용자가 이 작업을 수행할 수 있는 경우"를 구분해야 합니다. 전자는 명시적인 거버넌스 또는 관리 위험일 수 있으며, 후자는 권한 부여 취약점입니다. 역할 검사가 공개 함수에서 접근 가능한 내부 도우미를 포함하여 모든 중요한 경로를 포괄하는지 확인하십시오. 기본 관리자가 자신이나 다른 사용자에게 추가 권한을 부여할 수 있는지, 그리고 소유권 이전이 실수로 사용 불가능한 주소로 전송될 수 있는지 확인하십시오.

프록시의 경우, 초기화 메서드, 구현 권한 부여, 업그레이드 지연 시간, 저장소 레이아웃, 롤백 또는 비상 계획을 검토하십시오. OpenZeppelin의 업그레이드 가능 계약 지침은 생성자가 프록시 저장소를 초기화하지 않는 이유, 초기화 메서드를 보호해야 하는 이유, 구현체가 초기화되지 않은 상태로 남아 있으면 안 되는 이유, 저장소 순서 또는 유형을 변경하면 업그레이드가 손상될 수 있는 이유를 설명합니다. 프록시 관리자 키는 구현 세부 사항이 아니라 프로토콜의 보안 경계의 일부로 취급해야 합니다.

7단계: 퍼징, 불변 조건 및 포크를 사용하여 시스템을 테스트합니다.

예상되는 동작에 대한 단위 테스트를 실행한 다음, 권한 없는 발신자, 0 값, 최대값, 만료된 서명, 오래된 오라클 데이터, 전송 실패 및 반복 작업에 대한 부정 테스트를 추가하십시오. 몇 개의 선택된 숫자만 테스트하는 대신 입력값을 퍼징하십시오. 설계상 콜백이 허용되는 경우 여러 행위자와 악의적인 수신자 계약을 포함하십시오.

무작위 호출이 여러 번 발생한 후에도 참이어야 하는 속성에 대해서는 불변성 테스트를 사용하십시오. Foundry의 불변성 테스트 문서에는 무작위 시퀀스, 퍼징 입력, 실행 횟수, 테스트 깊이, 대상 계약 및 대상 송신자에 대한 설명이 있습니다. 호출이 의미 있도록 핸들러를 구성하십시오. 테스트 액터가 토큰을 보유하지 않아 모든 퍼징된 입금이 되돌려지는 경우, 불변성 테스트가 통과하더라도 유용한 상태가 변경되지 않았다는 의미일 수 있습니다.

가능하다면 대상 네트워크의 포크를 사용하여 배포된 주소, 현재 구성, 토큰 동작 및 프록시 라우팅을 테스트하십시오. 격리된 로컬 포크를 사용하는 경우가 아니라면 포크 테스트는 안전하게 보관하고 읽기 전용으로 유지하십시오. 실패한 모든 시퀀스를 최소화하고 반례, 호출자 주소, 블록 컨텍스트, 잔액 및 관련 저장소 값을 보존하십시오. 테스트 통과는 테스트된 경로에 대한 증거일 뿐, 가능한 모든 경로를 증명하는 것은 아닙니다.

8단계: 수정 및 재검사가 가능한 결과를 기록합니다.

문제당 하나의 기록을 사용하십시오. 실질적인 발견 사항에는 다음 내용이 포함되어야 합니다.

• 제목 및 위치: 계약, 기능, 파일, 그리고 줄 번호 또는 코드 참조.
• 영향: 무엇을 훔치거나, 동결하거나, 부풀리거나, 우회하거나, 왜곡할 수 있는가.
• 전제 조건: 필요한 권한, 잔액, 타이밍 또는 구성.
• 재현: 짧은 거래 시퀀스, 테스트, 추적 또는 증명.
• 권장 사항: 특정 코드 또는 운영 방식 변경(장단점 고려).
• 상태: 진행 중, 해결됨, 완화됨, 위험 수용됨 또는 재현 불가능.
• 재검사: 문제가 해결되었음을 확인하는 정확한 검사 또는 관찰.

심각도는 코드 패턴이 얼마나 위험해 보이는지가 아니라 실제 영향과 악용 가능성을 반영해야 합니다. 가정 사항을 명확히 설명하십시오. 저수준 호출은 강력한 불변 조건 뒤에 있으면 안전할 수 있지만, 겉보기에는 평범해 보이는 매개변수 변경이라도 오라클이나 업그레이드를 제어하는 ​​경우 치명적일 수 있습니다. 수정 후에는 변경 사항을 검토하고 관련 테스트를 다시 실행한 다음 전체 테스트 스위트를 다시 실행하고 회귀 여부를 확인하십시오. 배포된 주소가 이미 업그레이드되었거나 변경된 경우 실제 온체인 구현 및 구성을 다시 테스트하십시오.

흔히 저지르는 감사 실수를 피하는 방법

• "소스 코드가 검증되었으므로 안전합니다." 검증은 소스 코드와 바이트코드 간의 일치 여부를 확인하는 것이지, 설계 자체의 유효성을 검증하는 것은 아닙니다.
• "스캐너에서 아무것도 발견하지 못했으니 버그는 없습니다." 도구는 알려진 패턴을 탐지하는 데 가장 효과적이지만, 경제적 결함이나 계약 전반에 걸친 결함은 종종 사람의 분석이 필요합니다.
• “프로젝트에 감사 보고서가 있으므로 현재 배포는 보고서에 포함되어 있습니다.” 보고서의 커밋, 범위, 배포 주소, 수정 사항 및 업그레이드 기록을 비교해 보세요.
• “퍼즈 테스트를 통과했으니 불변식은 올바르다.” 먼저 불변식이 의도한 경제적 속성을 제대로 표현하는지, 그리고 핸들러가 의미 있는 상태에 도달하는지 확인해야 합니다.
• "관리자 권한은 보안 문제가 아닙니다." 이는 의도적인 신뢰 가정일 수 있지만, 사용자는 누가 발행, 일시 중지, 매개변수 변경 또는 업그레이드를 할 수 있는지 확인할 수 있어야 합니다.

결과를 신뢰하기 전에 마지막으로 스스로 점검해 보세요.

다음 질문들에 모두 '예'라고 답할 수 있어야 합니다.

• 체인, 주소, 바이트코드, 프록시, 구현 및 빌드 설정을 정확하게 기록했나요?
• 상태 변화를 일으킬 수 있는 모든 진입점과 그것이 영향을 미칠 수 있는 자산을 모두 목록화했습니까?
• 컴파일은 문제없이 완료되었습니까? 경고를 확인하고 자동화된 발견 사항을 분류했습니까?
• 모든 외부 호출, 콜백, 하위 수준 호출 및 오류 경로를 추적했습니까?
• 반올림, 한계값, 0값, 오래된 데이터, 반복 작업 등을 테스트했습니까?
• 권한 역할, 키, 지연 시간, 초기화 프로그램 및 업그레이드 경로를 모두 매핑했습니까?
• 의미 있는 모호성과 불변 반례를 보존했습니까?
• 독립적인 검토자가 각 문제점을 재현하고 각 해결책을 검증할 수 있습니까?

만약 어느 하나라도 '아니오'라면, 감사를 불완전하다고 표시하고 누락된 증거를 명시하십시오. 모호한 "안전함"이라는 결론보다는 투명한 제한 사항이 더 유용합니다. 스마트 계약 보안은 지속적인 과정입니다. 모든 업그레이드, 종속성 변경, 새로운 통합 및 권한 변경은 새로운 검토 범위를 생성할 수 있습니다.