Claude Mythos PreviewでFirefoxを強化した舞台裏

 (hacks.mozilla.org)
5 ポイント 投稿者 GN⁺ 2026-05-08 | 2件のコメント | WhatsAppで共有
  • Mozillaは、モデル性能の向上と**ハーネス（harness）**の改善により、AI生成のセキュリティレポートのシグナルを高めてノイズを減らし、Firefoxで実際のセキュリティバグを大規模に見つけるパイプラインを構築した
  • Firefox 150 releaseでは、Claude Mythos Previewが特定した271件のバグが修正され、149.0.2、150.0.1、150.0.2にも関連修正が含まれている
  • 公開された代表的なバグには、JITのWebAssembly GC構造体初期化削除による偽オブジェクトプリミティブ、IPC競合状態による親プロセスUAF、NaN逆シリアライズ問題、XSLTの20年来のrehashバグ、rowspan=0を利用した16ビットレイアウトbitfield overflowなどが含まれる
  • 公開されたバグのかなりの部分はサンドボックス脱出であり、侵害されたコンテンツプロセスが権限のある親プロセスへ権限昇格する状況を前提とするため、ファジングだけでは見つけにくい攻撃面をAI分析がより包括的に扱った
  • Mozillaは既存のファジング基盤の上にagenticハーネスを載せ、再現できない推測を捨ててテストケースで仮説を検証し、今後はパッチがtreeに入る際にスキャンするよう継続的インテグレーションへ統合する計画だ

AIモデルで明らかになったFirefoxセキュリティバグの変化

  • 数か月前までは、オープンソースプロジェクトに届くAI生成のセキュリティバグ報告はもっともらしく見えても誤っていることが多く、メンテナーに非対称なコストを生んでいた
  • Firefoxでは短期間で状況が大きく変わり、モデル性能の向上と、モデルを**ハーネス（harness）**で制御・拡張・結合してシグナルを増やしノイズをふるい落とす手法の改善が主因だった
  • Mozillaは通常、セキュリティ勧告と修正配布の後も詳細なバグ報告を数か月非公開に保つが、今回はエコシステム全体の緊急性と関心を踏まえて一部の報告を公開することにした
  • 公開された報告はブラウザの複数のサブシステムからまんべんなく選ばれており、選定にはある程度の任意性があるものの、その深さと多様性は防御側がこの手法を採用すべき必要性を示している

公開された代表的なバグ

  • 2024918
    • 誤った同値性検査のため、JITが生きているWebAssembly GC構造体の初期化を最適化で削除し、内外の研究者による広範なファジングを経たコードにおいて、潜在的な任意読み書きにつながる偽オブジェクトプリミティブを作り出せた
  • 2024437
    • <legend> 要素に関する15年来のバグで、再帰スタック深度制限、expando属性、cycle collectionなど、ブラウザの離れた領域にあるエッジケースを巧妙に組み合わせて引き起こされた
  • 2021894
    • IPC競合状態を安定して悪用することで、侵害されたコンテンツプロセスが親プロセスのIndexedDB参照カウントを操作し、UAFと潜在的なサンドボックス脱出を引き起こせた
  • 2022034
    • 生のNaNがIPC境界を越える際にタグ付きJSオブジェクトポインタのように見える可能性があり、doubleの逆シリアライズが親プロセスでの偽オブジェクトプリミティブとサンドボックス脱出につながり得た
  • 2024653
    • ネストしたイベントループ、pagehide リスナー、ガベージコレクションを組み合わせた複雑なテストケースにより、<object> 要素の属性setterでUAFを引き起こした
  • 2022733
    • WebTransportに数千個の証明書ハッシュを押し込み、参照カウントの多いコピー処理ループの競合状態を拡大し、侵害されたコンテンツプロセスからIPC経由で親プロセスUAFを引き起こした
  • 2023958
    • glibcのDNS関数呼び出しを横取りして悪意あるDNSサーバーをシミュレートし、UDPからTCPへ切り替わるfallbackのエッジケースを再現して、HTTPS RRおよびECH解析中のバッファ過剰読み取りと親プロセスのスタックメモリ漏えいを引き起こした
  • 2025977
    • 再入可能な key() 呼び出しがハッシュテーブルのrehashを起こしてbacking storeを解放する一方で、生のエントリポインタが使われ続ける20年来のXSLTバグであり、修正された複数のsec-high XSLT問題の1つだった
  • 2027298
    • カラーピッカーにパッチを当てて自動化しにくいユーザー選択をシミュレートしたうえで、同期入力イベントでネストしたイベントループを回し、actor teardownに再入してcallbackが解放中に解放されるようにし、コンテンツプロセスUAFを引き起こした
  • 2023817
    • 侵害されたコンテンツプロセスが任意の壁紙画像を親プロセスでデコードさせることができ、仮想的な画像デコーダ脆弱性と組み合わせるとサンドボックス脱出につながり得た
    • 親プロセスで入力の信頼水準を判断する、自動化しにくい推論が必要だった
  • 2029813
    • Firefox 95の細粒度サンドボックス技術であるRLBoxにおいて、信頼できない側から信頼側へ値をコピーする検証ロジックの隙を利用してサンドボックスを回避した
  • 2026305
    • HTMLテーブルの特殊な rowspan=0 の意味を利用する非常に小さなテストケースで、>65535 行を追加してclampingを回避し、16ビットのレイアウトbitfieldをoverflowさせたもので、何年もの間ファザーに見つからなかった

