メインコンテンツへスキップ
NetsujoNetsujo Inc.
資料一覧に戻る

— SECURITY CHECKLIST

スマートコントラクト発注前セキュリティチェックリスト

監査前社内レビューに使える40項目

スマートコントラクト開発を外部に発注する前段階で、社内側で確認しておくべきセキュリティ論点を、合計40項目のチェックリストとしてまとめた資料です。設計レイヤー・エコシステム設計・インフラ運用・監査法務の4観点から、発注後の手戻りを最小化するための論点を整理しています。

各項目には背景・確認ポイント・推奨対策の解説を併記しました。タイトルだけで判断が難しい論点も、解説を読むことで意味と対策が把握できる構成です。DeFi・NFT・RWA等で発生した過去のハッキング事例から逆算した設計時論点を盛り込んでいます。

セキュリティ設計の相談をする

— 01

本資料の使い方

スマートコントラクトの脆弱性は、デプロイ後の修正が困難なケースが多く、被害規模も極端に大きい領域です。発注前の段階で社内側がセキュリティ論点を整理しておくことで、発注先との議論の精度が上がり、監査前のレビュー品質が大きく変わります。

このチェックリストは4章構成で、合計40項目を整理しています。

  • 第2章: 設計レイヤーのチェック（10項目）
  • 第3章: エコシステム設計のチェック（10項目）
  • 第4章: インフラ・運用のチェック（10項目）
  • 第5章: 監査・法務のチェック（10項目）

各項目には Yes / No / 未確認 のチェック欄を設け、社内のセキュリティ担当・技術担当・法務担当が独立して評価し、結果を持ち寄る使い方を想定しています。発注前にすべて Yes である必要はありません。No や 未確認 項目を整理して、どのリスクが残っているかを認識した上で要件定義を進めていく材料としてください。

要点

  • ・スマートコントラクトは「発注前」の整理が品質を左右する
  • ・4観点・40項目を社内複数人で評価
  • ・各項目に解説を併記、論点を理解しやすい構成

— 02

設計レイヤーのチェック（10項目）

スマートコントラクトの設計時に確認すべき論点です。アップグレード方式・権限管理・関数の可視性など、デプロイ後に修正困難な箇所を中心に整理します。

  1. 1

    アップグレード方式（Proxy / Diamond / Immutable）の選定方針が決まっている

    YesNo未確認

    デプロイ後の柔軟性とリスクのトレードオフを最初に決める論点。Proxy（Transparent / UUPS）は標準的だがストレージスロット衝突リスクを伴い、Diamond は機能追加に強い反面複雑性が高い。Immutable は最も安全だが将来の修正不能。事業の成熟度とロードマップに合わせて選定し、選定理由を文書化する。

  2. 2

    権限管理（onlyOwner / Role-based）の最小権限原則が適用されている

    YesNo未確認

    特権関数を呼べる主体を必要最小限に絞り、Role-based（OpenZeppelin AccessControl 等）で権限を細分化する。EOA 単一の onlyOwner は秘密鍵流出時のリスクが高いため、本番では Multisig または Timelock + Multisig を推奨。

  3. 3

    関数の可視性（public / external / internal）が必要最小限になっている

    YesNo未確認

    公開不要な内部処理が public で公開されていないか、external として外部呼び出しを期待する関数の制約が適切か確認する。Solidity ではデフォルト可視性に頼らず明示することで、意図しない外部呼び出しを防げる。

  4. 4

    リエントランシー対策（CEI パターン / ReentrancyGuard）が組み込まれている

    YesNo未確認

    外部呼び出しを含む関数で「Checks → Effects → Interactions」の順序を守り、状態変更を外部呼び出し前に完了させる。OpenZeppelin の ReentrancyGuard を併用するのが標準。The DAO 事件の根本原因はこの脆弱性。

  5. 5

    ガス制限・無限ループの可能性が排除されている

    YesNo未確認

    配列のループ処理が攻撃者によって膨張させられないか、unbounded loop で DoS が発生しないかを確認する。ループ上限の設定、ページング処理、プル型送金（pull payment）への切り替えで回避できる。

  6. 6

    数値計算のオーバーフロー対策（SafeMath / Solidity 0.8+）が施されている

    YesNo未確認

    Solidity 0.8 以降は組み込みでオーバーフロー検知があるが、unchecked ブロックを使う箇所では明示的な検証が必要。0.8 未満のコードは SafeMath 導入が必須。トークン残高計算が代表的な攻撃面。

  7. 7

    重要な状態変更時にイベントが発行される設計になっている

    YesNo未確認

    オーナー変更・残高移動・パラメータ更新などの重要操作で event emit を行う。オフチェーンの監視やインデクサの動作に直結し、インシデント発生時の調査と異常検知の前提となる。

  8. 8

    ストレージスロットの衝突がアップグレード時に発生しない構造である

    YesNo未確認

    Proxy パターン採用時、実装コントラクト側のストレージレイアウト変更で旧データが破壊されるリスクがある。OpenZeppelin の storage gap や namespaced storage（ERC-7201）で衝突を回避する設計を最初から組み込む。

  9. 9

    メタトランザクションのリプレイ攻撃対策（nonce / chainId）が組み込まれている

    YesNo未確認

    ガスレストランザクションや署名認可（permit 等）を扱う場合、署名の使い回し（リプレイ）を防ぐため nonce と chainId を署名に含める EIP-712 形式が前提。署名検証ロジックは複数監査が望ましい。

  10. 10

    外部コントラクト呼び出しの返り値検証が漏れていない

    YesNo未確認

    call() や transfer() の返り値を確認せず処理を続行すると、失敗が無視されて状態が壊れてしまう。ERC20 の transfer も非標準実装が多く、SafeERC20 を経由するのが安全。Wormhole 事例の根本原因も外部検証の欠陥。

