Blog Dice

Refactoring English: Month 17

Michael Lynch

Refactoring English：17か月目

一行まとめ

本の執筆に集中すべきか、バグバウンティを追いかけるべきか？

ハイライト

  • 本の執筆に集中すべきか、セキュリティのバグバウンティを追うべきかで迷っています。
  • AIを使ってセキュリティ脆弱性を見つける方法について、これまで学んだことを教えるコースの開講を検討しています。

目標の達成度

毎月初めに、その月に達成したいことを宣言しています。目標に対する結果は次のとおりです。

Refactoring Englishの執筆を完了する

  • 結果：あと1〜2週間ほど執筆が残っています
  • 評価：C

もうすぐ終わりそうだと何度も感じているのですが、ついバグバウンティに予定より時間を取られてしまいます。

Refactoring Englishの指標

指標2026年3月2026年4月増減
ユニーク訪問者数6,9322,578-4,354 (-63%)
予約販売による収益$725.80$587.73-$138.07 (-19%)

本の収益は減少しました。3月以来マーケティングをまったく行っていないためです。その代わりにバグバウンティ探しに気を取られていました。これまでの努力の貯金でなんとかしのげていますが、このままマーケティングを怠れば数字はゼロに向かって落ちていくだろうと感じています。

バグバウンティプログラムに取り組んだ3か月間

ここ3か月間、AIを使ってセキュリティ脆弱性を見つけることに多くの時間を費やしてきました。これまで公に語ってこなかったのは、数が限られたバグバウンティプログラムに競合を呼び込みたくなかったからです。他の人たちがAIによるセキュリティ研究の有効性にどれほど気づいているか分かりませんでしたが、もはや秘密は隠しきれない状況だと思います。

AIとセキュリティ研究の動向を追っていない方のために説明すると、Firefoxは驚くべき事例です。2025年を通して（まだAIがセキュリティ研究で使い物にならなかった時期）、Mozillaと外部の研究者を合わせても、毎月10〜20件のセキュリティ脆弱性がFirefoxで見つかる程度でした。

2026年2月、AnthropicはClaude Opusを使ってFirefoxの脆弱性を22件発見しました。つまり、その1か月だけでAnthropic1社が、過去13か月のどの月よりも、他の全員を合わせた数を上回る脆弱性を見つけたことになります。その2か月後、AnthropicはClaude Mythosを使って、さらに271件もの脆弱性をFirefoxで発見しました。

私自身、ある程度早い段階でこの流れに気づいてはいましたが、少し見当違いをしていました。1月の時点では、AIがサイバーセキュリティ研究に革命を起こすかもしれないと考えていましたが、その価値はセキュリティツールを作ることにあると思っていました。私はAIにファズテスト用のツールを作らせて、その出力を評価させる形でファズテストを行っており、手作業で行っていたときと比べてどれほど速くテストできるかに驚いていました。

ファズテストツールを10〜20倍の速さで書けるようになったにもかかわらず、私の戦略は必要以上に手間がかかるものだったことが分かりました。AIにファズテストツールを作らせて出力を評価させるのではなく、AIに「ソースコードを見て、脆弱性をすべて教えて」と直接頼めばよかったのです。

AIがソースコードを直接監査する能力の高さを目の当たりにしてからは、ファズテストをやめてソースコード監査に集中するようになりました。これまでに5つの異なるバグバウンティプログラムに50件以上のバグを報告し、約1万ドルの報奨金を得ています。

バグは見つけやすくなったが、バウンティプログラムは難しくなった

AIを使ってセキュリティ脆弱性を見つけることには成功しましたが、その発見に対して報酬を支払ってくれる企業を見つけることには、あまり成功していません。

これまでの結果は次のとおりです。

  • ベンダー1：Meta
    • リモートコード実行の脆弱性1件を含む8件を報告しました。
    • 数週間、まったく返答がありませんでした。
    • その製品に携わった開発者のメールアドレスを探し出して連絡したところ、トリアージを通過するようエスカレーションしてもらえましたが、それから2週間以上、動きがありません。
  • ベンダー2
    • 1件を報告しました。
    • ベンダーは1営業日でトリアージしましたが、本格的な調査には数週間かかるとのことでした。
    • 30日以上、何の連絡もありません。
  • ベンダー3
    • 1件を報告しました。
    • ベンダーは重複報告だとして、報奨金の対象外としました。
  • ベンダー4
    • 40件ほど報告しました。
    • うち8件は2週間後に支払いが確定し、合計で9,700ドルになりました。
    • 2件は重複として却下されました。
    • 残りはすべてトリアージ待ちですが、最も価値の高いものはすでに支払い済みの最初の8件に含まれていました。
  • ベンダー5：Firedancer（暗号資産プロジェクト）
    • 中程度の深刻度の脆弱性をいくつか見つけました。
    • 報告手続きを始めようとしたところ、聞いたこともないサービスにパスポートをアップロードする必要があることが分かり、そこで断念しました。
    • プログラム規約も、使用しているバウンティプラットフォームの規約と矛盾しているように見え、内容があやふやです。

