trueNetLab logo
JA
Mythos の後で:バグバウンティにより強い証拠が必要になる理由

Mythos の後で:バグバウンティにより強い証拠が必要になる理由

3 min read
Ai Security Sophos

数週間前、私は Anthropic Mythos と Project Glasswing について書きました。その時の主題は大きな流れでした。もしモデルが古い脆弱性を見つけ、exploit の経路を組み合わせ、codebase 全体を理解する能力を本当に高めるなら、vulnerability research は変わります。

Sophos の新しい記事は、Mythos 時代のバグバウンティについて、その運用面を見せています。

問題はもはや、AI がより良い脆弱性を見つけるかどうかだけではありません。バグバウンティプログラム、security チーム、engineering 組織が、ゴミ、もっともらしい主張、本物のセキュリティ問題を十分な速さで見分けられるかどうかです。

Mythos の時代に価値があるのは、最も大きな声の report ではなく、最もきれいに再現できる report です。

本当の問題は AI slop だけではない

AI とバグバウンティの話をすると、今はすぐに slop が思い浮かびます。自動生成された reports、半分だけ理解されたエラーメッセージ、作り話の exploit chain、再現できない主張、そして中身の少ない長い文章です。

これは現実です。そして maintainer、product security team、triage をする人にとって非常に厄介です。

しかし、それは一面でしかありません。

もう一つの面のほうが危険です。優れた研究者は同じモデルを使って、本物の脆弱性をより速く見つけ、大きな codebase に対して仮説を試し、あるパターンのバリエーションを体系的に確認できます。以前なら数日から数週間の手作業が必要だったことが、将来は数時間でキューに入るかもしれません。

つまり問題は移動します。以前の問いはよく「十分に良い外部 findings を得られているか」でした。今後は「ノイズが増える中で、本物の findings を十分速く見つけ、検証し、優先順位を付け、fix に変えられるか」になります。

Sophos がここで興味深い理由

Sophos の記事は、AI についての一般論ではありません。Sophos は自社のバグバウンティプログラムを振り返り、具体的な数字を示しています。

Sophos によれば、公開プログラムは 2017 年 12 月から Bugcrowd 上で運用されています。記事時点までに、1,343 件の脆弱性に報奨金が支払われ、総 submissions は 7,091 件、総支払額は 599,695 米ドルだったと書かれています。

2025 年について、Sophos は次のような数字を挙げています。

  • 52 件を超える reports に対して 59,400 米ドルを支払い
  • 約 420 人の研究者が参加
  • 条件付きで Intercept X Endpoint に最大 80,000 米ドル
  • Sophos Central に最大 50,000 米ドル
  • Sophos Firewall に最大 50,000 米ドル
  • 2025 年の Sophos Firewall で 13 件の有効な bugs、総支払額 21,500 米ドル
  • 2025 年の Sophos Central で 13 件の有効な bugs、総支払額 11,650 米ドル

これは天文学的な数字ではありません。だからこそ興味深いのです。比較的成熟したプログラムの裏に、どれだけの選別作業があるかを示しています。数千件の submissions は、数千件の関連するセキュリティ問題を意味しません。そして AI は、おそらくこの比率を楽にはしません。

むしろ厳しくします。

再現性が入場券になる

私にとって最も重要な結果は、単純ですが不都合です。きれいに再現できない security report の価値は下がります。

triage チームが怠けているからではありません。彼らの時間がさらに不足するからです。

ある report が remote code execution、auth bypass、重大なデータ漏えいを示すと主張するなら、次の点を明確に証明する必要があります。

  • 影響を受ける version
  • 必要な configuration
  • 攻撃者に必要な権限
  • 結果に再現可能に到達する手順
  • 主張を支える logs、requests、traces、screenshots
  • 実際に証明された impact
  • 推測と証拠の境界

これは厳しく聞こえます。実際に厳しいです。しかし security teams がもっともらしい文章に溺れないためには必要になります。

AI が生成した report は、言語的には非常に説得力があるように見えます。コードを引用し、CVE 風に書き、きれいな構造を装うことができます。しかし、それは真実であることを意味しません。逆に、短く乾いた report でも、優れた proof of concept があれば非常に価値があります。

新しい通貨は言い回しではありません。新しい通貨は証拠です。

AI は authorization bugs を特に厄介にする

Sophos の記事で、私にとって特に実務的に感じた点があります。AI は、見つかった authorization bypass を、より広い scope の表面へ拡張する助けになります。

これは実際の SaaS 環境でよく見るものと合っています。Authorization は単一のスイッチではありません。roles、tenants、object IDs、subdomains、API versions、admin surfaces、mobile endpoints、legacy routes、半分だけ移行された features の中に存在します。

研究者が一つのパターンを見つけたとき、AI はそのバリエーションを体系的に確認する助けになります。

  • bypass は一つの endpoint だけに効くのか、それとも endpoint family 全体に効くのか
  • 一つの tenant 内だけか、tenant をまたいでも動くのか
  • 同じ logic が古い API と新しい API の両方にあるのか
  • admin と user の roles は本当にどこでもきれいに分離されているのか
  • UI では表示されない object を直接 ID で読み込めるのか

まさにここで AI は危険なほど役に立ちます。魔法の hacker としてではなく、退屈で広く体系的な検査を加速するものとしてです。

そしてこれは、「誰も退屈なバリエーションを全部試す時間がない」ことに強く依存している組織にとって悪い知らせです。

バグバウンティは PR メールボックスではない

多くの会社は、まだバグバウンティを半分イメージ施策のように扱っています。プログラムがあるから、自分たちはオープンで、現代的で、security-minded だというわけです。

それではもう足りません。