要点

  • ・アップグレード方式の選定は最初に決める
  • ・権限・可視性は「最小権限」を原則
  • ・過去のハッキング事例の多くは設計時の見落としに起因

— 03

エコシステム設計のチェック（10項目）

トークン経済・流動性・オラクル参照・ガバナンスなど、攻撃者が経済的利益を得る構造の論点です。Mango Markets・Beanstalk・Cream Finance等の事例から逆算した項目を含みます。

  1. 1

    オラクル価格の参照に複数オラクル（Chainlink等）が使われている

    YesNo未確認

    単一のオラクルや単一プールの spot price を担保評価に使うと、流動性の薄い時間帯に価格操作攻撃を受ける。Chainlink などの分散オラクル＋自社の独立検証ソースの組み合わせを推奨。

  2. 2

    オラクル価格の操作耐性として TWAP（時間加重平均）が組み込まれている

    YesNo未確認

    Uniswap V3 や Chainlink の TWAP（数十分〜数時間平均）を使うことで、フラッシュローンによる短時間の価格操作を緩和できる。瞬間値（spot price）依存は危険。

  3. 3

    担保比率の設計が保守的である（フラッシュローン耐性を考慮）

    YesNo未確認

    極端な相場変動時にも清算が間に合う担保比率（LTV）を設定する。フラッシュローンで一時的に流動性が動いても、清算可能な余裕が残る設計が必要。

  4. 4

    流動性下限（プールの最小TVL）が設定されている

    YesNo未確認

    流動性が極端に薄い時間帯はオラクル操作と組み合わせた攻撃が成立しやすい。プールの最小TVL閾値を設け、それ未満では取引や担保評価を停止する仕組みを組み込む。

  5. 5

    ガバナンス提案の即時実行ではなく、タイムロックが組み込まれている

    YesNo未確認

    提案可決から実行まで 24〜72 時間のタイムロックを設けることで、悪意ある提案が可決されても撤回・対抗できる。Compound や OpenZeppelin Governor の標準パターン。Beanstalk 事件の主因はタイムロック欠如。

  6. 6

    ガバナンストークンのフラッシュローン取得による即時投票を防ぐ設計である

    YesNo未確認

    スナップショット投票（過去ブロックの保有量で集計）または最低保有期間の要件を入れることで、フラッシュローンで一時的に投票権を借りる攻撃を防げる。

  7. 7

    インセンティブ設計（バーン・ステーキング・配分）の整合性が取れている

    YesNo未確認

    インフレ率・配分先・バーン条件・ステーキング報酬が長期的に均衡するか、シミュレーションで確認する。短期 APR を過剰に設定すると、流動性提供者の早期離脱で価格崩壊を招く。

  8. 8

    経済攻撃シミュレーションが実施されている（または計画されている）

    YesNo未確認

    Foundry の invariant testing、Echidna、Certora などで経済モデルの不変条件を機械的に検証する。設計フェーズで実施するのが理想で、最低限テストネットで攻撃シナリオの再現を行う。

  9. 9

    緊急停止権限の設計と発動条件が明確である

    YesNo未確認

    pausable パターンで緊急停止できる関数群を限定し、発動条件（誰が、どの状況で、どの範囲を止めるか）を文書化する。停止権限の濫用を防ぐためマルチシグ＋タイムロックでガードする。

  10. 10

    手数料モデル・トークン分配の透明性が確保されている

    YesNo未確認

    手数料率・分配先アドレス・変更可能パラメータを公開し、コントラクトコメントとドキュメントで一致させる。利用者がコントラクトを読めば全容を把握できる状態が望ましい。

