Smart Contract Audit Red Flags: How to Read Security Reports Before Buying

Updated September 14, 2026. A smart contract audit can be useful evidence, but it is not a safety certificate. The most important question is not “Has this project been audited?” It is “What exactly was audited, which version was reviewed, what remained unresolved, and does the deployed code still match the reviewed system?”

Ethereum’s security guidance explicitly warns that audits are not a silver bullet and cannot uncover every bug. OpenZeppelin’s audit workflow likewise treats scope, findings, severity, remediation status, and fix review as separate pieces of the security picture. The practical goal for a buyer is therefore to read the report like a risk document—not like a marketing badge.

Quick Red-Flag Checklist

Step 1: Confirm That the Report Is Real and Comes From the Auditor

Caption: Start with the report identity, date, auditor, and severity summary before reading individual findings.

Verified: reputable audit reports usually identify the project, the assessment period, the auditor, and the reviewed code. OpenZeppelin’s published reports and Consensys Diligence reports commonly include a scope section and code revision. For example, Consensys’ USDKG report identifies the exact commit hash reviewed, while OpenZeppelin reports routinely specify the repository and commit or pull request in scope.

Misconception: a PDF uploaded by the project is automatically trustworthy because it contains an auditor’s logo. That is not enough. Files can be outdated, modified, or detached from their original context.

Action: find the report through the auditor’s own site or repository whenever possible. Compare the project name, report date, URL, and version details with the copy shared by the token team.

Primary references: OpenZeppelin audit documentation and Consensys Diligence USDKG audit.

Step 2: Read the Scope Before the Findings

Caption: The audit badge matters less than the scope: identify exactly which contracts and components were reviewed.

An audit only covers what is in scope. A report may review a token contract but exclude staking, bridges, vaults, governance, front-end infrastructure, external dependencies, or a later upgrade.

Verified: OpenZeppelin’s Panoptic audit lists its scope and also notes that fixes were distributed across different repositories. Another OpenZeppelin report on an EVM emulator explicitly states that only changes in a specific pull request were audited, not the full files in their entirety. These examples show why “the project was audited” can be an overbroad conclusion.

Misconception: if one contract in the ecosystem was audited, the whole protocol is covered. It is not.

Action: write down every component that can hold funds, move funds, set prices, change permissions, mint tokens, or upgrade contracts. Then mark whether each one appears in the audit scope. Any important blank is a follow-up question.

Example references: OpenZeppelin Panoptic audit and OpenZeppelin EVM Emulator audit.

Step 3: Match the Commit Hash to the Code That Was Actually Deployed

Caption: A report is tied to a code revision; verify that the audited revision still corresponds to the deployed contracts.

This is one of the most overlooked checks. An audit may have been excellent, yet the project may have changed the code afterward.

Verified: OpenZeppelin’s Code Inspector documentation says reports are tied to a specific commit, and Ethereum’s contract-verification guidance explains that verified source code helps users establish that published source corresponds to deployed bytecode.

Misconception: “audited last month” means today’s deployed contract is the audited contract. Time alone does not prove that.

Action: locate the commit hash, tag, or pull request in the report. Then check the project’s deployment documentation and verified source on the relevant block explorer. If the deployed implementation is newer, look for a follow-up audit or documented diff review.

Primary references: OpenZeppelin Code Inspector documentation and Ethereum.org contract verification guide.

Step 4: Treat Finding Status as Seriously as Severity

설명: "심각", "높음" 또는 "중간"이라는 표시는 상황의 절반에 불과합니다. 각 문제가 해결되었는지, 부분적으로 해결되었는지, 아니면 아직 해결되지 않았는지 확인하십시오.

심각도는 발견된 문제의 잠재적 중요성을 나타냅니다. 상태는 그 후에 발생한 상황을 알려줍니다. OpenZeppelin의 감사 도구는 해결됨, 부분적으로 해결됨, 해결되지 않았음을 확인함, 응답 없음과 같은 상태를 구분합니다.