バグバウンティプログラムは本番システムです。明確なルール、良い triage、技術的な再現、製品との近さ、engineering の責任、incident response との接続が必要です。そうでなければ、外部研究者、AI slop、本物の攻撃者が同じ入り口を使う公開メールボックスになってしまいます。

Sophos は記事の中で、二つの不都合な点を結びつけています。

第一に、良い研究者は助けになります。外部の視点、異なる思考パターン、継続的な圧力は価値があります。

第二に、お金と信頼のあるシステムは悪用されることもあります。Sophos は Pacific Rim、Asnarök、Personal Panda に関する経験に触れています。そこでは active exploitation と後の bug bounty reports の時間的な近さが、少なくとも疑問を生みました。Sophos は、そのような report がすべて悪意あるものだったとは明言していません。しかし運用上のポイントは残ります。バグバウンティプログラムは naive に作ってはいけません。

具体的にはこういうことです。

  • Reports は telemetry と相関させる必要がある。
  • 新しい finding は、過去にさかのぼる threat hunts を起動できるべき。
  • triage は、似た exploit 試行がすでに見えていたかを知る必要がある。
  • 研究者の reputation は役に立つが、技術的検証の代わりにはならない。
  • Safe harbor は重要だが、abuse detection の代わりにはならない。

これが冷静な現実です。バグバウンティは Secure by Design の一部であり、代替物ではありません。

より強い証拠は、より強い責任も意味する

ここには、簡単に丸め込むべきではない緊張があります。

歴史的に、研究者にはよくこう言われてきました。十分早く止まってください。bug は示してください。でも深く入りすぎないでください。顧客データに触れないでください。lateral movement はしないでください。破壊的な操作はしないでください。

それは正しいです。

同時に、証明責任は重くなります。AI が大量に、もっともらしいが誤った reports を生成するなら、プログラムはより多くの evidence を求めます。そこで難しい問いが生まれます。研究者は危険な行動に踏み込まずに、impact をどうより強く証明できるのか。

答えは「もっとやればいい」ではありません。答えは、より制御された形であるべきです。

  • より明確な Rules of Engagement
  • 専用の test environments
  • 安全な reproduction paths
  • 合意された impact proof の境界
  • より良い sandbox と lab systems
  • proof of concept の自動 replay

大きなベンダーにとって、これはほぼ必須になります。高額な bounties を真剣に払うなら、reports をきれいに速く検証するインフラも必要です。

小さなプロジェクトには、これはより苦い話です。同じ slop の波を受けますが、同じ resources はありません。だから一部のプロジェクトは金銭的な bug bounties を減らすか、完全に止めるでしょう。安全を軽視しているからではなく、プログラムの運用自体が負担になるからです。

Admin と MSP が学べること

これは vendor と Bugcrowd プログラムだけの話だと言うこともできます。

私はそうは思いません。

同じ仕組みは MSP、社内 IT チーム、security 責任者にも当たります。外部または内部 findings を評価する必要がある場所では、どこでも圧力が高まります。

  • Scanners はより多くの findings を出す。
  • AI assistants は findings をより説得力を持って説明する。
  • Developers は AI-generated security notes を持ってくる。
  • Customers は文脈を知る前に CVEs について尋ねる。
  • Management は risk が本物か、ただ声が大きいだけかを知りたがる。

実務的な答えは、すべて無視することではありません。答えは、より厳しい validation process です。

少なくとも、私は次の問いが必要だと思います。

  1. 問題は再現できるか。
  2. 影響を受ける scope は明確か。
  3. 現実的な attacker path はあるか。
  4. impact は技術的に証明されているか、それとも主張だけか。
  5. exploitation を示し得る logs や telemetry はあるか。
  6. fix は patch、configuration、workaround、それともただの応急処置か。
  7. すでに悪用されていないか、過去にさかのぼって探す必要があるか。

これは仕事が増えるように聞こえます。実際に増えます。でも、よく書かれた report のたびに慌てて反応するより、ずっと良い仕事です。

なぜ Mythos とよくつながるのか

私にとって Mythos の重要な点は、「すごい、モデルが bugs を見つける」ということだけではありませんでした。

重要なのは、こうした能力がより現実になると、発見、理解、再現、利用の間の時間が短くなることです。まさにそこがバグバウンティプログラムに当たります。そこは research、attack potential、engineering、responsibility の交差点です。

Sophos も自分たちの記事で同じように表現しています。問いは、AI submissions をどう止めるかではありません。良い研究とノイズの両方が機械の速度で作られるとき、どう trust と signal を保つかです。

私にとって、これは問題の最もきれいな要約です。

すべての組織に大きなバグバウンティプログラムが必要なわけではありません。しかしすべての組織には、技術的な主張を検証するより良い仕組みが必要です。security information の洪水は小さくなりません。より速く、より大きく、より上手に書かれるようになります。

私の見方

私は Sophos の記事を Mythos の良い follow-up だと思っています。議論をモデルの部屋から運用の部屋へ移しているからです。

Mythos は目立つ signal です。バグバウンティ triage は、security processes が追いつけるかどうかを示す作業台です。

私の主張はシンプルです。

  • ただ reports を多く集める人は負ける。
  • 再現可能な evidence を求める人は、より良く優先順位を付けられる。
  • bug bounty、telemetry、engineering、incident response をつなげる人は、より速く反応できる。
  • AI を text generator としてだけ見る人は、体系的な security work における価値を過小評価している。
  • AI slop をフィルタしない人は、本物の問題を解くべき人の時間を燃やしてしまう。

これは frontier model が zero-days を見つける話ほど華やかではありません。しかし、security gain が defenders に届くのか、それとも全員がさらに多くのノイズに沈むのかは、まさにそこで決まります。

また次回、
Joe

参考資料