要点

  • ・オラクル攻撃は防御策を組み合わせて実装
  • ・ガバナンスはタイムロック必須
  • ・経済攻撃シミュレーションは設計段階で実施

— 04

インフラ・運用のチェック（10項目）

秘密鍵管理・マルチシグ・フロントエンド・モニタリングなど、コントラクト外側の運用基盤の論点です。Ronin Bridge・BadgerDAO・Nomad等の事例から逆算した項目を含みます。

  1. 1

    マルチシグの閾値（M of N）が保守的に設定されている

    YesNo未確認

    本番資産を扱うウォレットは最低 3of5 以上、大規模資産は 5of9 など。署名者は複数組織・地理的に分散させる。Ronin Bridge は 9 バリデータ中 5 バリデータが単一組織だったことが破綻の主因。

  2. 2

    HSM（ハードウェアセキュリティモジュール）またはハードウェアウォレットが使われている

    YesNo未確認

    秘密鍵がメモリやサーバ上に平文で存在しない構成にする。Ledger / Trezor / AWS CloudHSM などを採用し、署名はハードウェアデバイス内で完結させるのが基本。

  3. 3

    秘密鍵保管が地理的・組織的に分散されている

    YesNo未確認

    署名者は複数の物理拠点・複数の組織に分散させ、災害・侵害・離職時のリスクを最小化する。社内 1 拠点で全鍵を保管しているのは大きな単一障害点。

  4. 4

    フロントエンドのインフラ管理（DNS / CDN / Cloudflare）の権限が最小化されている

    YesNo未確認

    スマートコントラクトが堅牢でも、Web フロントが乗っ取られると署名画面を改ざんされる。BadgerDAO は Cloudflare アカウント侵害が起点。DNS・CDN・ホスティングの管理者を最小化し、MFA を必須化する。

  5. 5

    環境変数・APIキー等のシークレットが安全に保護されている

    YesNo未確認

    AWS Secrets Manager / GCP Secret Manager / Vault 等で管理し、リポジトリやログに露出しない。CI/CD のログ出力にも注意を払う。デプロイ用の秘密鍵が誤って公開リポジトリに上がる事故が継続的に発生している。

  6. 6

    デプロイ権限が必要な人員のみに限定されている

    YesNo未確認

    メインネットへのデプロイ権限は限定された担当者のみが持ち、デュアルコントロール（2 名以上の承認）を組み込む。離職者の権限失効プロセスも整備する。

  7. 7

    ログ・監視基盤が稼働しており、異常検知の仕組みがある

    YesNo未確認

    異常トランザクション・大口送金・流動性急変・特権関数呼び出しを検知し、自動アラートを飛ばす基盤を稼働させる。Tenderly / Forta / 自社監視のいずれか。検知から対応まで 1 時間以内が目標。

  8. 8

    インシデントレスポンス手順書が整備されている（緊急停止・資金保全・情報開示）

    YesNo未確認

    誰が何分以内にどの操作を行うかを文書化する。緊急停止判断者、資金移動権限者、広報窓口、法務確認担当を事前に定義。実際のインシデント対応の質はこの準備に大きく依存する。

  9. 9

    バックアップ・リカバリ手順が文書化され、定期的にテストされている

    YesNo未確認

    秘密鍵の紛失・侵害時の復旧手順、データのバックアップとリストアの手順を文書化し、四半期ごとに机上訓練または実機訓練を行う。「準備しただけで使えない手順書」を避ける。

  10. 10

    アップグレード手順がテスト済みで、段階的デプロイの仕組みがある

    YesNo未確認

    テストネットでのフルリハーサル → カナリアデプロイ → 段階的トラフィック移行の手順を定義する。Nomad は初期化処理の検証不足でアップグレード時に脆弱性を埋め込んだ事例。