오해: "감사 완료"라는 문구는 프로젝트에서 모든 문제를 해결했다는 의미입니다. 하지만 그렇지 않습니다. 감사가 완료되었더라도 발견된 문제점들이 해결되지 않은 채 남아 있을 수 있습니다.

조치: 심각도 높음 및 중요도 높음 등급의 모든 문제점을 간략하게 목록으로 작성한 다음, 최종 상태와 수정 검토 증거를 기록하십시오. 중간 등급 문제점의 경우, 접근 제어, 가격 조작 또는 회계 오류와 같이 동일한 설계 결함을 지적하는 여러 문제점에 특히 주의하십시오.

심각도가 낮은 발견 사항이라고 해서 무조건 무시해서는 안 됩니다. 해당 발견 사항의 중요성은 시스템 환경, 다른 문제와의 조합, 그리고 권한 있는 사용자가 영향을 받는 기능을 어떻게 사용할 수 있는지에 따라 달라집니다.

5단계: 제목뿐만 아니라 조사 결과, 영향, 전제 조건 및 해결 방안을 모두 읽으십시오.

설명: 심각도 등급은 출발점일 뿐입니다. 취약점 발생 조건, 영향을 받는 자산, 그리고 감사자의 판단 근거를 이해해야 합니다.

유용한 발견 사항은 일반적으로 발생할 수 있는 문제점, 그 중요성, 관련 코드 경로, 전제 조건 및 권장 사항을 설명합니다. 관리자 권한이 필요한 "높음" 등급의 발견 사항은 모든 사용자가 실행할 수 있는 권한 없는 익스플로잇과는 다른 실질적인 위험을 나타낼 수 있습니다.

검증됨: OpenZeppelin은 문제의 심각도를 영향, 발생 가능성, 악용 난이도 등의 요소를 반영하여 정의합니다. Trail of Bits의 246개 스마트 계약 분석에서도 재진입과 같은 잘 알려진 버그 유형뿐만 아니라 여러 범주에 걸쳐 심각한 문제가 발생하는 것으로 나타났습니다. 해당 데이터 세트는 접근 제어, 인증, 타이밍, 수치 연산, 유효성 검사 등을 중요한 위험 요소로 지적했습니다.

오해: 재진입 취약점만이 스마트 계약에서 걱정해야 할 유일한 버그는 아니다. 비즈니스 로직, 접근 제어, 유효성 검사, 오라클 설계, 회계 처리 또한 똑같이 중요할 수 있다.

조치: 중대한 문제점 발견 시, 다음 네 가지 질문에 답하십시오. 누가 문제점을 유발할 수 있습니까? 그들이 얻거나 잃을 수 있는 것은 무엇입니까? 어떤 가정이 필요합니까? 정확한 해결책을 검토했습니까?

주요 참고 자료: OpenZeppelin 감사 문제 모델 , Trail of Bits 감사 결과 분석 , Solidity 보안 고려 사항 .

6단계: 권한 역할, 관리자 키, 일시 중지, 발급 및 업그레이드 권한 검토

캡션: 권한이 부여된 기능은 안전한 코드 경로라 하더라도 거버넌스 또는 키 관리 위험이 발생할 수 있으므로 특별한 주의가 필요합니다.

많은 프로토콜은 의도적으로 특권 역할을 포함합니다. 그렇다고 해서 자동으로 안전하지 않다는 의미는 아니지만, 신뢰 모델이 달라집니다.

확인됨: 이더리움 스마트 계약 보안 지침은 단일 소유자가 중앙 집중식 장애 지점이 될 수 있다고 경고합니다. 또한 역할 기반 접근 제어와 다중 서명 제어를 이러한 위험을 줄이는 방법으로 설명합니다. 오픈제플린의 타임락 문서에서는 실행 지연을 통해 사용자가 유지 관리 작업을 검토하고 적절한 시점에 종료할 시간을 확보할 수 있다고 설명합니다.

오해: "심각한 취약점이 없다"는 것은 관리자가 사용자에게 피해를 줄 수 없다는 의미입니다. 감사 심각도와 관리 권한은 별개의 문제입니다.