サンドボックス脱出と防御レイヤー

  • 公開されたバグのかなりの部分はサンドボックス脱出であり、Firefox全体のチェーン侵害に至るには他のエクスプロイトと組み合わせる必要がある
  • こうした報告は、サイトコンテンツをレンダリングするサンドボックス化プロセスが別のバグですでに侵害されており、攻撃者が制御する機械語コードが権限のある親プロセスへ権限昇格しようとする状況を前提としている
  • サンドボックス脱出を作る際、モデルは修正したコードがサンドボックスプロセス内でのみ実行される限り、Firefoxソースコードをパッチできる
  • この種のバグはファジングで見つけにくく、Mozillaはスナップショットを用いたIPCファジングのような手法を開発してきたが、AI分析はこの重要な攻撃面をはるかに包括的に扱えた
  • モデルが見つけられなかった部分も重要だった
    • ここ数年、セキュリティ研究者は、権限のある親プロセスでprototype pollutionを引き起こしてプロセスサンドボックスを脱出する報告を複数送ってきた
    • Mozillaは問題を1件ずつ修正する代わりに、既定でprototypeをfreezeするアーキテクチャ変更を適用した
    • ハーネスのログには、この脱出経路を試みたものの設計により阻止された痕跡が多数見られ、過去の強化策の直接的な効果が確認された

ハーネスでセキュリティ強化パイプラインを構築

  • Mozillaは過去数年にわたり、GPT 4やSonnet 3.5のようなモデルで高リスクコードを静的解析するLLMコード監査実験を社内で進めてきた
  • 初期の実験は可能性を示したが、偽陽性率が高く、規模拡大が難しかった
  • セキュリティ問題を安定して検出するagenticハーネスの登場で状況が変わった
    • 実際のバグを見つけられる
    • 再現できない推測を捨てられる
    • 適切なインターフェースと指示があれば、再現可能なテストケースを作成・実行して、コードバグ仮説を動的に検証できる
  • Mozillaは2月にAnthropicが送った初期の問題を修正した後、既存のファジング基盤の上に独自のハーネスを構築した
  • 当初はClaude Opus 4.6でサンドボックス脱出を探す小規模実験を開始した
    • このモデルだけでも、マルチプロセスのブラウザエンジンコードに対する複雑な推論を要する、従来未知だった脆弱性をかなりの数特定した
    • 最初はターミナルで過程を直接見守りながら、リアルタイムでプロンプトとロジックを調整していた
    • 動作が安定した後は、複数のephemeral VMへ処理を並列化し、各VMが特定の対象ファイルでバグを見つけた後に結果をbucketへ記録するようにした
  • 発見サブシステムだけでは十分ではなかった
    • 何を探すか、どこを見るか、成果物をどう処理するかを含む、セキュリティバグのライフサイクル全体と統合する必要があった
    • 既存イシューとの重複排除、バグ追跡、triage、修正配布まで含まれる
    • モデルはハーネスを動かす中核的なプリミティブだが、スケールして有用にするには全体パイプラインが必要だった
  • ハーネスはプロジェクト間で再利用できる可能性があるが、パイプラインはコードベースの意味、ツール、プロセスに応じてプロジェクトごとに異なる
  • Firefoxエンジニアが流入するバグを処理する流れと密接なフィードバックループを置き、かなりの反復作業が必要だった