要点

  • ・鍵管理はHSM・分散保管が前提
  • ・フロントエンドのインフラ管理も攻撃面
  • ・インシデントレスポンスは事前整備が必須

— 05

監査・法務のチェック（10項目）

外部監査・バウンティプログラム・規制対応・KYC/AMLなど、第三者検証と法令対応の論点です。

  1. 1

    監査ファーム選定基準（実績・専門領域・費用）が明確である

    YesNo未確認

    監査ファームは類似領域（DeFi / NFT / Bridge 等）の実績、ヘッドの経歴、過去レポートの公開可否、対応言語、費用と期間を比較して選ぶ。OpenZeppelin / Trail of Bits / Halborn / CertiK / Quantstamp などが候補。

  2. 2

    Critical脆弱性は最低2社の監査で確認される計画になっている

    YesNo未確認

    単一監査では見落とすケースが少なくない。Critical 領域は独立した複数ファームで確認し、フォーマル検証ツール（Certora / SMTChecker）も併用するのが理想。Euler は複数監査でも見落としが発生した事例。

  3. 3

    Bug Bountyプログラムの運用方針が決まっている（Immunefi等）

    YesNo未確認

    Immunefi 等のプラットフォームで Bug Bounty を継続運用し、報奨金額・対象範囲・連絡先・対応 SLA を公開する。本番リリース前から開始することで攻撃前に脆弱性を発見できる確率が上がる。

  4. 4

    監査結果のCritical対応プロセスが事前に定義されている

    YesNo未確認

    監査で Critical / High が発見された場合の対応フロー（誰が修正、誰がレビュー、再監査の要否、デプロイ可否判断者）を事前に定義する。「監査後すぐリリース」のスケジュールは破綻の元。

  5. 5

    法律事務所との連携が確保されている

    YesNo未確認

    Web3 / 暗号資産の法務に実績のある法律事務所と契約しておく。アンダーソン・毛利・友常、TMI、西村あさひ、Atsumi & Sakai 等が国内候補。法務確認をリリース直前に依頼すると間に合わない。

  6. 6

    規制対応（金商法・資金決済法）の論点が整理されている

    YesNo未確認

    トークンが「電子記録移転権利」「暗号資産」「前払式支払手段」「ポイント」のいずれに該当するかで規制が大きく異なる。発行・販売・保管・交換の各フェーズでの規制適合性を法律事務所と整理する。

  7. 7

    KYC/AML体制（必要な場合）が設計されている

    YesNo未確認

    暗号資産交換業や為替類似行為に該当する場合は本人確認・取引モニタリング・疑わしい取引の届出が必要。Sumsub / Onfido / Veriff 等の KYC ベンダー連携を設計に組み込む。

  8. 8

    利用規約・プライバシーポリシーが法的レビュー済みである

    YesNo未確認

    リスク開示（元本毀損・スマコンリスク・規制変更リスク）、責任制限条項、紛争解決管轄、個人情報の取扱いを記載し、法律事務所のレビューを受ける。コピペでは必ず抜けが出る。

  9. 9

    保険プロトコル（Nexus Mutual等）の加入を検討した

    YesNo未確認

    Nexus Mutual / Sherlock / Unslashed 等の DeFi 保険、または伝統的なサイバー保険・暗号資産特約への加入を検討する。プロトコル側で加入する場合と、ユーザーに加入を促す導線を提供する場合がある。

  10. 10

    開示方針（脆弱性公表 / 緊急対応開示）が決まっている

    YesNo未確認

    インシデント発生時に何を、いつ、どの粒度で開示するかを事前に決める。早すぎる詳細開示は攻撃を誘発し、遅すぎる開示は信頼を毀損する。広報・法務・技術の合意で書面化しておく。

