セキュリティ専業ではない自分が WordPress Core で 1 回の Security Release に 3件クレジットされるまで
はじめに
この記事は、こんな方に向けて書いています。
- 脆弱性報告をしてみたい方
- リサーチャーとして活動してみたい方
- バグバウンティで報酬や実績を得たいと考えている方
- 「AI時代になって、もうバグハンターは厳しいのでは？」と思っている方
今回の記事は、技術解説メインではなく、自分自身の忘備録も兼ねた振り返りです。
なお、Xでも情報発信しているので、興味があればそちらも見てもらえると嬉しいです。
kaminuma
私はセキュリティ専業の人間ではなく、普段はフルスタック寄りの開発をしています。
そんな自分が、WordPress Core の脆弱性報告で、1回の Security Release の中で 3件クレジットされるという経験をしました。
WordPress Core のような大規模で長年レビューされているプロジェクトに対して、1回の Security Release で複数件クレジットされるのは、自分にとってかなり大きな成果でした。
各脆弱性の PoC や技術的な詳細については、また別で落ち着いて書きたいと思っています。
そのため今回は、
- どういう方向性で脆弱性の学習をしてきたのか
- どうやってバグハンターとして活動するようになったのか
- AIをどう実践の中に組み込んでいるのか
- セキュリティ専業ではない立場から、どうやって成果に繋げてきたのか
といった、学習の方向性・実践の積み上げ・AIとの付き合い方を中心に書いていきます。
公開できる範囲での活動内容
まず前提として、公開できる範囲での活動内容を簡単に書いておきます。
- WordPress Core の 1回の security release で 3件クレジット
- 未公開のCVE採番済み案件を複数保有
- 主な調査領域は、Web脆弱性（認可不備 / XSS / パストラバーサル / 任意ファイル書き込み / RCE / DoS）に加え、暗号実装やプロトコル周辺の問題調査
- HackerOne / OSS / responsible disclosure を継続中
- ここ3か月で、脆弱性レポートを約30本以上作成
- 現時点でH1の N/A 判定は 0件
たまたま今回、前面に出た結果が WordPress Core だっただけで、そこに至るまでにはかなり多くの試行錯誤がありました。
この記事では、そのあたりの話をしたいと思っています。
AI時代に、バグハンターは本当に終わったのか
ここ数年で、AIのコード読解力や要約力、仮説出しの性能はかなり上がったと思います。
その流れの中で、「AIでもう脆弱性も見つかるし、人間のバグハンターは厳しいのでは？」という話もよく見かけるようになりました。
自分はこの問いに対して、終わったというより、新しいフェーズに入ったと感じています。
実際に、コード読解や差分把握、仮説出し、レポート整理のような部分で、AIがかなり強い補助になっているのは事実です。
少なくとも初速や網羅性の面では、人間より強いと感じる場面もかなりあります。自分自身も、そうした使い方をかなりしています。
一方で、実際にレポートを出すところまで持っていくと、まだ人間側に大きく残っている部分もあります。
たとえば、
- 的外れな報告になっていないか
- それは仕様なのか、脆弱性なのか
- 攻撃成立条件は現実的か
- ローカルで再現可能か
- レポートとして相手に伝わる形になっているか
- 影響度をどう整理すべきか
といった部分です。
このあたりを蔑ろにしてレポートを出してしまうと、メンテナーやトリアージャーに余計な負担をかけることにもなります。
そのため、「AIが言っていたからレポートを出そう」は全くおすすめしません。最後は必ず自分自身が責任を持って提出する姿勢が大事だと思っています。
特に、暗号分野のように「理屈上は脆弱性だが、実際に攻撃可能といえるのか」が重要になる領域では、この見極めがかなり重くなります。
とはいえ、理論上の脆弱性でも informative 扱いで修正に繋がることはあるので、そこは「報奨金の有無」と「報告価値」を分けて考えるのが大事だとも思っています。
AIはかなり強くなっていて、脆弱性の仮説や下書きレベルであれば、相当高いところまで持っていけると思います。
ただ一方で、巨大プロダクトに対して、調査・再現・影響整理・相手とのやり取りまで含めた形で、きちんと通るCVE級レポートをそのまま量産してくれるかというと、そこはまだ別の難しさがあるとも感じています。
少なくとも自分は、WordPress Core のような大きな対象で結果が出たときほど、その最後の詰めや責任の部分はかなり人間依存だと感じました。
脆弱性診断やバグハンターは競技ではなく、その先には企業やOSSが抱えるリスクをいち早く発見し、責任ある開示を行うという役割があります。
攻撃者側もAIを使う時代だからこそ、守る側もAIを使いながら、より正確で修正しやすいレポートを早く出すことが求められていくはずです。
だから自分の中では、AIによってバグハンターが終わったというより、
AIと一緒にどう戦うかが問われる時代になった
という感覚のほうが近いです。
自分は現在セキュリティ専業ではないということ
自分は現在、脆弱性診断やペンテストを専門に業務をしていません。
仕事終わりの時間をリサーチャーとして活動するという形で実績を積んでいます。
普段のベースは、フルスタック寄りの開発です。
- フロントエンド
- バックエンド
- API設計
- DB設計
- 運用やインフラ寄りのこと
- 個人開発
- 自社アプリやWebサービスの実装
こういった文脈がメインの業務になります。
だからこそ、最初は「セキュリティの専門家ではない自分にどこまでできるのか」と思うこともありました。
理論面や体系的な知識で不足を感じる場面もありました。
ただ、その一方で、開発をやってきたことがそのまま活きる場面もかなりありました。
たとえば、
- 開発者がどこで実装を省略しがちか
- どこで信頼しすぎるか
- UIでは制御しているのにサーバー側で抜けるのはどこか
- 正常系は安全そうでも、例外系で壊れやすいのはどこか
- 修正のつもりが別ルートを残してしまいそうな箇所はどこか
こういう観点は、開発経験があるとかなり見えやすくなります。
なので、この記事でまず伝えたいのは、
セキュリティ専業じゃないと無理というわけではない
ということです。
むしろ、普段からコードを書いている人、設計や運用に触っている人ほど、入りやすい入口はあると思っています。
特にレビューで実装を細かくみることができる能力は脆弱性報告にとって強い武器になると思っています。
結果の裏には、かなり地味な積み上げがある
今回、表に出た結果としては、WordPress Core の 1回の Security Release で 3件クレジットという形になりました。
でも自分の感覚として重いのは、その結果そのものより、そこに至るまでの無数の試行錯誤のほうです。
実際には、提出したレポートの中には informative や duplicate になったものもありますし、自分でも見えていたものの、先行報告があり他の報告者のクレジットになったものもかなりの数あります。
つまり、実際にはかなり地道な積み上げの上に、たまたま前面に出たのが今回の WordPress Core の結果だった、という感覚に近いです。
脆弱性報告は、毎回ホームランになるような世界ではありません。
むしろ、バントで塁に出られたらかなり良い方、くらいの感覚です。三振して N/A にならないだけでも前進、くらいかもしれません。
ちなみに N/A は、ざっくり言うと「これは脆弱性としては扱わない」という判定です。
報告者側からするとかなりつらい判定ですが、逆に言えば、的外れな報告を避ける意識はとても大事だと思っています。
学習で効いたのは、「壊れ方を実装で理解すること」
いま振り返ると、自分にとって大きかったのは、派手な攻撃手法を追いかけることよりも、脆弱性が実装ベースでどう壊れるのかを理解することでした。
単語だけ知っていても、実戦ではあまり効きません。
たとえば XSS なら、
- どこで入力が入るのか
- どこでエスケープされるべきなのか
- HTML文脈なのか属性文脈なのか
- フレームワークの安全機構がどこまで効いているのか
- どこが例外ルートなのか
まで見ていかないと、実際の問題としては掴みにくいです。
認可不備なら、
- UIだけで制御していないか
- サーバー側で enforce されているか
- 追加時だけ厳しいが削除時は緩くないか
- 分岐によって片方だけ権限チェックが抜けていないか
を見る必要があります。
パストラバーサルや任意ファイル書き込みなら、
- パスの正規化前後で何が起きるのか
- バリデーションと実際の sink が離れていないか
- あるディレクトリに閉じている前提が本当に守られているか
- それがどうRCEに繋がるのか
というところまで見ていく必要があります。
だからこそ、自分は「まずAIを使ってでもやってみる」ことが重要だと思っています。
やっていく中で、自分が知っている単語もあれば、知らない脆弱性クラスや実装パターンの話が出てくることもあります。
でも、その場で調べて、試して、再現してみることで、試験用の知識ではなく、実際に使える知識として残りやすくなるはずです。
CTFは有益。でも「解けた」で終わると少しもったいない
CTFについては、かなり意味があると思っています。
ただ、自分の感覚では、単に「その問題を解けたかどうか」だけで終わると、実務的な伸びには繋がりにくいこともあります。
むしろ大事なのは、
- どういう観点でその問題を崩したのか
- どこに仮定があったのか
- 何を手がかりに突破口を見つけたのか
- AIを使うなら、どういう壁打ちで攻略に辿り着いたのか
- その過程を現実のプロダクト調査にどう応用できるのか
といった、過程のほうだと思っています。
特に大きいのは、
- どこが入力点かを探す癖
- どこに仮定が埋まっているかを見る癖
- 失敗しても手を変えて掘る癖
- 小さい観測結果から仮説を立てる癖
- 「通ると思っていた前提」を疑う癖
このあたりです。
脆弱性調査では、単に怪しい箇所を見つけるだけで終わることは少なくて、むしろその怪しさをどう脆弱性として成立させるか、どこまで詰められるか、という時間のほうが長いと感じています。
そういった意味でも、CTFを観点の訓練として使えるかどうかはかなり大きいと思います。
OSSは「対象」であると同時に、かなり強い教材でもある
個人的には、OSS を見ることがかなり勉強になりました。
OSS は、いまの時代だとAIも使いながら、過去の issue、advisory、修正差分、関連コミットをかなり素早くたどれます。
そうやって「いつ、どういう問題があり、どう修正されたのか」を追っていくと、逆に
- この修正が入ったということは、近い構造の別ルートはどうなのか
- この実装が後から入っているなら、見落としが残っていないか
- この修正は根本解決なのか、それとも一部だけ塞いでいるのか
といったヒントにもなります。
この意味で、OSS は単なる調査対象というより、かなり強い教材でもあります。
私の場合は CMS 関係のOSSを横断して調査し、構造から見ていく箇所や調査観点を Markdown で内部資料として溜めておき、横展開するような手法も使っていました。
ゼロから完全に思いつくというより、
既存の問題や修正の文脈を理解して、近い構造を追っていく
ほうが、実際にはかなり現実的だと思っています。
AIは「全部やってくれる存在」ではなく、かなり強い調査補助
自分はAIをかなり使っていますが、感覚としては「AIに全部やらせる」というより、かなり強い調査補助・整理役・壁打ち相手として使っています。
具体的には、こんな場面でかなり役に立っています。
1. 巨大コードベースの初期把握
巨大なプロダクトでは、最初にどこを見ればいいのか分かりにくいことが多いです。
そういうときに、
- この機能の中心クラスはどこか
- 権限チェックはどこにありそうか
- ファイル操作の sink はどこか
- 似た実装が他にないか
といった地図を描くのにかなり役立ちます。
2. 差分の意味を言語化する
セキュリティ修正の差分を見たときに、
- 何を防ごうとしているのか
- 追加された条件はどんな前提を意味するのか
- 別ルートにまだ似た問題が残っていないか
を整理するのにも使えます。
3. 仮説の壁打ち
たとえば、
- 追加だけ見て削除時は抜けていないか
- sanitize の順序が後段で崩れないか
- フォールバック経路だけ検証が薄くないか
- 安全な抽象化が別モードでは無効化されていないか
といった仮説を広げるのにかなり強いです。
4. 調査ログの整理
自分の場合、AIとのやり取りだけに依存するとコンテキストが残りにくいので、定期的に調査した内容を Markdown で保存しています。
仮説、観測結果、怪しかった箇所、通らなかった案、関連コミット、次に見るべき論点などを蓄積していく形です。
特に WordPress のような巨大プロジェクトでは、この蓄積がかなり効いてきます。
一度で仕留めるというより、過去の調査ログが次の攻略の起点になる感覚です。
それでも最後は、自分で判断して、自分で責任を持つ
AIを有効に使うナレッジを蓄積していくこと自体が、今後は差別化にもなっていくと思っています。
ただし、最後に提出するそのレポートに責任を持つのは自分です。
「このレポートはAIが出したので詳しくは答えられません」は通用しません。
more info で質問が来たとき、PRレビューを依頼されたとき、修正が本当に問題を潰せているか確認するとき、追加で問題があるか判断するとき、そこに立つのは自分自身です。
AIでざっと怪しい箇所を出すことはできても、そこからどこを深掘るか、どう攻めるか、何を突破口にするか、といった嗅覚はまだかなり人間依存だと思っています。
自分はそこが、この分野のいちばん面白いところでもあると感じています。
結果よりも、そこに至るまでの試行錯誤のほうが重い
今回、WordPress Core で 1回の Security Release に 3件クレジットされたことは、もちろん自分にとって大きな節目でした。
ただ、自分の感覚としては、そこに至るまでの無数の試行錯誤のほうがずっと重いです。
- どう見ても怪しいのに脆弱性としては弱かったもの
- かなり良いと思ったのに duplicate だったもの
- 再現はできたものの、ローカル条件や前提が強く、実戦的な報告としては弱かったもの
- 実装上は危なそうでも、仕様との線引きで脆弱性として押し切れなかったもの
そういうものが山ほどあります。
だから今回の結果も、「いきなり当たった」というより、たくさんの観察、提出、失敗、修正、再考の積み上げのうえで、たまたま前面に出たのがこの結果だった、という感覚です。
これから始める人に伝えたいこと
ここまで読んでくださった方の中には、「自分もやってみたい」と思っている方もいるかもしれません。
自分もホワイトハッカーに憧れてエンジニアに転職し、ようやく今ここに来てリサーチャー的な活動ができるようになってきました。
本職はフルスタックエンジニアなので、まだ本業そのものがセキュリティ専業というわけではありませんが、それでもここまで来ることはできました。
そんな方に向けて、今の時点で自分が思うことをまとめると、こんな感じです。
1. まずはAIも使いながら、実装ベースで触ってみる
脆弱性クラスを単語として知るだけでは、実戦ではなかなか使いにくいです。
AIも使いながら、実際にどう壊れるのか、どんなコードで起きるのか、どこで防ぐべきかを見てみることが重要だと思っています。
2. 開発経験は十分に武器になる
普段コードを書いていること、設計や運用に触っていることは、そのまま武器になります。
特に、権限境界やデータ境界の実務的な見え方は、開発者視点がかなり強いと思っています。
3. AIは強い。でも最後に責任を持つのは自分
AIは便利ですし、有効に使うナレッジを蓄積していくこと自体が差別化にもなると思います。
ただし、最後に「これは本当に脆弱性として成立する」と言う責任は自分にあります。
4. 毎回ホームランにはならない
脆弱性報告は、毎回大当たりになるわけではありません。
むしろ、地道に積み上げていく中で少しずつ前に進む感覚のほうが近いと思っています。
5. 最初から大きな対象を狙いすぎなくていい
自分は今回、結果として WordPress Core で表に出ましたが、最初からそういう大きな対象ばかりを狙う必要はないと思っています。
実際には他のOSSも大量に見ていますし、掘り尽くされていない対象や、自分で作ったアプリを見直すことにも十分意味があります。
これからやっていきたいこと
今回の結果で一区切りというより、むしろここからが本番だと思っています。
今後は、
- 今回の各脆弱性の技術詳細を整理する
- 公開可能な範囲で PoC や再現手順を書く
- より深い設計レベルの問題も追う
- AIの使い方も、再現性ある形で整理していく
- 難易度の高い暗号分野の実装不備やプロトコル起因の問題についても、引き続き専門性を上げていく
といったことを続けていきたいと思っています。
AIとともに調査し、AIとともに修正後の世界線まで見にいく。
そして、その修正が入ったあとでも見つかる問題を追っていく。
これからは、そういう能力がより求められていくのではないかとも感じています。
だからこそ、AI時代はつまらなくなるのではなく、むしろもっと面白くなるのかもしれません。
おわりに
もし今、
- 脆弱性報告に興味はあるけれど踏み出せていない
- 自分はセキュリティ専業ではないから厳しいかもしれない
- AI時代に今さら始めても遅いのではないか
と思っている方がいたら、自分はこう思います。
AIの時代だからこそ、この分野はむしろ面白くなるのではないかと思っています。
AIと一緒に調査し、AIと一緒に実装を読み、修正が入った後の世界線でも問題を見つける。
そういう戦い方が、これからもっと重要になっていくはずです。
（もしくは今と違ったサイバーセキュリティの世界に入っていくのではないでしょうか？）
そこにも結局新しい形のホワイトハッカーは存在するはずです。
自分自身、セキュリティ専業というわけではありません。
それでも、学習を続け、実践し、AIもうまく使いながら、WordPress Core で 1回の Security Release に 3件クレジットされるところまでは来ることができました。
この記事は技術詳細ではありませんが、
「こういう積み上げ方でも届くんだ」
という一つの例として、これから始める誰かの参考になれば嬉しいです。
技術的な詳細や PoC、実際にどんな観点で見つけたのかについては、また別の記事で整理していきたいと思っています。