Keone HonによるUltrafuzz推進でMonadのOpSec懸念が焦点に
Monad共同創業者のKeone Honは、開発者にUltrafuzzの採用を促す一方、セキュリティはコントラクトコードのバグ発見にとどまらないと警告している。Keone HonによるUltrafuzzの推進は、AI支援テストと、ソフトウェアを取り巻くアカウント、デバイス、プロセスを保護する運用セキュリティ（OpSec）を組み合わせるものだ。安全なコントラクトであっても、その管理権限を持つ人物に依存するため、この組み合わせは重要である。
crypto.newsによると、Honは10月30日にセキュリティ関連リソースを共有し、別途、開発者にUltrafuzzでコントラクトをテストするよう促した。この呼びかけは、既存のオープンソースプロジェクトへの関心を新たにするものだ。新製品の発表を意味するものでも、ツールの有効性を独自に検証するものでもない。
中心的な緊張関係は、自動化された調査と、なお開発者に残る運用上の責任にある。Trail of BitsのEchidnaのような既存ツールは、すでにコントラクトの挙動をテストしている。Ultrafuzzはその作業にAIによる調整を加える一方、自身のドキュメントでは、価値の高い認証情報の近くで制約のないエージェントを実行しないよう警告している。採用を検討するチームは、そこで得られる検出結果と、それを安全に生み出すために必要な環境の両方を評価しなければならない。
Keone HonによるUltrafuzz推進が既存のセキュリティ施策を再び注目させる
直近のニュースは、新たにリリースされたセキュリティ製品ではなく、Honによる採用の呼びかけが改めて行われたことにある。
Crypto.newsは10月31日、Honがコントラクトテストを推進するとともに、従業員のデバイス、認証情報、管理権限、第三者アカウントを扱うガイダンスを紹介したと報じた。同報道は10月30日の彼の投稿を再掲し、開発者にUltrafuzzの実行を促す別の呼びかけについても説明している。こうしたセキュリティ上の推奨事項は、ソフトウェアレビューをより広範な運用規律の中に位置づけている。
この区別は、読者が今回の発表をどう解釈すべきかを変える。新リリースであれば、新たに加わった機能、移行要件、旧バージョンからの変更点が問われることになる。一方、改めての呼びかけは、採用状況、実用性、既存リソースが必要とするチームに届いているかという問いを生む。
Honのメッセージは、組織が時に別々の担当者に割り当てる責務も結び付けている。開発者はコントラクトの挙動を調査し、他の担当者はアカウントの管理、コンピューターの運用、機微な操作の承認を行う。特に管理操作がソフトウェアの挙動を変え得る場合、セキュリティ上の結果は、こうした責務がどう結び付くかに左右される。
スマートコントラクトは、プログラムされたルールに従って実行される、ブロックチェーン上にデプロイされたソフトウェアである。一部のコントラクトには、アップグレードやその他の管理作業のための特権機能も含まれる。ルールをレビューすることと、それを変更する権限を保護することは、異なる障害経路に対処する。どちらか一方で成功しても、もう一方の成功を示すものではない。
だからこそ、この物語ではOpSecの資料がテストツールと並んで位置づけられる。報道で紹介されたHonの推奨事項は、専門的なAI防御だけでなく、通常の業務慣行を対象としている。それらが含まれることで、コードのレビュー後にプロトコルを支える人々とシステムへ注意が向けられる。
報道上の境界も明確にある。Honの元のX投稿は今回のレビュー中に直接取得できなかったため、彼の最近のコメントは、それを再掲した報道に帰属したままである。ツールの公開ドキュメントは、その存在と運用モデルについて別個の証拠を提供している。
この呼びかけ自体からは、どれほど多くのチームがこのガイダンスを採用したかは測れない。また、利用者が署名の慣行を変えたことや、これまで知られていなかった弱点を修正したことも示されない。公開、推進、利用、実証された効果は、依然として別々の段階である。
読者にとって意味のある展開は、これらを組み合わせた要請にある。Monadはビルダーに対し、ソフトウェアをより広範に調査すると同時に、そのソフトウェアを取り巻く権限も検証するよう求めている。こうした要請が行動変化につながるかどうかは、リソース一覧の共有を超えた取り組みにかかっている。
圧力は監査と日常業務を切り離すチームにかかる
Honの呼びかけは、アカウントと管理アクセスを管理する人々を含め、プロトコルを運用する組織に責任を課す。
コントラクトレビューは、定義されたソフトウェア対象を調査する。一方、組織は人員の入れ替わり、新たな依存関係、権限変更、業務慣行の改訂を通じて、その対象の周囲で変化し続ける。完了したレビューを恒久的なセキュリティ状態として扱うことは、こうした継続的な判断を見落とす。
レビュー済みのコードと、アップグレードを承認する権限を持つアカウントがあるプロトコルを考えてみよう。権限のない人物がそのアカウントを掌握した場合、レビューは組織の承認プロセスを強制できない。この仮説は、正しいソフトウェア挙動と、特権的権限の正当な行使との境界を示している。
同じ考え方は従業員のコンピューターにも当てはまる。開発者は、同じマシン上で無関係なソフトウェアや通信を扱いながら、コントラクトロジックに注意深く取り組むことができる。その結果生じる露出は、コントラクト自体が意図どおりに挙動していても、業務環境に属する問題である。
報道で説明されたガイドは、デバイスの分離、認証情報の運用、トランザクション署名前の確認を通じ、この周辺環境に対処する。その推奨事項は、新規のAI機能に依存しない。チームに対して、通常の責任を明確にし、日々の業務で維持することを求めるものだ。
これにより、個々の開発者と同じくらい、創業者やエンジニアリング責任者にも圧力がかかる。誰が機微な操作を承認できるのか、どのデバイスがそれを支えるのか、不審な活動をどう報告するのかを、誰かが決めなければならない。こうした決定には、別の自動スキャンではなく、責任の所在が必要となる。
Honは、より能力の高い攻撃者を防御強化の理由として示しており、AIが議論を変えている。これは彼が述べた根拠であり、AIが特定のインシデントを引き起こした証拠ではない。攻撃へのAI関与を立証するには、攻撃自体に関する証拠が必要である。
より強い帰属がなくても、運用上の含意は有用であり続ける。チームが実行するセキュリティ作業量を増やすために自動化を採用するなら、アクセスを巡る明確なルールも必要となる。調査を増やしても、アカウント、デバイス、署名手順を通じて露出する権限が自動的に減るわけではない。
この圧力は、プロトコルを評価する購入者やパートナーにも及ぶ。ソフトウェアが自動テストを受けたという説明は、組織がそれを安全に運用できるかどうかより狭い問いに答えるものだ。レビュアーは、何が調査され、どの責任がその調査の対象外に残ったのかを理解する必要がある。
例えば、コントラクトの挙動に関する報告は、従業員の復旧プロセスが保護されていることを示すものではない。保護されたアカウントに関する説明も、会計ロジックが通常と異なるトランザクションの連続を正しく処理できることを示すものではない。対象範囲が明確であれば、どちらの説明も有用になり得る。
このため、Honの組み合わせたメッセージは、単にツールを試すよう求めるものより厳しい。それはチームに、技術的な調査と運用上の説明責任を整合させるよう求める。実務上の問いは、特に各専門家が別の誰かが対応すると想定している場合に、これらの活動の間にあるリスクを誰かが担っているかどうかとなる。
Ultrafuzzは既存のテスト手法を中心に調査を調整する
Ultrafuzzの提案は、エージェントが調査する問いと、各段階の間で引き渡す証拠を含め、セキュリティ作業を組織化することに関わる。
Monadの9月10日のオープンソースリリースでは、スマートコントラクトの記述に使われるプログラミング言語であるSolidityとVyperのサポートが説明されている。20回を超えるエコシステムでの実行経験がリリースに反映されたとしている。これらは保護の独立した指標ではなく、同財団の開発上の主張である。
多様な入力を生成して予期しない挙動を探すテスト技法であるファジングは、このワークフローの一部を成す。不変条件とは、システムが到達する状態を通じて真であり続けるべき条件である。そうした条件を定義することで、調査に検証すべき具体的な問いが与えられる。
重要な設計上の選択は、入力生成の前に行われる。システムには、意図された挙動、関連する利用者、有意な障害条件について有用な説明が必要だ。その説明が不完全なら、大規模なテストは誤った問いを徹底的に調査することになり得る。
Antonio Viggianoによる9月21日の技術的ウォークスルーは、このプロジェクトがチームの外部セキュリティレビュー準備を支援する目的から始まった経緯をたどっている。彼はファジングテストの不足と、作業の一部を自動化する取り組みについて説明している。彼の説明では、Ultrafuzzはセキュリティエンゲージメントを支援するものとして位置付けられている。
このワークフローは、プロパティを調査する前に参加者と行動を対応付ける。例えばレンディングアプリケーションでは、借り手、貸し手、清算人が異なる操作を通じて相互作用する。こうした関係を理解することで、調査者は孤立した操作ではなく、一連の操作に関わる障害を推論しやすくなる。
個々の操作の後には条件が成立していても、複数の相互作用を経た後には失敗することがあるため、この順序は重要だ。有用な調査は、システムの変化する状態を考慮しなければならない。障害について説得力のある説明を生成することは、その障害が起きる証拠を示すこととは異なる。
既存のテストツールは、すでにこの問題の一部に対処している。Trail of BitsはEchidnaをプロパティベースのファザー、Medusaを並列スマートコントラクトファザーとして説明している。そのコントラクトテストツールには、アプリケーション全体を実行せずにコードを検査するSlitherも含まれる。
したがって、この比較は単純な置き換え競争ではなく、ワークフローの範囲に関するものだ。Echidnaは与えられたプロパティのテストに焦点を当てる。Ultrafuzzは、準備と解釈を含め、対象を中心により広範な調査を調整しようとする。組織はなお、プロパティの質と得られた証拠を評価しなければならない。
Viggianoの説明では、エージェントが先行するエージェントの出力に依存する際の困難にも触れられている。これは、調整されたワークフローが有用な情報だけでなく、誤りも引き継ぐことを意味するため重要だ。プロセス初期の誤った前提は、別の段階で検証されない限り、その後の作業に影響を与え得る。
採用者にとっての重要な問いは、この調整によって、より少ない専門家の労力でレビュー可能な結果が得られるかどうかである。その答えには、実際のキャンペーンを検証する必要がある。長大なレポートや精緻なワークフロー図だけでは、調査がプロトコルにとって最も重大な障害経路を網羅したことを示せない。
自動化された検出結果にも再現可能な証拠が必要
セキュリティ上の検出結果を信頼するために必要な証拠は、もっともらしい警告を生成するために必要な証拠より具体的である。
AI生成レポートは、対象がそれを許容することを示さずに、現実的な障害を説明できる。逆に、前提が関連する挙動を除外しているため、調査が障害を見逃す場合もある。ツールの評価には、裏付けのない検出結果と見落とされた弱点の両方への注意が必要となる。
再現手順とは、明示された条件下で報告された障害を確実に示すテストまたは手順である。レビュアーにとって、それは説明を観測可能な挙動へ結び付ける。この結び付きがなければ、チームは警告が適用されるかどうかを判断するために追加の労力を費やさなければならない。
対象となるリビジョンも重要です。開発中にはソフトウェアが変化するため、以前のバージョンに関する指摘が、デプロイ予定のバージョンをもはや正確に表していない可能性があります。報告には、別のレビュー担当者が、どのコードと前提条件からその結果が得られたのかを特定できるだけの文脈が必要です。
これらの要件は、人間によるレビューにもAIシステムにも当てはまります。自動化は、チームが直ちに調査できる数を超える候補の指摘を生み出せるため、さらなる負荷をもたらします。その出力の価値は、確立された不具合と未解決の疑いをどれだけ明確に区別できるかにも左右されます。
したがって有用な評価では、指摘が現れた後に何が起きたかを問います。開発者は再現したのか。チームは根本的な問題を受け入れたのか。修正は実証された挙動に対処したのか。こうした問いは、自動化された発見をエンジニアリング上の成果へと結び付けます。
ツール間の比較にも、同様に慎重な境界設定が必要です。対象、モデルの選択、プロンプト、利用可能なリソースの違いは結果を変え得ます。複数の条件を同時に変える比較では、どの設計上の選択が見かけ上の改善を生んだのかを切り分けられません。
独立した研究は、導入上の課題に文脈を与えます。研究 Human Side of Fuzzing は、スマートコントラクト開発ツールキットであるEchidnaとFoundryに関する381件のGitHub issueを調査しました。この研究は、実務者がこれらのシステムを利用する際に直面する困難を調べたものです。Ultrafuzzを評価したものではありません。
ここで重要なのは、利用可能な技法と実用可能なワークフローの違いです。ツールは現実の技術的ニーズに対応できても、セットアップ、解釈、保守の作業を依然として課すことがあります。AIによる協調は、発見結果だけでなく、こうした負担も踏まえて評価すべきです。
これにより、Ultrafuzzに対する公正な基準が生まれます。開発者は、完全な網羅性や普遍的な優位性を主張せずとも、有用な証拠を提示できます。明確に範囲を定めた事例、再現可能な不具合、失敗した実行についての率直な説明は、外部の人々がワークフローの寄与する領域を判断する助けになるでしょう。
これに対応する懐疑的な見方は、AI支援による調査を退けることを求めるものではありません。「このシステムは問題を見つけた」から「このシステムはセキュリティを確立する」へと飛躍することに抵抗するよう求めるものです。これらの主張には異なる証拠上の要件があり、後者は単一のキャンペーンの範囲を超えます。
Keone HonのUltrafuzz推進を評価するチームにとって、実務上の帰結は明快です。導入は、他者が検査し異議を唱えられる成果物を生み出すべきです。信頼は、関与したエージェントの数ではなく、そうした成果物とその解決から育まれるべきです。
無制限の権限を持つエージェントにより、運用環境自体が評価の一部となる
Ultrafuzz自身の警告は、隔離をテスト開始後に検討する細部ではなく、責任ある評価の条件としています。
プロジェクトのagent security warningは、通常のワークステーションから分離されたソフトウェアベースのコンピューターである、使い捨ての隔離された仮想マシンを推奨しています。そこでは、エージェントが制限のない権限で動作すると明記されています。また、価値あるデータや認証情報を含む環境を避けるよう警告しています。
この警告は、ツールを試すことの意味を変えます。開発者は、貼り付けたコードについて単にコメントを求めるのではなく、環境内でソフトウェアに行動を実行させることになります。その環境で利用可能な権限は、評価の一部となります。
隔離は、意図しない行動がもたらす結果に対処します。すべての生成された指摘が正しいことや、関連するすべてのコントラクトの挙動に注意が払われることを保証するものではありません。運用上の封じ込めと分析上の正確性は、どちらもキャンペーンの有用性に影響する場合であっても、依然として別個の要件です。
この区別は、機密コードにも当てはまります。隔離されたマシンは、分析に必要な機密プロジェクト資料を保持しつつ、無関係なファイルへのアクセスを制限できます。チームは、選択した構成全体を通じて、その資料がどのように扱われるかを理解しなければなりません。
これは、組織がすでに外部ソフトウェアをレビューするための規則を持っている場合に特に重要です。セキュリティツールも、リポジトリにアクセスする他のソフトウェアと同じ意思決定プロセスを経るべきです。その防御的な目的は、その権限を理解する必要性をなくすものではありません。
ここには、Ultrafuzzがユーザーのワークステーションを侵害したと主張する根拠はありません。文書化された警告は、明示されたリスクとデプロイメント上の境界を示しています。これを、特定の有害な出来事が発生したとの非難に置き換えるべきではありません。
より有用な解釈は、説明責任に関するものです。誰かが環境を準備し、そこに何を入れるかを決定し、得られた成果物をレビューしなければなりません。キャンペーンの自動化された段階は、こうした責任をなくしません。むしろ、機械の活動と人間の判断の間にある引き継ぎを、より重要なものにします。
ここで、ツールとOpSecへの訴えが最も直接的に交わります。AIを使ってコントラクトを調査するチームは、その調査にも運用上の規律を適用しなければなりません。さもなければ、セキュリティワークフローを、他の場所で求めている実践の例外として扱う危険があります。
同様の製品を評価する組織にとっては、調達上の含意もあります。デプロイメント要件は、対応言語やレポーティング機能と並んで比較に含めるべきです。ツールの有用性は、組織がアクセスと機密保持の要件に沿ってそれを運用できるかどうかにも左右されます。
ここから生じるトレードオフは具体的です。より大きな自律性により、エージェントは絶え間ない介入なしにより多くの作業を実行できますが、その環境は自律性がもたらす結果を制限しなければなりません。適切な評価は、準備、実行、レビュー、廃棄を含むキャンペーン全体を考慮します。
したがって、Keone HonのUltrafuzz推進は、開発者がキャンペーンを開始するかどうかだけでは判断できません。より強い導入の兆候は、チームが文書化された境界に従い、結果に対する明確な責任を保持していることを示すものです。ソフトウェアを実行することは、それを適切に利用することの一部にすぎません。
検証済みの指摘、継続的な利用、運用上の変更に注目する
次に必要な証拠は、自動化された調査を、修正、継続的な利用、そして機密性の高い運用に対するより強い統制と結び付けるものです。
最初に注目すべき兆候は、独立して再現可能な指摘です。今後数か月のうちに、どの対象を調査したのか、どの挙動が失敗したのか、別のレビュー担当者がどのように確認したのかを示す詳細な開示が行われる可能性があります。そうした証拠は、このワークフローが候補となる警告の生成を超えて寄与しているという根拠を強めるでしょう。
受け入れられた修正は、もう一つの有用なつながりをもたらします。公開された指摘は、デプロイ済みのシステムに影響を与えなくても興味深い場合があります。開発者が問題を理解し修正したことを示す証拠は、発見がどのようにエンジニアリング作業へと変換されたかを示すでしょう。
公開された開示がないことは、失敗を証明するものではありません。チームは修正の間、指摘を機密に保つ場合があり、開示のタイミングも異なり得ます。しかし、それは外部の観察者にとって、有効性を独立して判断するための証拠が少ないことを意味します。
二つ目の兆候は、初期トライアルを超えた継続的な利用です。コード変更後にチームがこのツールに戻ることは、一度限りのデモとは異なる導入の兆候を示します。繰り返しの利用は、そのワークフローが継続的な開発プロセスに適合していることを示唆するでしょう。
ユーザーが必要な労力を説明すれば、この兆候はさらに強まります。セットアップの難しさ、失敗したキャンペーン、レビュー時間、有用な出力に関する記述は、他のチームが適合性を評価する助けになります。無条件の称賛よりも、ワークフローがどこで役立ったかを明確に説明するほうが、実務的な情報を多く提供します。
リポジトリへの注目だけでは、これらの問いには答えられません。一般の関心は、本番利用ではなく、好奇心、宣伝、研究を反映している可能性があります。導入に関する主張は、完了したタスクと、その結果のレビューを担った人々を説明する場合に、より有益になります。
三つ目の兆候は、技術テストと並行した運用上の変更です。Honのより広範な訴えに従うチームは、特権アクセス、署名の取り決め、機密性の高い作業の分離を見直すでしょう。こうした行動は、メッセージがコントラクト分析を超えて届いたという主張を支えるものです。
キャンペーンの報告書だけでは、そのような変更が行われたことを示せません。証拠は、機密性の高い詳細に適切な配慮をしつつ、プロトコルを運用する組織から得る必要があります。セキュリティを真剣に扱うという大まかな主張よりも、明確な責任の所在と文書化されたプロセスのほうが意味があります。
これらの兆候は、同じ命題の異なる部分を検証します。検証済みの指摘は分析上の有用性を評価します。継続的な利用は実務上の適合性を評価します。運用上の変更は、より強力なテストに、ソフトウェアを管理するシステムに対するより強い統制が伴うかを評価します。
開発者にとって、直ちに取るべき行動は、キャンペーンを始める前に、そのワークフローの導入を正当化する証拠を定義することです。誰が指摘をレビューするのか、不具合をどのように再現するのか、どの環境がプロジェクトの運用要件を満たすのかを特定してください。購入者やパートナーは、得られる報告書が実際に何を対象とし、どの責任がその範囲外に残るのかを尋ねるべきです。Keone HonのUltrafuzz推進は、これらの問いを再検討する有用な理由を与えます。文書化された境界を読み、自組織の実践と比較し、次のセキュリティ演習が、より良い証拠と、その証拠だけでは解決できないリスクに対するより明確な責任の所在の両方を生み出すかを問いかけてください。
