T5 · Security Engineer
脆弱性をいくつか見つける段階から、他者が意思決定に使える脅威モデルを提供する段階へ。
セキュリティと監査の分野向けです。
このページの T5 は Track です。講座の章は「第 T30 章」のようにリンク付きで区別します。講座の T5 は EVM Account Model を扱います。
この Track に向いている人
コードの問題は見えても、深刻度を説明できない。 検査不足を知っても、技術的な欠陥を誰がいくら失うかへ換算する方法がなく、危険度を感覚で決めています。
実装は調べられても、経済を調べられない。 再入、権限、精度には慣れても、すべて合法な呼び出しを使い、資金規模だけで奪う攻撃が見えません。
報告が指摘一覧だけになっている。 137 行目の修正などを提出し、修正も確認しても、どんな条件でまだ事故が起きるかは答えられません。
ツールが見ていないものを知らない。 静的解析、網羅率、Fuzzing を使っていても、合わせて何を覆い、何を省くかの一覧がありません。
境界は、発見したものだけでなく、防がない範囲も含むプロトコルの境界を提供することです。
前提
安全は業務から独立した技能ではありません。第 T29 章が第 24 章と第 T21 章へ依存するのは、オラクルと清算を知らなければ DeFi を監査できないためです。
- 第 T7–T9 章
- 第 T12 章
- 第 T28 章
- 第 24 章
- 第 T21 章
- 第 T29 章
- 第 T30 章
| 先に読む章 | グラフ上の理由 |
|---|---|
| 第 T7 章から第 T9 章 | 第 T28 章は第 T8・T9 章に依存。Gas の構成まで計算できる実装経験が必要 |
| 第 T12 章 · Testing & Deployment | 同じく第 T28 章の前提。Fork の能力なしでは再現コードを書けず、それが最も確かな成果物 |
| 第 T28 章 · Smart Contract Security | 脆弱性は行間の順序と、守られない経路にあるという原理 |
| 第 24 章 · Crypto でなぜゼロ化と攻撃が続くか | 第 T29 章の前提。事例集ではなく攻撃の分類を与える |
| 第 T21 章 · Oracle | 同じく第 T29 章の前提。よくある単一障害点と経済攻撃の入口 |
| 第 T29 章 · Protocol Security | 脆弱性なしに資金だけで何ができるか。攻撃費用表が中心の道具 |
| 第 T30 章 · Audit | 脅威モデルの四問、不変条件の三種類、四層のツールの境界。成果物の構造 |
第 T24 章 · MEV（順序も攻撃面）と第 T26 章 · Cross-chain（信頼の仮定の負担者）も強く勧めます。
学ぶ内容
- Audit
- Threat Model
- Fuzzing
- Formal Verification
- Economic Security
五テーマを三群と、全体を貫く職業上の規範に分けます。
1．Threat Model と Audit：範囲を提供可能な判断へ
監査範囲は脅威モデルで決まり、能力の境界でもあります。未知のプロトコルで二日以内に、攻撃者、狙うもの、能力、明確に防がないものを記します。
入口から資金経路を描き、信頼境界、外部依存と失敗、誰が何を変更し、即時か遅延かの権限表を作ります。
深刻度は感覚ではなく、到達可能性（必要な前提）と影響（取得額と被害人数）の積です。二変数を書けない評価は推測です。
2．Fuzzing と Formal Verification：次の変更でも結論を保つ
成果物は自動実行するものです。呼び出し列を探す状態を持つ Fuzzing が主力で、形式検証は短く、性質を厳密に表せ、失敗費用が大きい関数に絞ります。
必要な技能は次です。
- 未知のコードから不変条件を導き、安全性と現在の実装の偶然を区別する
- 深い状態へ到達する呼び出し列の生成器を書く
- 網羅率に基づいて調整し、どの時間で効果が逓減するか説明する
- 検証結果は記述したモデル内だけで成立し、モデルが誤れば証明も誤ると理解する
3．Economic Security：脆弱性なしに資金だけで攻撃する
コードの監査者とプロトコルの監査者を分ける群です。攻撃者ごとに、資金、時間、取引数、取得可能額を表へ記します。
価格操作とフラッシュローン、提案期間と議決権の借入、流動性撤去の連鎖、清算報酬の悪用、プロトコル間の伝染を最低限扱います。
難所はどの費用を計算すべきかを思い付くことです。仮定ごとに、その仮定を資金で崩す費用を問います。
4．職業上の規範：参加するための条件
練習の対象は実際のシステムであり、そこでの越境は学習ではなく事故です。
- 公開コードを読み、ローカルか Fork だけで再現します。無許可のオンライン配備へ対話的なテストを行ってはいけません。
- 実際の脆弱性は責任ある開示に従い、先に運営や公開窓口へ連絡し、修正期間を与え、修正確認後に公開します。
- 資産が必要ならテストネットを使い、避けられない場合は少額で事前に明示します。
- コピーしてメインネットで実行できる攻撃スクリプトを報告に書きません。再現は Fork に置き、業界の慣行と自分の保護を守ります。
卒業成果物
脅威モデル、不変条件、再現コードを備えた実際のプロトコルの監査報告。
卒業プロジェクトと異なり、他者が作ったものを評価します。実務の形式に近く、雇用者がそのまま仕事の見本として扱いやすい成果物です。
公開コード、中心部が二千行以内、公開監査報告がある対象を選びます。公開報告が重要です。終了後に照合し、見落としと独自の発見を確認できます。
他者が再現コードを動かせるか。 各発見に、一コマンドで Fork 上で再現し、前後の状態を示すテストを付けます。
Fork 専用であり、オンライン配備へ実行してはいけないと明記します。 再現コードがなければ、専門的な評価では未検証の推測です。
四問に答え、防がないものを最低三つ示す。 内部のマルチシグや更新権限者も攻撃者に含め、目的、能力、範囲を記します。
第四問が専門性を分けます。各項目に、起きた場合の負担者を書きます。
不変条件と、実行済みの Fuzzing を付ける。 三種類を覆う最低八つで、違反の結果と自動検証方法を示します。
意図的な破壊を検出した最短の失敗列を残します。常に成功する検査は、ない検査と同じです。
攻撃費用表を付ける。 最低三種類の攻撃者に、資金、時間、取引数、成功時の利益上限を示します。
現在のパラメーターで、どの攻撃が割に合うかへ結論を落とします。すべて不利なら、資金の閾値、タイムロック、厚みのどれが支えるかを説明します。報告の他の部分以上に重要です。
各発見に根拠付きの等級を付ける。 ラベルだけでなく、到達可能性と影響を書きます。
冒頭に範囲、対象ファイル、コミット、対象外を示します。第 T30 章の 17 件を直しても資金を失ったチームは、このページが読まれなかった例です。
達成したかを判断するには
脅威モデルと不変条件の一覧です。
発見一覧は以前の誤りを示し、提出時が最も価値が高く、以後の変更を覆わず価値が減ります。
脅威モデルは危険の境界、不変条件はテストへ接続され、コードとともに生き続け、変更ごとに再検証されます。
発見は今回の成果、モデルと不変条件はチームへ残す能力です。
違反すると、資金や支配権を失う人がいるかを問います。
利用者残高の合計が保有資産以下、は引き出し不能を防ぐ安全の条件です。
内部配列の長さが利用者数と等しい、は別実装で変えられ、安全性と無関係な細部です。
AI の補助では特に重要です。現在の実装の偶然を不変条件にしがちで、すべて通っても資金を守りません。
薄い市場で担保価格を上げ、実価値を超えて借り、放棄する価格操作です。フラッシュローンなら元本はほぼ不要です。
議決権を借りるか買い、有利な担保率などへ変更し、裁定後に返すガバナンス攻撃です。期限と借入可能な厚みが実現性を決めます。
急変時に清算経路を占有したり、担保売却の流動性を撤去し、不良債権を作って他所のポジションで利益を得る、清算報酬の悪用です。
共通点は、呼び出しはすべて合法ということです。実装だけの報告では見えません。
すべてすでに表現した性質だけを検証します。
静的解析は既知の形、Fuzzing は書いた不変条件、形式検証は与えたモデルしか扱いません。業務の意味や未記載の性質を考えてはくれません。
漏れるのは、思い付かなかった攻撃者の種類全体です。どの一覧にもなく、直接数えられません。
脅威モデルの最初へ戻り、無限の資金を借りられる裁定者や自分自身など、役割の欠落を間接的に調べます。
正解は一つではありません。三つを確認します。
- 行ごとの読解より先に、範囲と脅威モデルを決めますか。二日で全行は読めず、読むべきでもありません。
- 資金経路と権限表を先に描きますか。高危険度の多くは、資金の入口・出口と変更権限にあります。
- 防がない範囲を書く時間を残しますか。チームが最も必要としても、未記載になりがちな節です。
二日をすべて読解に使うなら、成果は発見一覧になりがちです。
よくある誤解
発見数が多いほど品質が高い
数は実装の粗さを測り、評価の深さではありません。低危険度 23 件でも経済の仮定を扱わず、6 件でもモデルと不変条件がある報告のほうが有用です。
どんな条件でまだ事故が起きるかを主問にし、指摘を副産物と扱います。
ツールを実行すれば調べたことになる
静的解析は誤検知もあるフィルターで、Fuzzing は記載条件だけを測ります。出力は脅威モデルを基に判断します。
実問題、誤検知、見落としへ分けます。前二つは見えても、最後は攻撃者の欠落から間接的に推測するしかなく、最も危険な種類です。
監査は公開前の一つの関門
監査は一時点の記録です。コード、依存、市場は変わり、自分が変更しなくても依存の更新で仮定が失われます。
不変条件を CI、重要な仮定を監視へ接続します。依存の実装アドレス変更などを通知します。価値は自動で動き続けるものを、いくつ残したかで決まります。
コードだけを監査し、経済は担当外
範囲として明記するなら専門的ですが、暗黙にすると危険です。多くのチームは経済の監査者を別に雇わず、対象外は誰も見ていないことを意味します。
有料範囲外でも、気付いた未評価の仮定を一節に書き、攻撃費用の計算を勧めます。調べていないリスクの指摘は、低危険度を三つ追加するより役立ちます。
次に進むには
- 対象とともに、第 T28 章、第 T29 章、第 T30 章を読み直します。
- DeFi の監査には、Track T4 · DeFi Engineerの理解が必須です。
- Track T1 · EVM Engineerで実装、Track T3 · Onchain Data Engineerで調査と監視、Track T6 · AI × Crypto Engineerで新しい攻撃面を深めます。
- AI の補助前に、AI の安全経路と第 T31 章を読みます。速くなるのは作成であり、Review の責任は移りません。
- 非技術側は Track N5 · Crypto Founderです。安全予算をどの段階へ使うかは、監査経験のある人が答えられます。
- 自分のものを作るなら、卒業プロジェクトへ進みます。