Claude Mythos Previewとモデル切り替えの効果

  • エンドツーエンドのパイプラインが整えば、新しいモデルが出た際に別モデルへ差し替えるのは簡単になる
  • Mozillaは公開モデルでも複数の重大バグを見つけており、このパイプラインのおかげでClaude Mythos Previewの評価機会を得たときにすぐ活用できた
  • モデルのアップグレードはパイプライン全体の効果を高めた
    • 潜在バグをよりよく見つける
    • バグを証明する概念実証テストケースをよりうまく作る
    • 病理と影響をよりよく整理する
  • Firefox 150 releaseでClaude Mythos Previewが特定した271件のバグを修正したことに加え、149.0.2、150.0.1、150.0.2にも関連修正が含まれている
  • 社内では他の方法でもバグ発見を続けており、他プロジェクトと同様にここ数か月で外部報告も大きく増えた
  • すべてのバグは適切に修正するために細心の注意を要し、前例のない規模に追いつくため、この数か月は多くの作業と長時間勤務が続いた
  • 100人を超える人々が、これまでで最も安全なFirefoxをリリースするためのコード貢献に参加し、パッチ作成・レビューに加えて、パイプラインの構築・拡張、triage、修正テスト、各バグのリリースプロセス管理が行われた

重要な教訓

  • ソフトウェアを作る誰もが、いまや現代的なモデルとハーネスを使ってバグを見つけ、コードを強化できる
  • シンプルなプロンプトから始めて観察し、反復できる
    • 初期プロンプトはこの動画で示された方式と大きくは違わなかった
    • 反復を通じてパイプライン最適化と拡張のためのorchestrationやツールが多数追加されたが、内部ループの核心は「このコード部分にバグがあるので見つけてテストケースを作れ」だった
  • Firefoxの潜在バグをすべて掘り尽くしたわけではないが、現在の軌道には満足している
  • 現在のスキャンは主として、人の判断と自動シグナルを組み合わせて指定した特定のコード領域、つまりファイルと関数に集中している
  • 近い将来には、この分析を継続的インテグレーションシステムに統合し、パッチがtreeに入る際にスキャンする計画だ
  • モデルは与えられた文脈形式に柔軟に対応し、パッチベースのスキャンはファイルベースのスキャンと同等かそれ以上にうまく機能すると見込まれている
  • 現在は危険な時期でもあるが機会も大きく、インターネットを安全にするため共に動く必要がある

