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件のスマートコントラクトの分析でも、深刻な問題は、再入可能性などの有名なバグの種類だけでなく、複数のカテゴリにわたって発生していることがわかりました。彼らのデータセットでは、アクセス制御、認証、タイミング、数値計算、検証などのカテゴリが重要なリスク要因として強調されています。

誤解：再入可能性だけがスマートコントラクトのバグで、心配する価値がある。そうではない。ビジネスロジック、アクセス制御、検証、オラクル設計、会計処理も同様に重要である。

対策：重大な発見事項ごとに、次の4つの質問に答えてください。誰がそれを引き起こす可能性があるか？彼らは何を得たり、何を損なったりする可能性があるか？どのような前提条件が必要か？具体的な修正策は検討されたか？

主な参考文献: OpenZeppelin 監査問題モデル、Trail of Bits による監査結果の分析、およびSolidity のセキュリティに関する考慮事項。

ステップ6：特権ロール、管理者キー、一時停止、ミント、およびアップグレード権限を検査する

キャプション：特権関数は、安全なコードパスであってもガバナンスや鍵管理のリスクを伴う可能性があるため、特別な注意を払う必要がある。

多くのプロトコルは意図的に特権ロールを含んでいます。それは必ずしもプロトコルを危険にするわけではありませんが、信頼モデルを変えることになります。

検証済み：イーサリアムのスマートコントラクトのセキュリティガイドラインでは、単一の所有者が中央集権的な障害点となる可能性があると警告しています。そのリスクを軽減する方法として、ロールベースのアクセス制御とマルチシグネチャ制御が挙げられています。OpenZeppelinのタイムロックに関するドキュメントでは、実行を遅延させることで、ユーザーがメンテナンス作業を確認し、適切なタイミングで終了する時間を確保できると説明しています。

誤解：「重大な脆弱性がない」とは、管理者がユーザーに危害を加えることができないという意味ではありません。監査の厳格性とガバナンス権限は、別の問題です。

アクション：レポート内で、、、、、、、、、などの用語を検索します。owner次に、admin現在それぞれの役割を誰が担っているか、またその役割がどれくらいの速さで実行できるかを特定しroleます。multisigtimelockpausemintupgradeblacklistwithdraw

主な参考文献：イーサリアムのスマートコントラクトのセキュリティガイダンスおよびOpenZeppelinのアクセス制御に関するドキュメント。

ステップ7：アップグレード可能性、オラクル、ブリッジ、およびその他の外部信頼に関する前提条件を確認する

キャプション：Solidityファイルだけでなく、信頼境界を監査してください。プロキシ、オラクル、ブリッジ、外部依存関係によって、実際のリスクが変化する可能性があります。

アップグレード可能なプロキシは、実装ロジックを変更しながらも同じ公開アドレスを維持できます。オラクルは、清算を決定する価格を提供できます。ブリッジは、個別の保管またはバリデーターの前提条件を導入できます。外部ライブラリとプロトコルは、それぞれ独立して障害を起こす可能性があります。

検証済み： OpenZeppelinのドキュメントでは、プロキシベースのシステムでは、安定したプロキシアドレスと変更可能な実装コードが分離されていることが明記されています。また、アップグレードには慎重な承認が必要であることも警告されています。イーサリアムのセキュリティガイドでは、オラクル操作のリスクについて説明し、価格入力の誤りによってコントラクトが不正なデータに基づいて実行される可能性があることを指摘しています。

誤解：プロキシアドレスで検証済みのソースコードがあれば、将来の動作は変更されないと証明される。アップグレード可能なシステムの場合、必ずしもそうとは限りません。

対策：契約がアップグレード可能かどうか、アップグレードを承認する権限を持つのは誰か、アップグレードが遅延しているかどうか、現在の実装が検証済みかどうかを確認します。次に、障害によってユーザー資金に影響を与える可能性のあるすべての外部システムをリストアップします。

主な参考文献：OpenZeppelinプロキシのドキュメントおよびイーサリアムのスマートコントラクトのセキュリティガイダンス。

ステップ8：残存リスクに基づいて購入／回避／調査の決定を行う

キャプション：最終的な決定は、監査バッジの有無ではなく、修正後に残るリスクを反映したものであるべきです。

