一行サマリー

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

ハイライト

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

目標の成績表

毎月のはじめに、その月に達成したいことを宣言している。その目標に対してどうだったかは次のとおりだ。

Refactoring Englishを書き上げる

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

もうすぐ終わりそうな気がずっとしているのに、ついバグバウンティに予定以上の時間を費やしてしまう。

Refactoring Englishの指標

3月以降まったくマーケティングをしていないため、本の収益は下がった。その代わり、バグバウンティ探しに気を取られていた。過去の積み重ねでなんとか持ちこたえられているのはありがたいが、このままマーケティングを怠れば数字はゼロに向かって落ちていくだろう。

3ヶ月間のバグバウンティ・プログラム

ここ3ヶ月ほど、AIを使ってセキュリティ脆弱性を見つけることに多くの時間を費やしてきた。これまで公に語ってこなかったのは、数が限られたバグバウンティ・プログラムに競争相手を呼び込みたくなかったからだ。他の人たちがAIのセキュリティ研究における有効性にどれほど気づいているのか確信が持てなかったが、もう隠しきれる段階ではないと思う。

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

2026年2月、AnthropicはClaude Opusを使ってFirefoxの脆弱性を22件見つけた。つまり、その月だけでAnthropic1社が、過去13ヶ月のどの月よりも多くの脆弱性を、それまで全員で見つけていた合計を上回る数だけ発見したのだ。2ヶ月後、AnthropicはClaude Mythosを使って、さらに驚くべきことに271件もの脆弱性をFirefoxで見つけた。

自分もこの流れを比較的早く察知していたつもりだが、少し見当違いをしていた。1月の時点では、AIがサイバーセキュリティ研究に革命を起こすかもしれないと思いつつも、その価値はセキュリティツールを作ることにあると考えていた。AIにファズテスト用のツールを作らせて、手作業でやっていた頃と比べてどれだけ速くファズテストができるかに驚いていた。

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

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

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

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

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

• ベンダー1: Meta
  • 8件報告した。うち1件はリモートコード実行の脆弱性だった。
  • 数週間まったく返答がなかった。
  • そのプロダクトに携わった開発者のメールアドレスを見つけて連絡し、トリアージを通過するようエスカレーションしてもらったが、その後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エージェントにバグ探しをさせていると、常に進捗が気になって、初期の結果に基づいて指示を変えたくなってしまう。
  • デメリット: 仕事について公に共有できることに大きな制約がかかる。バウンティ・プログラム自体がそれを求めることもあるし、同じ領域に競合を呼び込みたくないという理由もある。

理屈で考えれば、バグバウンティを追いかけ続ける理由を正当化するのは難しいが、それでも少しは続けたい気持ちがある。せいぜい本7割、バグバウンティ3割くらいの配分で。

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

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

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

このコースはバグバウンティで稼ぐ方法が主題ではない。その話も少しは触れるかもしれないが、中心ではない。ここ3ヶ月で自分が最も学んだことではないからだ。

コースの主題は、大規模なコードベースでAIを使ってセキュリティ脆弱性を見つけることだ。AIツールにバグがありそうな箇所に焦点を当てさせ、見込みのない調査に時間やトークンを浪費させないためのテクニックを紹介する。これらの知見は、自社のクローズドソースのコードに内部で適用することも、セキュア化を手伝いたいオープンソースプロジェクトに応用することもできる。

興味があれば、以下の関心リストに登録してほしい。

• 先行関心リスト - AIでセキュリティ脆弱性を見つける

おすすめ

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

数週間前、redditで質問を見かけた。Facebookアカウントを削除したいが、データを扱いやすい形式でアーカイブとして残したいという内容だった。それで、Hacker Newsで見かけたもののあまり深掘りしていなかったTimelinizeというプロジェクトを思い出した。

Timelinizeは、FacebookやGoogle、Twitterなどのサービスからエクスポートしたデータを取り込み、データを探索するための統合タイムラインを作成してくれる。作者は人気のリバースプロキシCaddyの作者でもあるMatt Holtだ。

Timelinizeはまだかなりアルファ段階という感じで、使えるようにするためにローカルで多くのパッチを当てる必要があったが、方向性は気に入っている。使い込むにつれて、自分のパッチをもっとアップストリームに送るつもりだ。

これまでクラウドサービスが必要だったものに対して、ローカルでオフラインな代替手段を見つけるたびに、奇妙なほど清々しい気分になる。ストリーミングサービスからJellyfinに乗り換えたとき、企業に監視されて金を搾り取られる方法を探られることなく、ただ純粋に観たいものを観る感覚がどれほど違うかに驚いた。