よくある質問

  • 「271件のバグ」とセキュリティ勧告数が異なる理由

    • セキュリティ勧告のWebページでは、内部報告バグを複数のバグがその下に束ねられた「rollup」CVEとしてグループ化している
    • Webページは、CVE割り当ての正式な場所であるfoundation-security-advisoriesリポジトリのyamlから生成される
    • 一部のブラウザは内部発見イシューにCVE識別子を作成しないが、Mozillaは可能な限り透明性を高めるためこれを公開している
    • Firefox 150には内部rollupが3件あった
      • CVE-2026-6784: 154件のバグ
      • CVE-2026-6785: 55件のバグ
      • CVE-2026-6786: 107件のバグ
    • 3件の内部rollupの合計は316件で、Claude Mythos Previewで見つけたと発表した271件より多い
    • 理由は、Mozillaセキュリティチームが日々Firefoxを攻撃して新たなバグを探しており、その方法がファジングシステム、手動検査、複数モデルを活用した新しいagenticパイプラインの組み合わせだからだ
    • 4月リリースでは合計423件のセキュリティバグが修正された
      • 2週間前に発表した271件のバグ
      • 外部報告バグ41件
      • 残る111件は内部発見で、おおむね3種類に分かれる
        • このパイプラインでClaude Mythos Previewを使って見つけたが、Firefox 150ではなく別リリースで修正されたバグ
        • このパイプラインで別モデルを使って見つけたバグ
        • ファジングなど他の手法で見つけたバグ
    • Anthropicには今回の最新作業とは別に、3件のCVEが直接クレジットされている
      • CVE-2026-6746
      • CVE-2026-6757
      • CVE-2026-6758
    • これらは、数か月前にAnthropic Frontier Red TeamがMozillaへ送ったバグ修正であり、通常手順に従ってそれぞれ固有のCVEが割り当てられた

  • セキュリティ深刻度レーティングの意味

    • Mozillaはバグの緊急度を示すためにsecurity severity ratingsをcriticalからlowまで適用している
    • sec-criticalとsec-highは、Webページ訪問のような一般ユーザー行動で誘発されうる脆弱性に付与される
    • sec-criticalとsec-highの間に技術的差はないが、sec-criticalは公に公開された、または実際の攻撃で悪用されたと分かっている問題にのみ使われる
    • sec-moderateは、本来sec-highと評価される脆弱性だが、被害者に異常で複雑な手順を要する場合に付与される
    • sec-lowは、安全なcrashのようにユーザー被害から遠い厄介なバグに付与される
    • Firefox 150で発表された271件のバグのレーティングは次の通り
      • sec-high 180件
      • sec-moderate 80件
      • sec-low 11件
    • Mozillaはcritical/highバグを最重視するが、正確性の問題修正と多層防御のため、moderateやlowのセキュリティバグも優先するのが一般的だ

  • sec-highまたはsec-criticalと実際のエクスプロイトの違い

    • sec-highまたはsec-criticalのバグが、そのまま実用的なエクスプロイトを意味するわけではない
    • 多くの場合、1件のcritical/highバグだけではFirefoxを侵害するのに十分ではない
    • Firefoxは多層防御アーキテクチャを備えており、たとえばJITバグを悪用しても、サンドボックス化されサイトごとに分離されたプロセスでリモートコード実行を得る程度にとどまる
    • 実際の攻撃者は通常、複数のエクスプロイトをチェーン化し、1つ以上のサンドボックス層とASLRのようなOSレベル緩和を越えて権限昇格しなければならない
    • Mozillaは通常、バグが実際の攻撃者に使われ得るか確認するためのエクスプロイトは作成しない
    • sec-high分類は、AddressSanitizerが報告するuse-after-freeやout-of-boundsメモリ問題のような、予測可能なcrash症状に基づく
    • 脅威モデルでは、十分な労力があればこうしたバグが悪用可能になり得ると仮定する
    • この方式は、悪用可能性分析における偽陰性リスクを減らし、より多くの脆弱性を見つけて修正することにリソースを集中させる

関連記事