要点

  • ・監査は1社では不十分、Critical対応は複数社で
  • ・法務確認は発注前に整理
  • ・開示方針も事前に決める

— 06

集計シートの使い方

各章10項目について、Yes / No / 未確認 を選択し、集計シートで状態を可視化します。

章領域項目数YesNo未確認
第2章設計レイヤー10———
第3章エコシステム設計10———
第4章インフラ・運用10———
第5章監査・法務10———
合計40———

判断基準の目安は次のとおりです。

Yes 32項目以上

監査依頼・発注準備が整っている

監査ファームへ正式依頼へ進める

Yes 24〜31項目

主要論点は押さえている

残りの未確認項目を社内で整理してから発注検討

Yes 24項目未満

設計フェーズの整理が不足

社内議論またはコンサルティングで論点を整理することを推奨

— 07

過去の事例から学ぶ設計指針

このチェックリストの各項目は、実際のハッキング事例から逆算しています。代表的な事例とチェック項目の対応関係を示します。

事例攻撃ベクトル関連チェック項目
Ronin Bridge（2022, 約6億ドル）秘密鍵流出・マルチシグ閾値設計欠陥第4章 ①②③
Wormhole Bridge（2022, 約3.2億ドル）署名検証ロジックの欠陥第2章 ⑩
BadgerDAO（2021, 約1.2億ドル）フロントエンド改ざん第4章 ④⑤
Euler Finance（2023, 約2億ドル）フラッシュローン × ロジック欠陥第3章 ③⑦ / 第5章 ②③
Mango Markets（2022, 約1.1億ドル）オラクル価格操作第3章 ①②③
Beanstalk Farms（2022, 約1.8億ドル）ガバナンス × フラッシュローン第3章 ⑤⑥
Nomad Bridge（2022, 約1.9億ドル）アップグレード時の初期化欠陥第4章 ⑩ / 第2章 ⑧

詳細な事例分析は DeFiハッキング事例10選 を参照してください。

要点

  • ・チェック項目は実事例から逆算
  • ・過去の被害を回避する設計を発注前に組み込む
  • ・事例集と本チェックリストはセット運用

— 08

Netsujoへのご相談

このチェックリストの活用は、社内で完結する場合も、Netsujo株式会社の監査前社内レビューで伴走する場合も両方を想定しています。「未確認」項目が多く、どこから整理すべきかわからない場合は、初回30分の無料相談でご一緒に論点を洗い出します。

支援の標準範囲は以下です。

  • ・チェックリスト各項目の社内インタビューと整理（コンサル）
  • ・スマートコントラクト設計レビュー
  • ・外部監査ファームとの連携支援（監査前準備・指摘事項の解釈）
  • ・監査結果のCritical対応支援
  • ・運用時の継続レビュー（四半期毎）
セキュリティ設計の相談をするWeb3コンサルの詳細

発行: Netsujo株式会社

問い合わせ: info@netsujo.jp

サイト: https://netsujo.jp

PDFをDLする（無料）会員登録不要