修正後もリスクは残ります。OpenZeppelinは公開されている監査報告書の中で、期間限定のレビューではすべてのバグやリスクが発見されるとは限らないことを明言しています。例えば、Audiusの監査では、多数の重大な問題が発見された後にベータテスト、バグ報奨金制度、そして再監査を実施することを推奨しています。Panopticの監査では、追加の監視と、大幅なコード変更後の再監査を推奨しています。

誤解：複数の監査を実施すれば、スマートコントラクトのリスクはゼロになる。そうではない。監査によって保証は向上するが、セキュリティは展開の正確性、運用、管理者キーのセキュリティ、監視、インシデント対応、経済的な前提条件、そして将来のアップグレードにも左右される。

行動：プロジェクトを次の3つのカテゴリーのいずれかに分類する。

• 購入／研究の継続：現在展開されているコードはレビュー対象の範囲と一致している。重大な問題は解決され、再確認された。特権権限は許容範囲内であり、透明性が確保されている。外部依存関係が理解されている。
• さらに調査してください：重要な情報が欠落している、監査が主要なアップグレードより前に行われた、または中程度/高レベルの問題が部分的にしか解決されていないか、認識されていない。
• 現時点では避けるべき事項：重大な問題／高レベルの問題が未解決のままである、展開状況が監査済みの改訂版と一致しない、コア契約が範囲外である、または管理者がユーザー資金に対する一方的な管理権限を適切に開示していない。

一般的な監査用語の解釈方法

即座に停止すべき5つの危険信号

1. このプロジェクトでは、監査担当者がホストする元のレポートを表示できません。スクリーンショットやロゴだけでは不十分です。
2. この報告書には、再現可能な範囲やバージョンが明記されていません。コミット、タグ、または具体的なファイルがないため、何がレビューされたのかを把握するのは困難です。
3. 重大または高レベルの問題は、明確で文書化された根拠がない限り未解決のままとなる。
4. このプロトコルはアップグレード可能であるが、報告書ではアップグレード権限や特権ロールについてはほとんど触れられていない。
5. 監査後、導入内容が大幅に変更されたため、その後のフォローアップレビューは実施されていない。

これらのいずれかが現れた場合、最も安全な次のステップは、それを正当化しようとしないことです。投資判断を一時停止し、最新の証拠を求めましょう。

10分でできる購入前監査レポート作成手順

1. 監査人の公式サイトから報告書を開いてください。
2. レポートの日付、リポジトリ、スコープ、コミットハッシュを記録してください。
3. 展開済みの契約と実装アドレスを確認してください。
4. 重大な所見と高評価の所見をすべてお読みください。
5. 重大な問題はすべて、最終的な状況を確認してください。
6. 特権的な役割や緊急権限を探す。
7. プロキシのアップグレードとその制御者を特定する。
8. オラクル、ブリッジ、カストディシステム、および外部依存関係を特定する。
9. 監査対象のコミット以降に加えられた変更点を確認してください。
10. 購入前に、どの程度の残存リスクを受け入れるかを決めましょう。

結論

スマートコントラクトの監査は、レビューが行われた証拠であって、安全性の証明ではありません。最も強力なシグナルは、監査人のロゴではなく、明確に定義された範囲、正確なコード改訂、重大な発見事項、検証済みの修正、展開されたバイトコード、そして透明性のある運用管理を結びつける証拠の連鎖です。

最も危険な読み間違いは、「監査済み」という一文で判断を止めてしまうことです。より重要な問いは、「この監査後、他にどのような問題が発生する可能性があるか？」です。この問いに明確に答えられ、残りのリスクを許容できるのであれば、より情報に基づいた意思決定ができ​​るでしょう。適用範囲、修正状況、管理者権限、または展開済みバージョンが不明確な場合は、購入前に調査を行うのが正しい対応です。

一次資料

• Ethereum.org: スマートコントラクトのセキュリティ
• Ethereum.org：スマートコントラクトの検証
• Solidityドキュメント：セキュリティに関する考慮事項
• OpenZeppelin Defender: 監査
• OpenZeppelin：スマートコントラクト監査とは？
• OpenZeppelin 契約: プロキシのドキュメント
• ConsenSys Diligence: USDKG監査
• ビットの軌跡：スマートコントラクト監査から得られた246の発見

この記事は情報提供のみを目的としており、財務アドバイスではありません。監査によって、スマートコントラクト、ガバナンス、オラクル、経済、運用、または市場リスクを完全に排除することはできません。