2件のコメント

 
GN⁺ 2026-05-09
Hacker Newsの意見

  • 繰り返し強調するが、バグはバグだ。「潜在的な脆弱性」もバグであり、脆弱性は概念実証やそれに準ずる証拠によってセキュリティ上の影響が検証される必要がある
    言葉は重要であり、バグも重要だ。多くのバグを修正することは昔から重要であり、実際にやってきたことで、それ自体でも十分に印象的だ
    Mythosが271件の脆弱性について概念実証を書き、セキュリティ上の影響があるコードパスへの到達可能性を証明したわけではない。Mythosは有効なバグ271件を見つけたのであり、それで十分だと思う

    • 定義が少し紛らわしかったが、Mozillaはその271件の「何か」をこう分類していた[1]
      追加の文脈として、Mozillaはバグの緊急度を示すために、criticalからlowまでのセキュリティ深刻度を適用している。sec-criticalとsec-highは、Webページの訪問のような一般ユーザーの行動でトリガー可能な脆弱性に付けられ、技術的には両者を区別しないが、sec-criticalは公開済みまたは実際の悪用が知られている問題のために予約されている
      sec-moderateは、本来sec-highに相当するが、被害者に異常で複雑な手順が必要な脆弱性に付けられ、sec-lowはユーザー被害とは距離のある厄介なバグ、たとえば安全なクラッシュに付けられる
      Firefox 150で発表された271件のバグのうち、180件はsec-high、80件はsec-moderate、11件はsec-lowだった
      Mozillaはすぐ下で、実用的なエクスプロイトと同義ではないと述べながらも、sec-highにも「vulnerability」という言葉を使っている。定義ページではsec-lowでさえ「vulnerabilities」に分類している[2]
      言葉は道具であり、その有用性は集団的な意味から生まれる。その意味体系をどこから受け入れたのか、Mozillaと一致しているのか、それとも異なるのか気になる
      [1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
      [2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
    • Mythosは実際に、use-after-freeや境界外読み書きのようなメモリ安全性違反でクラッシュするすべてのバグについて概念実証を書いていた
      私たちの基準では、反証がない限り、この程度であればセキュリティ脆弱性と見るのに十分な実質的証拠であり、ファジングのバグでも常にそのように扱ってきた
    • Claudeは、ユーザーがそのコードを所有していると信じる場合、自分が見つけた悪用可能なバグについて概念実証エクスプロイトを作ることができ、実際に作る
      出典は個人的経験だけで、証拠は共有できない
    • 何を先に処理するかを決めなければならない現場では、こうした区別は通用しない
    • 「脆弱性向けPoC 271件」でないなら、探している言葉はエクスプロイトに近いように見える

  • 先の非技術的なブログ記事は、Anthropicのための露骨な製品宣伝だと片付けていた。リンク先のMozilla Hacksの記事はこの話題についてこの記事よりよい出典であり、歓迎すべき公開資料だ
    いまや、何らかの実際の成果があることを否定するのは難しそうだ。Mozilla内部での「脆弱性」の定義は、多くの人が直感的に考えるより広く適用されているようだが、こうした問題が真剣に受け止められ修正されるのはよいことだ

  • 元ソース: https://news.ycombinator.com/item?id=48051079
    実際に公開されたBugzillaレポートの一部を列挙しているので、よりよい。これは以前にも一度議論された話題だが、バグレポートが公開されたという点は完全に新しい
    前回の議論は2週間前で、コメント数は36件だった: https://news.ycombinator.com/item?id=47885042

  • LLMがバグを見つけて修正するのがあまりに得意になって、Firefoxエンジニアが新機能追加だけに集中できる日が来るといい
    皮肉ではない。Firefoxはもっと使われるに値する。周囲の大半は「Chromeがほぼすべてをよりうまくやる」ことを理由にFirefoxを使わず、Firefoxは他のブラウザーのロードマップと競争するのが難しい

    • Firefoxがもっと使われるべきだという点には完全に同意する。サイトで購入するときも、Firefoxで動くかどうかでどこで買うかを選ぶほどだ
      ときどきサポートに、Firefoxがサポートされていない、あるいは機能が正しく動かないと書くこともある。ほぼいつも何も起きないが、ブラウザーをどうにか視界の中に残すために自分にできることだと感じている
    • 問題の一部は、バグ修正をやめるとMozillaがMr. Robot的なことを始める点だ。私たちはただのWebブラウザーが欲しい。PocketやAIを求めた人はいなかった
      AIですべてのバグを直したら、複数のビルド言語との構文互換性を維持すること以外に何が残るだろうか。結局またブラウザーを台無しにする方向へ戻りそうだ
    • そうした品質と可用性こそが、ChromeをFirefoxよりずっと速く先に進ませるのではないかと思う
      Mozillaが社内専用の独自LLMやハーネスを作ってChromeより先に進むなら話は別だが、それも現実的にはあまり見えない
    • Chromeは、ユースケースの99%以上で意味のあるほど優れているわけではない。自分は開発者だが、ここ10年ほどFirefoxとuBlock Originだけを使ってきた
      妻も説明を聞いてインターネット体験がどれほど変わるか理解してからは、Firefoxをメインブラウザーにしている
      だから「独占は悪くGoogleは少し邪悪だから、劣勢の弱者を使ってほしい」という言い方はしないでほしい。自分が投げ込んだあらゆる作業でFirefoxは一級の体験だったし、モバイルではその3倍くらいそうだ。断然もっとも有用なモバイルブラウザー体験だ
    • ブラウザーにはずっと昔から新機能は必要なかった。そういうものは拡張機能が解決策であるべきだった

  • リンクされているチケットは数件だけなので、271件の実際の個別項目をすべて見れば印象は変わるかもしれないが、私が見たものはすべてC++コードの深刻なバグだった
    Firefoxは複数言語で書かれていて、C++は約25%にすぎないが、これらの問題はどれもC++に触れているように見える

    • このアプローチの一般的な限界は、バリデーターが優れている範囲でしか優れていないことだ。たとえばAddressSanitizerほど、use-after-freeを起こすテストケースで検証しやすいものはない
      より微妙な問題には、より具体的なバリデーターが必要なのか、それともLLMが自分で検証すべき別の危険条件をよりうまく思いつくようになるのか、見守る必要がある
    • Mythosが他の言語よりC++の脆弱性をはるかにうまく見つける可能性はある。こうしたモデルも既存のセキュリティ分析資料をもとに作られているからだ
      私には、これらのバグのかなりの部分はC++固有の問題というより、たまたまC++コードで発生したものに見える。最も安全なRustでも、TOCTOUのような問題を魔法のように捕まえられるわけではない
    • バグをAddressSanitizerで検証したため、構造的にC++バグしか見つからないようになっていた

  • Zig界隈の人たちがLLM生成バグをレビュー対象にすらしたがらない態度とこの記事をあわせて読むと、今後自分のツールチェーンにどんな技術を入れるかを見る視点が変わる

    • どちらも正しく、どのモデルを使うかと、誰がバグを提出するかにかかっている。先端モデルの能力は、数か月の間に99%ノイズから99%有効なバグへと変わった
      ある種のプロジェクトは前者であふれていて、メンテナーに対する実質的なDoS攻撃にならないよう防止策が必要だ

  • PalmSourceにいたとき、CoVerityやFortifyのような静的コード解析ツールの予算を取ろうとしたが、管理ラインは「高すぎる」と言った
    さらに1年かけてコストを下げ、ネットワークスタックのスキャンに限定した案を作ったが、今度は「BSDベースで、BSDは本質的に安全だ」と言われた。どちらも事実ではない
    結局会社を辞めてMozillaに行ったところ、コードのあちこちに/* flawfinder ignore */コメントが散らばっていた
    私の推測では、Mythosはflawfinder ignoreディレクティブを無視して、コード内の既知の脆弱性を報告しただけではないかと思う

    • コードは公開されている。それが事実だと証明できれば、本当のニュースになるだろう

  • これが静的解析ツールにどんな影響を与えるのか気になる。性質はかなり異なるが、ときどき同じ目標を達成する
    静的解析ツールは遅いことがあり、誤検出も多い。こうしたモデルが十分によくなり、安くなれば、人々は静的解析をほとんど使わなくなるのだろうか

    • LLMはツールを置き換えることより、ツールを使うことにはるかに優れている。同じ結果をLLMで得ようとするより、既存のツールを使う方が普通はずっと速い
      LLMコーディングツールで静的解析ツールの出力を継続的に片付けるやり方は非常によく機能し、問題が残らないよう強制するガードレールを追加するのもよい考えだ。すべてがクリーンか確認するCIチェックのようなものだ
      誤検出はツール次第だ。大半がノイズしか出さないツールは避ける傾向があり、そうしたツールはたいていノイズの多いルールを無効にできる。あるいはLLMにすべての問題を直させればよい。ルールと議論するより直す方が安いなら、ただ直せばいい。昔は人が直接やる必要があり非常に高くついたが、今はそうではない
      最近数年間手を付けていなかったAnsibleコードベースを更新するときにこの方法を使った。ansible-lintの問題が数百件あり、そのほとんどは廃止予定警告と致命的でない警告だったが、10分後には0件になっていた。深刻な問題ではなかったかもしれないが、一種の技術的負債だった。数百件の警告を手作業で直さなければならないなら、おそらくやらなかっただろうが、魔法の杖を一振りして消せるなら、やらない理由はない。今ではガードレールを調整して常にansible-lintを走らせ、問題を直すようにしており、数秒余分にかかるだけだ
    • 興味深い可能性は、LLMが最初に見つけたバグの形を静的解析ツールが見つけられるよう強化することだ[0]
      静的解析ツールがより速く安いことには疑いの余地がなく、巨大なコードベースによりよくスケールし、LLMの手法を一般化できる可能性もある
      [0] https://lwn.net/Articles/1068968/
    • 静的解析ツールははるかに高速にできるし、大半は完全に決定的なので、CIに入れればバグや潜在バグがコードベースに入る前に捕まえられる
      Firefox CIで使っている静的解析ツールを保守している。私たちのツリーにパッチを入れるには、誤検出であれ真陽性であれすべて修正するか、問題ではないとマークしなければならない。つまり陽性を0件まで許容する必要があり、かなり厳しい基準だ
      これは意識的なトレードオフだ。人々が無視したり全部コメントで消したり、あるいはそもそも実行を止めたりしないよう、十分なシグナル対ノイズ比を確保するには解析を弱め、一部の見逃しを受け入れなければならない。ほぼすべての静的解析ツールがこうしたバランスを取る必要がある
      一方、一般的に使われるAIにはもっと余地が与えられている。誤検出を幻覚することを許容しなければならない点はほぼ本質的で、それが力のかなりの部分でもある。だからその上に複数の検証・確認レイヤーが必要になる。遅いかもしれないし、「この特定形式のエラーを100%捕まえる」とは言えないが、それでも膨大な量を捕まえる
      一つのデータポイントがある。自分の解析は、本物のバグになる可能性が低いと誤って考え、しかも実装も面倒に見えたあるケースを扱っていなかった。OpusかMythosかは定かでないが、それがそのケースに由来する脆弱性を報告し始め、私は急いで解析を拡張して穴を埋めた。実装にはかなり時間がかかり、ソースツリー全体をスキャンした時点では、Claudeが報告した重要な問題はすでにすべて見つけ終わっていた。静的解析はさらにいくつか見つけたが、その中に実際にトリガー可能なものがあるかは、正直いまでも分からない
      それでも静的解析には価値があると思う。問題パターンの一部の発生箇所は、今でもAIが構成するには難しすぎる経路を通って到達可能かもしれない。別のコードが変われば実際の問題になることもありうる。両方の可能性に備えて今のうちにすべて直しておく価値はあるし、AIがそれらを悪用しようとして時間を浪費しないようにするという、より重要度の低い理由もある。同時に、費用対効果のバランスが明らかに変わったのも事実だ
      両者は協力もできる。自分の基準を緩め、解析ツールに疑わしい問題について追加の警告レポートを書かせ、誤検出である可能性を明示したうえで、その一覧をAIに渡して検証させることができる。要するにスロップをスロップ機械に食わせて、その中の原石を非決定的にふるい分けさせるようなものだ
      考える価値はある
    • こうしたハーネスは静的解析ツールを使っているはずであり、今後もおそらくそうだろう

  • 最新のMission Impossibleでは、脱走した超人的AGIの原本ソフトウェアを沈没したロシア潜水艦から回収しなければ世界を救えない
    Lutherは、原本ソースが与えられればAIを即座に一撃で終わらせる「poison pill」を書く。この魔法のようなコードがどう書かれたのか不思議だったが、今なら分かる。Luthorは単にMythosのプロンプトにソースコードを渡し、変更不可能な致命的エクスプロイトを要求したのだ

  • 人々が、LLMが5年後にソフトウェアをより安全にするのか、より危険にするのかをどう見ているのか気になる

    • おそらくいくつかの種類の問題を消し去るだろうし、それはよいことになりそうだ。そして依然として安全でないものは別の言語へ移すこともできる
      LLMが登場する前から、Rustへの手動移植の流れはあった。いまやLLMのおかげで、その作業はより簡単で速くなるだろう。長期的な価値は、既存のC/C++コードベースという山のような技術的負債を片付けることから生まれる。これらのコードはメモリエクスプロイト、バッファオーバーフロー、その他の問題の圧倒的大多数を担っており、何十年も注意が払われてきたにもかかわらず、主要なコードベースで見つかり続けている
      Mozillaがこうした問題を見つけたのは、非常に有能なエンジニアたちが25年にわたり正しいことをしようと努め、利用可能なあらゆるツールでこうした問題が起きないようにしてきた、その積み重ねの上に成り立っている。そのチームと、長年にわたりツール、テスト、検証慣行の改善に貢献してきたことを大いに尊重している。問題は彼らの努力や能力ではない
      テストが整い、文書化と仕様が行き届いた既存システムを受け取り、ドロップイン置換実装を作る作業が、いまやレビュー可能なものになった。数年前なら莫大なプロジェクトコストとリスクにつながっていただろうが、今では金曜の午後に始めてみられるようなことだ。最悪でも失敗するだけで、最善ならはるかによい実装が得られる
      まだ初期段階で、LLM生成コードには品質上の問題が多い。しかし成功率と失敗率は時間とともに改善する可能性が高い
    • 両方だ。熟練者は問題を見つけるために使い、未熟な者は熟練者が直さなければならない危険なスロップコードを作るために使うだろう
    • ホームセンター、電動工具、簡単に手に入るハードウェア、YouTubeチュートリアルが、驚くほど優れた頑丈な家具を作れるようにもしたが、雑で醜く、果ては危険な家具も作れるようにしたのと似ている
      より多くの人により多くの道具が渡れば、より広い範囲のものがより多く作られる
    • より安全なソフトウェアにはなるだろうが、それは疫病の後で人口が純健康化するのに似た形になると思う
    • 適切に適用される場合には、より安全になるだろう
      ただし、こうしたツールを適用しないプロジェクトに対しては、ブラックハットが悪用する機会もより得やすくなるという意味でもある
 
GN⁺ 2026-05-08
Lobste.rsの意見

  • この作業で使ったプロンプトや他の機能も公開してほしい
    再現できるように、バグレポートや修正履歴にプロンプトを含めるとよさそう
    非Mythosモデルにも触れていたので、この作業の一部は他の人にもすぐ役立ちそう

    • たいていのプロジェクトでは参入障壁は本当に低い
      基本的には「このプロジェクトをセキュリティ問題の観点でレビューし、(ファイル)から始めて、考えられる経路をすべて列挙してほしい」と頼み、その後各項目について「このレポートを検証して概念実証を作ってほしい」と続ければよい
      今はOpusを使えば、こういうやり方で何かを見つけられないほうが難しい
    • プロンプトが「このコードベースでセキュリティ脆弱性を見つけてほしい」以上のものだと思う？

  • 何と言おうと、これは本当に印象的だ
    Mythosで271件のセキュリティ問題を見つけ、全体では423件を見つけた
    そのうち180件は重大度が高く、一部のセキュリティ問題は20年来のものだった

    • Opus 4.6 / Mythos比較がどれほど公平だったのかは完全には明確ではない
      以前に4.6で同様にスキャンしたコードで、Mythosが「271件のバグ」を見つけたかのように示唆されているが、記事が正確にそう言っているわけではない
      研究用ハーネスにも同時に変更があったのか気になる

  • 「私たちが修正した複数のsec-high問題のうち1つはXSLT関連だった」という部分は、XSLT削除論争があるので入れたのだと思う

  • ここでいちばん気になるのは、偽陽性がどれくらい報告されたのかという点だ
    モデルが潜在的な脆弱性を2倍ほど多く報告していて、ここに出ているのが確認済みのものなのか気になる
    モデルが報告する前に再現までしているのかもわからない
    公開されている問題を見ると再現を試みているようなコメントが見えるが、既存のボットがやったものかもしれない
    Firefoxがもともとこうした作業をどう処理していたのか、そして今はAIと一緒にどう進めているのかをよく知らないので、もっと詳しい説明があればとても興味深いと思う