ベンダー4からの1万ドルは、パートタイムで2週間の作業で得られたものです。もし他のバウンティプログラムに6週間以上を費やして報酬がゼロでなかったなら、非常に良い投資だったと言えます。ベンダー4のようなところをもっと見つけられれば素晴らしいのですが、その方法が分かりません。

本に集中すべきか、バグバウンティに集中すべきか？

今、時間を本とバグバウンティのどちらに割くべきか迷っています。考えていることは次のとおりです。

  • 本に集中する
    • メリット：本はほぼ完成しているので、集中して仕上げれば、中途半端な状態よりはるかに価値のあるものになります。
    • メリット：本は私にしか作れないものですが、バグバウンティには誰でも参加できます。
    • メリット：すでに本の公開が遅れているので、完成させれば読者をお待たせしている罪悪感が軽くなります。
    • メリット：本については公に話すことができ、考えを整理できるだけでなく、新しい読者に本を知ってもらうきっかけにもなります。
    • デメリット：本の期待値は、少なくとも短期的にはバグバウンティより低く感じられます。理論上は来週にも10万ドルの脆弱性を見つけられるかもしれませんが、来週までに本の売上で10万ドルを生み出すような施策は考えにくいです。
  • バグバウンティに集中する
    • メリット：2週間のバグバウンティで得た収益は、2025年1年間の本の収益を上回りました。
    • メリット：AIツールで見つけられる、まだ発見されていない報奨金対象のバグが大量に残っています。
    • メリット：数か月休めば、他の研究者が簡単に見つかるバグを次々と報告してしまうため、残されたバグの価値は大きく下がってしまいます。
    • デメリット：バグバウンティへの参加はフラストレーションが溜まります。ベンダー側が低い金額を提示したり、対応を反故にしたりしても、こちらには交渉の余地がほとんどありません。悪用目的でエクスプロイトを売るのでなければ、対抗手段がないのです。
    • デメリット：バグバウンティ探しはギャンブルのように中毒性があります。報酬がランダムに現れるからです。
    • デメリット：バグバウンティはAIの良くない使い方に逆戻りさせます。バックグラウンドでAIエージェントにバグを探させていると、常に進捗が気になってしまい、初期の結果に基づいて指示を出し直したくなります。
    • デメリット：バグバウンティでは、公開できる内容が大きく制限されます。プログラムの規約で求められることもありますし、自分が力を入れている領域に競合を呼び込みたくないという理由もあります。

理屈で考えれば、バグバウンティを追い続ける理由を正当化するのは難しいのですが、それでも少しは続けたいと思っています。割合で言えば、本が70％、バグバウンティが30％くらいでしょうか。

AIによるソフトウェアセキュリティ向上を教えるべきかもしれません

3つ目の可能性として、バグバウンティを追う代わりに、この数か月で学んだAIを使ってセキュリティ脆弱性を見つける方法を教えることを考えています。

オープンソースプロジェクトでバグを探す、少人数のコホート型コースの開講を考えています。バウンティのないプロジェクトを選ぶことで、受講生が報酬を誰かに横取りされる心配なく、発見を内部で共有できるようにします。形式は、ライブまたは録画のスクリーンキャストと、2〜4週間のプライベートなグループチャットを組み合わせたものになる予定です。

このコースはバグバウンティで稼ぐ方法が主題ではありません。多少は触れるかもしれませんが、そこが焦点ではありません。この3か月で私が最も学んだのは、そういうことではないからです。

コースの主題は、AIを使って大規模なコードベースからセキュリティ脆弱性を見つける方法です。AIにバグがありそうな箇所に絞って注目させ、無駄な調査やトークンの浪費を避けるために私が学んだテクニックを紹介します。これらの知見は、社内のクローズドソースのコードにも、堅牢化したいオープンソースプロジェクトにも応用できます。

ご興味のある方は、以下のリストにご登録ください。

おすすめ

Timelinizeでソーシャルメディアから自分のデータを取り戻す

数週間前、redditで質問を見かけました。Facebookのアカウントを削除したいが、データを再利用可能な形式で保存しておきたいという内容でした。それを見て、以前Hacker Newsで見かけたものの、あまり深く調べていなかったTimelinizeというプロジェクトを思い出しました。

Timelinizeは、FacebookやGoogle、Twitterなどのサービスからエクスポートしたデータを取り込み、統一されたタイムラインで閲覧できるようにするアプリです。作者は、人気のリバースプロキシであるCaddyの作者でもあるMatt Holt氏です。

Timelinizeはまだアルファ段階という印象で、私も使いやすくするためにローカルで多くのパッチを当てました。ただ、今後の方向性には期待しています。今後も使いながら、私のパッチをさらにupstreamに還元していく予定です。

これまでクラウドサービスに頼っていたことを、ローカルで動かすソリューションに置き換えると、妙にすがすがしい気分になります。ストリーミングサービスからJellyfinに乗り換えたときも、誰かに見られている感覚なく、ただ自分が見たいものを観るという感覚が、こんなにも違うものかと驚きました。企業に「どうすればもっと課金させられるか」と観察されることがなくなったのです。

