Trail of BitsのMiden監査、エージェントが不足ツールを構築した後にFalconの欠陥を発見
Trail of BitsはMiden監査に向けて6か月を費やして準備し、その後、AIエージェントがゼロから構築したツールによって重大度の高い欠陥を発見した。Trail of BitsによるMiden監査は、モデルにソースコードを与えるだけのものではなかった。正式なレビューの開始前に、同社のエージェントはLSPサーバー、デコンパイラ、静的解析エンジン、Leanモデルを作成した。
その準備により、悪意あるプルーバーがFalcon署名を偽造し、影響を受けるアカウントから資金を引き出せる可能性があると報じられた、制約不足の値が明らかになった。解析ツールはまた、型検証を改善できる箇所を400件以上特定した。一方、形式検証の取り組みでは、機械検査済みの正しさに関する証明を95件作成し、既存のユニットテストで見逃されていた2件のバグを発見した。
重要な対立軸は、AIエージェント対人間の監査人ではない。直接的なAIコードレビューと、難しいコードレビューを可能にするインフラの構築をエージェントが支援する方法との違いだ。Trail of Bitsは引き続き、人間による監督、定理の手作業レビュー、従来のセキュリティ判断に依存した。エージェントは、どの支援プロジェクトが経済的に実行可能かを変えた。
Trail of BitsのMiden監査は6か月前から始まっていた
決定的な作業は、監査人が完成した対象を受け取って調査する前に始まっていた。
同社の詳細なMiden監査レポートによると、Midenチームは2025年後半にTrail of Bitsへアプローチした。Midenは、ローンチ前にゼロ知識仮想マシンの一部をレビューしてほしいと考えていた。その一部には、Miden Assembly、すなわちMASMで記述された暗号プリミティブを含む中核ライブラリが含まれていた。
ゼロ知識仮想マシンは、しばしばzkVMと略され、すべての検証者が同じ計算を繰り返すことなく、プログラムが正しく実行されたことを証明する。Midenはスタックマシンアーキテクチャを採用している。命令はスタックから値を取り出し、結果を再びスタックに積む。
このアーキテクチャが重要なのは、MASMコードでは入力と出力が暗黙的であることが多いためだ。レビュー担当者は各命令がスタックをどう変更するかを追跡し、その状態を分岐、ループ、プロシージャ呼び出しにまたがって引き継ぐ必要がある。ソースレベルで馴染みのある手がかりは失われる場合がある。
MASMには、監査人が通常期待するツールの多くも欠けていた。エディタのサポートは限定的で、レビュー向けに整備された言語サーバーはなく、中核ライブラリに対する自動解析も限られていた。Trail of Bitsは実装がまだ機能的に完全ではないことを把握していたが、レビューまで6か月あることも認識していた。
同社はその期間を使い、独自のレビュー環境を構築した。Trail of Bitsによると、Claudeは数日以内に初期の言語サーバープロトタイプを作成した。完成したMASM language serverは、ナビゲーション、参照の発見、ホバー文書、構文診断、命令の説明、スタック効果の情報を提供する。
これらの機能は、通常の開発者向けの利便機能のように聞こえるかもしれない。しかし、馴染みのないアセンブリ言語では、セキュリティ手法の一部となる。ナビゲーションは監査人がプロシージャ境界をまたいで値を追跡する助けとなる。インラインのスタック効果は、手作業による再構築の繰り返しを減らす。診断は、前提が脆弱性の指摘になる前に表面化させる。
Trail of Bitsはその後、プロジェクトをデコンパイル、静的解析、コマンドラインツール、形式モデリングへと拡張した。Claudeが計画と実装を担い、Codexはコードレビューに参加した。エージェントは役割も入れ替え、生成された成果物に別のレビュー工程を与えた。
これは一度きりの生成プロセスではなかった。機能を実装した後、チームはエージェントにランダム化したプロシージャをデコンパイルさせ、結果を元のMASMと比較するよう求めた。回帰はテストになり、モデルはそのテストに対して作業を進めた。
このフィードバックループが、この事例の中心にある。エージェントは、出力が自動的に信頼されるべき権威として扱われなかった。テスト、レビュー段階、解析ツール、そして後には証明チェッカーを含む、成長する検証システムの内部で稼働した。
そのため、この監査は通常とは異なる問いから始まった。Trail of Bitsは、エージェントが脆弱性を見つけられるかだけを問わなかった。監査人やエージェントがそもそもコードを理解することを妨げる、不足した手段は何かを問うた。
このスコープの変更が、最終的な発見の条件を生んだ。また、AIレビューを主に高速なソースコードスキャンとして売り出すセキュリティチームにも圧力をかけるものだ。Trail of Bitsのアプローチにはより多くの準備が必要だったが、その準備を再利用可能な技術インフラへと変換した。
デコンパイラは出力そのものより価値を持つようになった
デコンパイラが最も重要だったのは、その中間表現が他の解析にとって信頼できる実行基盤となったからだ。
MASMのデコンパイルは、単にアセンブリ命令を読みやすい式に置き換える作業ではなかった。中核ライブラリのプロシージャの大半には宣言済みのシグネチャがなく、ツールはしばしば文脈から入力と出力を推論する必要があった。プロシージャには統一された呼び出し規約もなかった。
ループも別の問題を生んだ。MASMのwhileループでは、反復ごとに同じスタック形状を維持する必要がない。条件が別のスタック位置へ移動することがあり、命令入力に安定した名前を割り当てようとする単純な試みは破綻する。
条件分岐も異なるスタック効果を生み出し得る。一方の分岐で項目を追加し、もう一方で削除する場合、デコンパイラはその状態を無条件にマージできない。スタック効果の推論における誤りは、影響を受けたコードを呼び出すすべてのプロシージャへ伝播する可能性がある。
Trail of Bitsは、提供する保証を限定することで対応した。同社のMASM decompilerは、すべてのプロシージャを完全に復元できると主張するのではなく、明確に定義されたサブセットを対象としている。この選択は、表面的なカバレッジより正しさを優先した。
デコンパイラはプロジェクト最大のツール開発作業となった。Trail of Bitsは、数か月にわたり100件を超えるAI生成コミットがあったと報告している。しかし、完成した疑似コードは最も重要な成果物ではなかった。
このプロジェクトは、プロシージャの入力と出力を解析可能な式として表現する中間表現、すなわちIRを作成した。IRは、変換や解析のために設計された構造化されたコード表現である。MASM命令がその形式で存在すれば、チームは確立されたデータフロー解析と静的解析の手法を適用できる。
解析ツールは、プルーバーが提供した値が使用前に検証されているかを調べられる。32ビット整数やブール値など、コードが期待される型を強制しているかも追跡できる。また、ローカル変数が考えられるすべての実行経路で初期化されているかも判定できる。
Trail of Bitsはこの作業の一部で抽象解釈を用いた。抽象解釈は、具体的な1つの入力でプログラムを実行するのではなく、可能な値のカテゴリーを評価する。値は、有効な32ビット整数、ブール値、または未知の値として表現されることがある。
解析は、新しい情報が現れない安定状態に達するまで繰り返される。健全に設計されていれば、実際の実行で可能な動作を過大近似する。これは偽陽性を生む可能性があるが、モデルが対象とする実際の動作を密かに除外してはならない。
この点は、Trail of BitsによるMiden監査が一般的なAIコーディングのデモと異なる理由を示している。エージェント生成のデコンパイラは、コードが安全だと断言するために信頼されたわけではない。明示的で検査可能な解析を実行できる基盤の構築に役立った。
このワークフローは人間にも利点をもたらした。デコンパイルされたプロシージャにより、エディタ内で高レベルの制御フローとデータフローをレビューしやすくなった。スタック注釈は精神的な管理負荷を減らした。コマンドラインインターフェースにより、同じ機能を自動化されたレビュー処理でも利用できるようになった。
コーディングエージェントを評価するチームには、より広い教訓がある。最も価値の高い生成成果物は、ユーザーが目にするものとは限らない。部分的にスコープを限定したデコンパイラであっても、そのパーサー、制御フローモデル、IRが複数のより価値あるチェックを可能にするなら、コストに見合う可能性がある。
この結論は、チームがプロジェクトのコンテキストをどのように保存すべきかも変える。エージェントへのプロンプト、回帰ケース、アーキテクチャ上の決定、レビュー担当者のコメントは、持続的なエンジニアリング入力となる。検索可能なナレッジベースは、長期にわたるセキュリティプロジェクトでこれらの資料を利用可能な状態に保つ助けとなる。
直接的なAIレビューは通常、対象コードから始めて欠陥を問う。Trail of Bitsは代わりに、レビューの対象面そのものを変えるためにエージェントを用いた。次の結果は、なぜこの違いが重要だったかを示している。
1つの欠けたチェックがFalcon認証に到達した
検証されない単一の剰余が、算術ヘルパーを認証偽造への経路に変えたと報じられている。
監査中、静的解析は型検証を改善できる一意の箇所を400件以上特定した。Trail of Bitsによると、これらはすべて中核ライブラリの公開APIから到達可能だった。多くは、公開されているプロシージャが、元の作成者が想定した前提なしに呼び出され得ることから生じた。
公開プロシージャは、すべての呼び出し元が意図された型の値を渡すことに安全に依存できない。証明システムでは特に、プルーバーが提供する値と、証明によって制約される値を区別することが重要だ。データを計算に置くだけでは、それが主張された整数やブール値を表すことは確立されない。
重大度の高い発見は、64ビット値を12,289で剰余演算するプロシージャmod_12289に集中していた。プルーバーはadviceメカニズムを通じて商と剰余を提供した。advice値はVM外部で計算される実行ヒントであり、VM内での高コストな処理を避けるためによく使われる。
商には、期待される64ビット表現に収まることを確認するチェックがあった。一方、剰余には、32ビット減算命令であるu32overflowing_subに入る前に、同等の検証が行われていなかった。
Trail of Bitsによると、攻撃者は減算制約を満たしたまま、商と剰余を変化させることができた。これにより、mod_12289は数学的に正しい剰余とは異なる結果を返し得た。
このバグの影響は、不正な算術結果だけにとどまらなかった。このプロシージャはFalcon署名検証を支えていた。Falconは耐量子デジタル署名方式であり、Midenはアカウント認証にそのバリアントを使用していた。
Trail of Bitsによると、悪意あるプルーバーはこの制約不足の値を悪用し、Falcon署名を偽造して、Falcon鍵ペアで管理されるアカウントから資金を引き出せる可能性があった。これは同社による技術的主張であり、公開記事で独立して再現されたエクスプロイトではない。
深刻度はMidenの実行モデルに起因する。Miden VM designは、証明生成中に提供される非決定的入力をサポートしている。これらの入力は効率を向上させる可能性があるが、プログラム側で慎重に制約する必要がある。
検証者は開発者の意図を推測しない。提出された証明が、エンコードされた制約を満たすかを確認する。これらの制約が不正な剰余を受け入れるなら、主張された算術関係が誤っていても、証明は有効なままであり得る。
これが根本的な逆転である。ゼロ知識証明は、指定されたシステムが忠実に実行されたことを確立できるが、不完全な仕様を修復することはできない。制約不足のプログラムに対する暗号学的証明は、誤った性質への確信を与え得る。
独立した後続のMiden contract auditも、この一般論を裏付けている。OpenZeppelinは、対応する証明が存在する場合にMidenトランザクションは有効であると説明しており、すべてのMASMチェックがproverが満たすべき制約の一部となる。
この別個のエンゲージメントは異なるリポジトリ範囲を対象としており、Trail of Bitsのレビューと混同すべきではない。しかし両者の報告は、認証ロジック、proverが制御する入力、オンチェーンの前提条件を明示的に扱う必要がある理由を示している。
400件を超える型検証箇所についても、慎重に解釈する必要がある。これらは400件の悪用可能な脆弱性として説明されたものではない。検証を改善できる箇所を示すものであり、その中には報告された高深刻度の問題が1件含まれていた。
この区別は重要である。静的解析では、トリアージが必要な条件がしばしば検出される。健全なアナライザーは、最終的にセキュリティ欠陥となる件数より多くのケースを意図的に報告することがある。その価値は、精査に値する前提条件を体系的に特定することにある。
セキュリティチームにとって、この結果はよくある近道に再考を迫る。すなわち、対象言語の値の規則を最初にモデル化せず、エージェントに疑わしい関数の要約を任せる方法だ。モデルは、コードが何をしているように見えるかを説明できる。アナライザーは、許可されたすべての実行が必要な型を実際に尊重しているかを問える。
Falconの発見は、両方の能力を組み合わせたことで生まれた。エージェントが構築を加速し、静的セマンティクスがprover制御データに関する直感を再現可能なチェックへと変えた。
Leanの証明がユニットテストの見落としを発見
形式検証はテストを置き換えたのではなく、未テストだった2件の失敗を明らかにできるほど厳密に振る舞いを定義することをチームに求めた。
Trail of Bitsは、エディタと静的解析ツールを構築した後も形式モデルの開発を進めた。問いは意図的に異なっていた。ライブラリのプロシージャに明白な欠陥がない場合、その実装が意図された算術的振る舞いと一致することをチームは証明できるのか。
同社はLeanで最小限のMiden VM executorを構築した。Leanは対話型定理証明支援系であり、小さな信頼基盤となるカーネルが、提出された証明が定義と前提から導かれるかを検査する。ClaudeはMASMプロシージャをLean表現へ変換するトランスレータの構築にも協力した。
その後、複数のエージェントが並行してプロシージャの証明に取り組んだ。結果として生まれたMASM Lean modelには、実行可能なVMセマンティクス、変換済みプロシージャ、共通の証明支援、および個別の正しさ定理が含まれている。
このリポジトリには、検査済みのプロシージャ証明が95件掲載されている。内訳は64ビット演算が31件、128ビット演算が36件、256ビット演算が17件、word演算が11件だ。これらを合わせると、Trail of Bitsが説明した二進算術部分をカバーしている。
これらは、Midenのあらゆる部分が安全であることを示す証明ではない。特定のプロシージャに対して定義された正しさの性質を扱ったものだ。定理証明支援系が検証するのは与えられた定理であり、開発者の頭の中にある暗黙の意図ではないため、この境界は不可欠である。
そのためTrail of Bitsによれば、人間のレビュー担当者は定理文の監査に注力した。エージェントが重要な事前条件を省いた定理や誤った結果を表す定理を証明しても、カーネルに受理されたことだけでソフトウェアが正しくなるわけではない。
高いレベルでは、多くの定理は分かりやすいパターンに従っていた。特定の入力を含むスタックが与えられたとき、プロシージャを実行すれば終了し、数学的に期待される結果が最上部に残るべきである。呼び出し元が所有する無関係なスタック値は、期待される位置に保持されるべきだ。
こうした仕様への圧力によって、既存のユニットテストが見逃していた2つの欠陥が明らかになった。1つ目は、rotrという64ビット右ローテーションプロシージャに影響した。ローテーション量が32の倍数である場合、Goldilocks primeを上回る大きな入力に対して正しく動作しなかった。
Goldilocks primeはVMが使用するfieldを定義するため、その境界付近またはそれを超える値には慎重な表現が必要となる。証明作業中、問題となるshiftケースを除外する前提を追加しなければ、求める定理は成立しなかった。
証明の失敗は、自動的にコードのバグを意味するわけではない。定理、モデル、または補助補題が誤っている可能性もある。このケースでは、障害となっている部分を手作業でレビューした結果、チームは実装上のエッジケースにたどり着いた。
2つ目のバグは、256ビットのwrapping_mulプロシージャに現れた。Trail of Bitsによれば、同プロシージャは戻る前に呼び出し元が所有する値をスタックから削除していた。乗算結果だけを確認する通常のテストは、周辺のスタック状態が保持されているかを確認しないまま通過する可能性がある。
この欠陥は、厳密な事後条件が重要である理由を示す。プロシージャは正しい数値結果を計算しながら、呼び出し規約に違反し得る。スタックマシンでは、最上部の項目が正しく見えても、隣接する状態を損なえば後続の実行に影響を与える可能性がある。
ユニットテストは依然として中核的な役割を担う。高速に実行でき、既知のリグレッションを防ぎ、まだ形式モデルが存在しない統合動作もカバーする。Leanの取り組みは、明示的に記述された性質に対して別種の保証を提供した。
重要な利点は合成可能性にあった。エージェントは大規模に証明の試行を生み出せる一方、Leanのカーネルは無効な導出を拒否した。人間はモデルの文章上の自信を信頼する必要はなかった。定義を検討し、受理された定理が意図した保証を表していることを確認すればよかった。
これは、生成コードが正しく見えるかを別の言語モデルに尋ねるよりも強力な制御境界である。人間の判断をなくすものではないが、その判断を仕様と前提条件へと移す。
エンジニアリングリーダーにとって、この事例は実践的な役割分担を示唆する。エージェントは反復的な証明の足場、トランスレータ、候補補題を生成できる。人間の専門家は、何を証明すべきかを決定し、重要な命題が失敗する理由を調査する。
この結果は自律型監査を信頼できるものにはしない
このプロジェクトが支持するのはエージェント支援型の監査エンジニアリングであり、監督のないセキュリティ認証ではない。
Trail of Bitsは、経済的な変化を直接的に説明している。数年前であれば、1件のエンゲージメントのために数か月にわたる探索的ツール開発を正当化するのは困難だっただろう。この種の副次プロジェクトは成果が不確実であり、価値が明らかになる前に販売するのも難しかった。
同社は、エージェントが探索コストを十分に下げ、この計算を変えたと主張する。失敗した実験のコストは、専門的なエンジニアリング労働力を丸ごと割り当てることではなく、ますますトークンと監督時間に置き換わっている。
この主張は慎重に読むべきだ。監査までにはなお6か月が経過しており、decompilerだけでも100件を超えるAI生成コミットが蓄積された。公開された説明には、スタッフ時間、総モデルコスト、欠陥発見率を従来型エンゲージメントと比較した統制された比較は示されていない。
また、エージェントがあらゆる特殊な言語に対して同等のツールを構築できることも立証していない。MASMは解析と形式モデル化に適した特性を備えていた。Miden VMは命令セットがコンパクトで、多くの演算は複雑な副作用を避けている。
この有利な対象においても、decompilerはすべてのプロシージャを安全にカバーできなかった。スタック効果の不整合とシグネチャの欠如により、完全かつ信頼できるdecompilationは現実的ではなかったため、Trail of Bitsはサポート対象のサブセットを絞り込んだ。
Leanのワークフローにも別の限界があった。カーネル検査済みの証明が確立するのは、モデル化されたセマンティクスのもとで記述された定理だけである。誤訳された命令、不完全なVMモデル、または弱い定理によって、証明済みの振る舞いと実際のデプロイメントの間には隔たりが残り得る。
人間によるレビューはプロセス全体を通じて明確に存在していた。監査人はエージェント生成コードをレビューし、リグレッションをテストへ変換し、定理文を精査し、失敗した証明を分析した。ClaudeとCodexは、観察されない権威として動作するのではなく、開発とレビューを交互に担った。
これにより、主要な比較はより明確になる。直接的なAIレビューでは、モデルに既存の表現の中で脆弱性を認識させる。ツール構築エージェントは、欠けている制約、無効な型、誤った事後条件を明示できる表現を専門家が作成するのを支援する。
どちらのアプローチも単独で成立すべきではない。モデルは、静的アナライザーが符号化していない仮説を浮かび上がらせることができる。静的解析は、確率的なレビュー担当者が見落とす可能性のある実行パスをカバーできる。形式証明は、その後、選択された性質に対して機械検査可能な基準を提供できる。
このプロセスは保守の義務も生み出す。parserは言語の変更に追随しなければならない。analyzerにはリグレッションスイートが必要である。形式モデルはVMセマンティクスとの整合性を維持しなければならない。古くなった生成ツールは誤った安心感を生み出しかねない。
Trail of Bitsによれば、Midenチームは将来のコアライブラリ更新に向けて静的解析エンジンを採用した。これは、ツールを単一の監査スナップショットの先へ移すため、重要なシグナルである。継続利用によって、言語とライブラリの進化に伴ってもアナライザーが有用であり続けるかが試される。
同様のワークフローを検討する組織は、provenanceも計画すべきだ。チームは、どのモデルが変更を生成したのか、どの人間がレビューしたのか、どのテストが実行されたのか、どの前提が証明に取り込まれたのかを把握する必要がある。engineering workflowは、その周辺に保存された記録と同程度にしかレビュー可能ではない。
したがって、公開された証拠が支持する結論は限定的である。エージェントは、このエンゲージメントにおける野心的な準備プログラムを実現可能にした。セキュリティ保証は依然として、ドメイン専門家、テスト、明示的な分析、証明検査を組み合わせたシステムから得られた。
このシステムは、AIがバグを見つけたという主張よりも興味深い。不完全なエージェントを、その自信を証拠として扱わずに活用するための具体的なモデルを提示している。
この監査モデルが持続するかを試す3つのシグナル
次の試金石は、エージェントが構築した保証ツールが、注目を集めた発見の後も正確さ、採用、そして生産性を維持できるかどうかだ。
最初のシグナルは、MASM analyzerがMidenの開発プロセスに継続的に統合されることだ。Trail of Bitsによれば、Midenチームは将来のコアライブラリ変更に向けて静的解析エンジンを採用した。継続的インテグレーションでの定常的な利用は、監査ツールが予防的なインフラになり得るという主張を強めるだろう。
重要な指標は、どれだけ多くの警告を出すかではない。新しい公開プロシージャがリリース前に必要な検証を受けるか、またanalyzerの更新がMASMセマンティクスの変更を追跡するかである。恒常的な偽陽性や古いモデルは、この結果を弱めるだろう。
2つ目のシグナルは、95件のLean証明の拡張と保守だ。追加の検証済みプロシージャは、初期モデルが固定的な実演ではなく継続的な作業を支えることを示すだろう。既存の算術コードに対する変更も、証明の更新または失敗を引き起こすべきである。
変換されたコードと人手でレビューされた仕様の境界に注目すべきだ。定理のカバレッジを強化せずに証明数だけを増やす自動化は、同じ保証を提供しない。前提条件の明確な文書化は、生の総数と同じくらい重要になる。
3つ目のシグナルは、他の監査チームや言語エコシステムによる再現だ。Midenは、カスタム言語、不足していたツール、明示的な証明セマンティクス、数か月の準備期間という、異例に適した組み合わせを提示した。
異なるzkVMや低レベル言語で同様のパターンが繰り返されれば、Trail of Bitsのより広範な経済的主張を裏付けることになる。並行性、複雑なメモリ、大規模な依存関係グラフを持つシステムで再現できなければ、その限界が明らかになるだろう。
Trail of BitsによるMiden監査は、すでに単なる推測的なワークフローを超える成果を生み出している。エディタ統合、decompiler、analyzer、VMモデル、検査済み証明、具体的なセキュリティ上の発見を提供した。
重要なのは、チームがそれらの成果物を、保護対象のシステムと整合した状態に維持できるかどうかだ。エージェント支援型セキュリティを評価する開発者は、リポジトリを確認し、モデル化された前提を精査し、どこで機械検証可能な統制がモデルへの信頼に取って代わるのかを問うべきである。それこそが、次回の監査に持ち込むべき基準だ。