조치: 보고서에서 owner, admin, role, multisig, timelock, pause, mint, upgrade, blacklist, 와 같은 용어를 검색하십시오 withdraw. 그런 다음 현재 각 역할을 누가 맡고 있는지, 그리고 해당 역할이 얼마나 빨리 실행될 수 있는지 파악하십시오.

주요 참고 자료: 이더리움 스마트 계약 보안 지침 및 OpenZeppelin 접근 제어 문서 .

7단계: 업그레이드 가능성, 오라클, 브리지 및 기타 외부 신뢰 가정을 확인합니다.

캡션: 솔리디티 파일뿐만 아니라 신뢰 경계도 감사해야 합니다. 프록시, 오라클, 브리지 및 외부 종속성은 실제 위험을 바꿀 수 있습니다.

업그레이드 가능한 프록시는 구현 로직을 변경하면서도 동일한 공개 주소를 유지할 수 있습니다. 오라클은 청산을 결정하는 가격 정보를 제공할 수 있습니다. 브리지는 별도의 수탁 또는 검증자 가정을 도입할 수 있습니다. 외부 라이브러리 및 프로토콜은 독립적으로 오류를 발생시킬 수 있습니다.

검증됨: OpenZeppelin 문서에 따르면 프록시 기반 시스템은 안정적인 프록시 주소와 변경 가능한 구현 코드를 분리합니다. 또한 업그레이드 가능성에는 신중한 권한 부여가 필요하다고 경고합니다. 이더리움 보안 가이드에서는 오라클 조작 위험을 설명하고 잘못된 가격 입력으로 인해 계약이 잘못된 데이터를 기반으로 실행될 수 있다고 지적합니다.

오해: 프록시 주소의 검증된 소스 코드가 향후 동작이 변경되지 않음을 증명한다. 업그레이드 가능한 시스템의 경우 반드시 그렇지는 않다.

조치: 계약 업그레이드 가능 여부, 업그레이드 승인 권한, 업그레이드 지연 여부, 현재 구현 검증 여부를 확인합니다. 그런 다음 장애 발생 시 사용자 자금에 영향을 미칠 수 있는 모든 외부 시스템을 나열합니다.

주요 참고 자료: OpenZeppelin 프록시 문서 및 이더리움 스마트 계약 보안 지침 .

8단계: 잔여 위험을 고려하여 구매/회피/조사 결정

설명: 최종 결정은 감사 배지의 존재 여부가 아니라 수정 후에도 남아 있는 위험을 반영해야 합니다.

수정 후에도 위험은 여전히 ​​존재합니다. OpenZeppelin은 공개된 감사 보고서에서 시간 제한이 있는 검토로는 모든 버그나 위험을 발견할 수 없다고 명시적으로 밝혔습니다. 예를 들어, Audius 감사에서는 심각한 문제가 대량으로 발견된 후 베타 테스트, 버그 현상금 지급, 그리고 향후 재감사를 권고했습니다. Panoptic 감사에서는 중요한 코드 변경 후 추가 모니터링과 재감사를 권고했습니다.

오해: 여러 번의 감사를 거치면 스마트 계약의 위험이 완전히 사라진다. 그렇지 않습니다. 감사는 신뢰도를 높여주지만, 보안은 배포 정확성, 운영, 관리자 키 보안, 모니터링, 사고 대응, 경제적 가정, 그리고 향후 업그레이드에도 달려 있습니다.

조치: 프로젝트를 다음 세 가지 범주 중 하나로 분류하십시오.

• 구매/연구 지속: 현재 배포된 코드가 검토 범위와 일치함; 중대한 문제점이 해결 및 재확인됨; 권한 부여 방식이 적절하고 투명함; 외부 종속성이 이해됨.
• 추가 조사: 핵심 정보가 누락되었거나, 감사가 주요 업그레이드 이전에 수행되었거나, 일부 중/고위험 문제가 부분적으로만 해결되었거나 인정된 경우.
• 현재로서는 다음과 같은 상황은 피하십시오: 심각/높음 수준의 문제가 해결되지 않았거나, 배포 버전이 감사된 개정판과 일치하지 않거나, 핵심 계약이 범위에서 제외되었거나, 관리자가 사용자 자금에 대한 일방적인 통제권을 제대로 공개하지 않은 경우.