奇妙なことに、NetflixやHBOを観ていたときは「ああ、監視されている」などと意識したことはなかった。だが、テレビや映画を完全にローカルで観るようになってからは、オフィスのキュービクルに長くいすぎて外の世界があることすら忘れていたような感覚だった。そして外に出て、新鮮な空気と日差しを楽しんだ。比喩的に、だが。文字どおりには、相変わらず屋内でパソコンでテレビを観ていたわけだが。でも、以前よりずっと速く、ずっと自由だった！

Timelinizeでも同じように「新鮮な空気を吸う」ような体験をした。Timelinizeのインターフェースはユーザー本位に作られており、クラウドプラットフォームのインターフェースがどれほどユーザーに敵対的かを気づかせてくれる。FacebookやTwitterは、古いメッセージをただスクロールして読んでほしいとは思っていない。そんなことをしても彼らの儲けにならないからだ。古いメッセージを読ませないように、彼らは体験をさりげなく不快にしている。会話を小さなボックスに押し込み、数秒ごとに新しいメッセージの読み込み待ちで立ち止まらせ、気を散らす通知を常に見せて、マネタイズできる新しいコンテンツへと誘導する。

Timelinizeでは、読書体験がただアーカイブを読むためだけに設計されている。新着をチェックさせようと注意を奪うものは何もない。Timelinizeが示すのは過去のスナップショットだからだ。10年前の日付に飛んで、当時どんな会話をしていたかを読むのが楽しい。

React2Shellストーリーと、Next.jsで次に起きたこと

当時はReact2Shellを追っていなかったが、これはReact.jsの深刻な脆弱性で、多くのReact.jsやNext.jsアプリで攻撃者がコード実行を可能にするものだった。

先週、React2Shellを発見した2人の研究者が舞台裏で何が起きたかを書いた。

• 「The React2Shell Story」 by Lachlan Davidson、脆弱性発見を主導した研究者。
• 「The React2Shell Story and What Happened Next.js」 by Sylvie Mayer、Lachlanとともに脆弱性の調査、ベンダーへの通知、そして脆弱性に対して報酬を払ってくれるバグバウンティ・プログラムの特定を支援した人物。

Lachlanの投稿のほうが注目を集めたが、個人的にはSylvieの投稿のほうがより興味深かった。特に、当時彼女が20歳の大学生だったことを考えると。

LachlanとSylvieは、自分たちが何百、何千もの主要サイトに影響する「核爆弾」を見つけたことに気づいた。Meta（Reactのメンテナ）とVercel（Next.jsのメンテナ）にバグを報告した後、彼らはこの巨大なバグに対して報酬を払ってくれる他のバグバウンティ・プログラムを探したくなった。

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

先手を打つため、Sylvieはバグのブラックアウト期間中にバグバウンティ・プログラムを調査し、それらのベンダーのサイトがReact2Shellに対して脆弱かどうかをチェックした。そうすることで、Metaが脆弱性を発表した途端に、SylvieとLachlanはこれらのサードパーティの報奨金を請求できるようにしたのだ。

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

そのため、MetaがReact2Shellを発表した後、Sylvieが事前に目星をつけていたサイトでバグを再現しようとしても、脆弱性は発動しなかった。バグバウンティのあるサイトのほぼすべてがCloudflareかVercelを使っていたため、WAFがSylvieのエクスプロイトをブロックしてしまったのだ。

そこでLachlanとSylvieは、React2Shellを発動させるためにCloudflareやVercelのWAFをすり抜ける方法を考えなければならなくなった。だが、エンタープライズ向けWAFをバイパスするのはそれ自体が巨大な研究プロジェクトだ。幸い、SylvieはCloudflareのWAFで1件、Vercelのもので5件の異なるバイパスを見つけた。

興味深いことに、Sylvieの収益の「大半」はReact2Shell自体からではなく、WAFバイパスによるものだった。Vercelは報告されたバイパス1件あたり$50kを支払ったからだ。

まとめ

何をやり遂げたか？

• 新章「Improve Your Writing with AI」と「Meet the Reader Where They Are」を公開した
• AIを使って文章を改善する方法について読者向けライブセッションを開催した
• バグバウンティ・プログラムを通じて多数のセキュリティバグを報告した

学んだこと

• 長期的には、セキュリティのバグバウンティよりも本に集中するほうが自分にとって良い。
  • 難しいのは、バグバウンティは短期的な報酬が大きいのに対し、本の報酬は投資から少なくとも1ヶ月は遅れてやってくることだ。
• クラウドサービスから自分で運用するローカルなものへ移行するのは、意外なほど満足感がある。

来月の目標

• Refactoring Englishを「コンテンツ完成」の状態に持っていく。
• Refactoring Englishの読者が読みながらフィードバックを送れるツールを作る。

協力のお願い

AIを使ってチームのコードからセキュリティ脆弱性を見つける方法を学びたい方は、関心リストに登録してほしい。十分な関心が集まれば、コースを作る予定だ。

• 先行関心リスト - AIでセキュリティ脆弱性を見つける