不思議なことに、NetflixやHBOを観ていたときは、「監視されている」と意識することはありませんでした。しかし、テレビや映画を完全にローカルで観るようになってからは、ずっと窮屈なオフィスの小部屋にいたのに、外の世界があることすら忘れていたような感覚でした。そして外に出て、新鮮な空気と日差しを味わったのです。比喩的な意味ですが、文字どおりには今も屋内でパソコンでテレビを観ています。ただ、以前よりずっと速く、自由になったと感じます。

Timelinizeでも同じような「新鮮な空気を吸う」体験をしました。Timelinizeのインターフェースはユーザー本位に作られており、それによってクラウドプラットフォームのインターフェースがいかにユーザーに敵対的かが分かります。FacebookやTwitterは、過去のメッセージをただ遡って読まれることを望んでいません。収益にならないからです。読ませないために、あえて読み心地を悪くしています。会話を小さな枠に押し込め、数秒ごとに新しいメッセージの読み込み待ちを強制し、常に気を引く通知を表示して収益化できる新しいコンテンツへ誘導するのです。

Timelinizeでは、アーカイブを読む体験が、ただ読むことに集中できるよう設計されています。過去のスナップショットを表示するだけなので、注意を奪って新着をチェックさせようとする仕掛けがありません。10年前のある日にジャンプして、当時の会話を読み返すのが楽しいです。

Timelinizeのインターフェースでは、通知で注意を奪われることなく会話を読み進められます。

React2Shellの物語とNext.jsで起きたこと

当時は追っていませんでしたが、React2ShellはReact.jsの深刻な脆弱性で、多くのReact.jsやNext.jsアプリで攻撃者にコード実行を許すものでした。

先週、React2Shellを発見した2人の研究者が、その舞台裏について書きました。

Lachlan氏の記事の方が注目を集めましたが、当時20歳の大学生だったSylvie氏の記事の方が私は興味深く感じました。

Lachlan氏とSylvie氏は、自分たちが何百、何千もの主要なウェブサイトに影響を与える「核爆弾」を見つけたことに気づきました。Reactを管理するMetaとNext.jsを管理するVercelにバグを報告した後、この巨大なバグに対して報酬を支払ってくれる他のバグバウンティプログラムを探したいと考えました。

研究者は、Metaがセキュリティアドバイザリを公開するまで、他のベンダーにバグを開示できません。問題は、React2Shellが公開された途端、同じ報奨金を求めて殺到する他の人たちに対して、Lachlan氏とSylvie氏の優位性が失われることでした。

先手を打つために、Sylvie氏はバグが非公開の期間にバグバウンティプログラムを調査し、それらのベンダーのサイトがReact2Shellに対して脆弱かどうかを確認しました。そうすることで、Metaが脆弱性を公表した直後に、これらのサードパーティの報奨金を確保できるようにしたのです。

問題は、React2Shellが公開される前に、Vercelが同社のウェブアプリケーションファイアウォール（WAF）にこのバグ用のフィルターを作成し、顧客のサイトが脆弱なバージョンのReactやNext.jsを動かしていても保護されるようにしていたことでした。MetaとVercelはCloudflareなどのWAFプラットフォームとも連携し、React2Shell攻撃のフィルタリング方法を共有していました。

そのため、MetaがReact2Shellを公表した後、Sylvie氏が事前に調査しておいたサイトに対してバグを再現しようとしても、exploitは発動しませんでした。バグバウンティのあるサイトのほとんどがCloudflareやVercelを利用していたため、WAFがSylvie氏のexploitをブロックしてしまったのです。

そこでLachlan氏とSylvie氏は、React2Shellを発動させるためにCloudflareとVercelのWAFをすり抜ける方法を考えなければなりませんでしたが、エンタープライズ向けWAFをバイパスするのはそれ自体が大規模な研究テーマです。幸いにも、Sylvie氏はCloudflareのWAFで1件、VercelのWAFで5件のバイパス方法を見つけました。

興味深いことに、Sylvie氏が得た報酬の「大半」は、React2Shell自体ではなくWAFのバイパスによるもので、Vercelは報告1件あたり5万ドルを支払ったそうです。

まとめ

できたこと

  • 新しい章「AIで文章を改善する」と「読者のいる場所に寄り添う」を公開しました
  • AIを使って文章を改善する方法について、読者とのライブセッションを開催しました
  • バグバウンティプログラムを通じて多数のセキュリティバグを報告しました

学んだこと

  • 長期的には、セキュリティのバグバウンティよりも本に集中する方が自分にとって良い結果につながります。
    • 難しいのは、バグバウンティは短期的な報酬が大きいのに対し、本の報酬は投資から少なくとも1か月は遅れて現れることです。
  • クラウドサービスからローカルで動くものへ移行するのは、想像以上に満足感があります。

来月の目標

  • Refactoring Englishを「コンテンツ完成」まで持っていきます。
  • Refactoring Englishの読者が本を読みながらフィードバックを送れるツールを作ります。

お願い

チームのコードに対してAIを使ってセキュリティ脆弱性を見つける方法に興味がある方は、ぜひ参加希望リストにご登録ください。十分な関心が集まれば、コースを準備します。

原文は Michael Lynch により に公開されました。

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。