일반적인 감사 용어를 해석하는 방법

즉시 중단해야 할 다섯 가지 위험 신호

1. 이 프로젝트에서는 감사인이 제공한 원본 보고서를 보여줄 수 없습니다. 스크린샷이나 로고만으로는 충분하지 않습니다.
2. 보고서에는 재현 가능한 범위나 버전 정보가 없습니다. 커밋, 태그 또는 정확한 파일 정보가 없으므로 어떤 내용이 검토되었는지 파악하기 어렵습니다.
3. 중요하거나 심각한 사안은 강력하고 문서화된 근거가 없으면 해결되지 않은 채로 남아 있습니다.
4. 해당 프로토콜은 업그레이드 가능하지만, 보고서에서는 업그레이드 권한이나 특권 역할에 대해 거의 언급하지 않습니다.
5. 감사 이후 배포 방식이 크게 변경되었으며, 후속 검토 자료는 없습니다.

이러한 징후가 나타나면, 합리화하려 들지 말고 투자 결정을 보류하고 최신 증거를 요청하는 것이 가장 안전한 다음 단계입니다.

10분 만에 완료하는 구매 전 감사 보고서 작성 루틴

1. 감사기관 공식 웹사이트에서 보고서를 열어보세요.
2. 보고 날짜, 저장소, 범위 및 커밋 해시를 기록하십시오.
3. 배포된 계약 및 구현 주소를 확인하십시오.
4. 중요 및 심각도 높은 모든 결과를 읽어보세요.
5. 모든 주요 사안의 최종 상태를 확인하십시오.
6. 특권적 역할과 비상 권한을 검색하십시오.
7. 프록시 업그레이드와 이를 제어하는 ​​주체를 파악하십시오.
8. 오라클, 브리지, 관리 시스템 및 외부 종속성을 식별합니다.
9. 감사된 커밋 이후에 발생한 변경 사항을 찾아보세요.
10. 구매하기 전에 감수해야 할 잔여 위험이 어느 정도인지 결정하십시오.

결론

스마트 계약 감사는 검토의 증거일 뿐 안전성을 입증하는 것은 아닙니다. 가장 강력한 신호는 감사 기관의 로고가 아니라 명확하게 정의된 범위, 정확한 코드 버전, 중대한 발견 사항, 검증된 수정 사항, 배포된 바이트코드, 투명한 운영 통제를 연결하는 일련의 증거입니다.

가장 위험한 읽기 오류는 "감사 완료"라는 문구에서 멈추는 것입니다. 더 유용한 질문은 " 이 감사 후에도 어떤 문제가 발생할 수 있을까? "입니다. 이 질문 에 명확하게 답할 수 있고, 남아 있는 위험을 감수할 수 있다면 더 현명한 결정을 내릴 수 있습니다. 범위, 수정 상태, 관리 권한 또는 배포 버전이 불분명한 경우, 구매하기 전에 조사하는 것이 올바른 조치입니다.

1차 자료

• Ethereum.org: 스마트 계약 보안
• Ethereum.org: 스마트 계약 검증
• Solidity 문서화: 보안 고려 사항
• OpenZeppelin Defender: 감사
• OpenZeppelin: 스마트 계약 감사란 무엇인가요?
• OpenZeppelin 계약: 프록시 문서
• Consensys Diligence: USDKG 감사
• 스마트 계약 감사에서 밝혀낸 246가지 핵심 사항: 비트의 흔적

본 문서는 정보 제공 목적으로만 작성되었으며 재정 자문이 아닙니다. 감사를 통해 스마트 계약, 거버넌스, 오라클, 경제적, 운영적 또는 시장 위험을 완전히 제거할 수는 없습니다.