世界を動かす技術を、日本語で。

脆弱性レポートはもはや特別ではない

2026年6月24日原文(words.filippo.io)

概要

  • 2026年 にはオープンソースの脆弱性報告の扱いが大きく変化
  • LLMの登場 により、脆弱性の発見は特別ではなくなった現状
  • 課題は発見よりもトリアージと対応 にシフト
  • 機密性や調整の重要性も低下
  • 今後はLLMを活用した自動分析と迅速な対応 が求められる

オープンソースメンテナンスと脆弱性報告の変化

  • 従来、 オープンソースメンテナ は「IssueやPRは贈り物」と捉え、 受け入れ・無視・部分利用の自由 があった
  • しかし、 脆弱性報告だけは特別扱い され、迅速な対応と発見者への謝辞が求められていた
  • セキュリティ研究者 は、攻撃者へ公開せずに報告することで、 守り手へのサービス を提供していた
  • この対応は、 ユーザー保護の責任感 から来ていた

2026年の現実:LLMによる脆弱性発見の一般化

  • LLM(大規模言語モデル) がほぼ全てのセキュリティ研究者と同等の能力を持つ時代へ
  • 誰でもLLMを使って脆弱性を発見可能、守り手も攻撃者も同じツールを利用
  • 貴重だった「洞察」や「機密性」 の価値が大幅に低下
  • 現在のボトルネックは、 発見ではなく「どれが本物か」のトリアージ
  • 外部研究者の貢献も限定的 で、LLMの出力やsecurity@の受信箱のノイズ率は同等
  • 機密保持や調整の意味合いも薄れ、攻撃者も同じ情報やツールを持つ状況

今後のメンテナンスの焦点

  • 脆弱性報告の特別扱いは終焉、違和感を覚えるが現実として受け入れる必要
  • 課題はトリアージ・迅速な修正・予防策の強化 へ移行
  • CIパイプラインでのLLM分析の導入 が今後の標準に

Geomysとスポンサーシップ

  • Geomys :プロのGoメンテナによる組織、 Ava Labs、Teleport、Datadog、Tailscale、Sentry が資金提供
  • スポンサー契約 により、オープンソース保守の持続性と信頼性を確保
  • 直接的な専門知識提供 とプロジェクト支援

Teleportのコメント

  • 攻撃の主流 は従来型マルウェアから アカウントや認証情報の乗っ取り
  • Teleport Identity :アクセス監視、アクセスリクエストによる表面縮小、未使用権限の削除でリスク低減

Ava Labsのコメント

  • AvalancheGo の保守・開発を通じ、 ブロックチェーン技術の普及 を支援
  • オープンソース暗号プロトコルの持続的な保守 の重要性を強調

脆弱性報告とCoC(行動規範)の交差

  • 脆弱性報告者がCoC違反の場合の扱い は難題
  • ケースバイケースの判断 が必要で、報告の無視やサイレント修正など対応は状況次第

脆弱性報告文化の歴史的背景

  • かつては報告者が法的脅威に晒されることも あり、 フルディスクロージャ運動 が状況を改善
  • 2026年現在、オープンソースでは法的リスクはほぼ無関係

今後への提言

  • ユーザー保護のために、時代に合わせた対応の変革が必要
  • LLM分析や自動化されたトリアージ体制の構築 が今後の必須スキル

Hackerたちの意見

スパムがめっちゃ増えてる気がする。会社を運営してるけど、毎週2~5件の「脆弱性レポート」が届くんだ。半分は、LLMがうちのフレーマースプラッシュページの悪いCSSを見つけたやつ。残りの半分は恐らく恐喝の試みだから、スパムとしてマークしてる。たまにHNで本物のセキュリティ研究者が、誰も開示を真剣に受け止めてくれないとか、すぐに差し止め命令が来るって文句言ってるのを見るけど、受け取る側からすると、スパムが管理できないからなんだよね。

同じ経験だわ。10年以上、成功した脆弱性開示プログラムを運営してきて、scanii.com(マルウェア識別APIサービス)には何千ドルも報酬を支払ってきたけど、最近(年始から)、月に5件だったのが、今は1日5件になっちゃった。これらは明らかにAI生成で、質がめっちゃ低い(でも、文章はうまい)。プログラムのルールも読まれてないし、明らかに「ウェブサイトにポイント&クリックして報告する」だけ。OPが指摘したように、AIツールを使ってこの脆弱性を見つけたなら、そもそも公開されてるものだから、プログラムを閉じることも考えてる。まだそこまでは行ってないけど、ほとんどのレポートをフィルタリングするための新しいルールを設けたよ:1- AI生成のレポートはダメ、2- レポートにはエクスプロイトの動画を含めること。プログラムのルールはここで見られるよ:https://docs.scanii.com/article/131-does-scanii-have-a-secur...

もうCVE疲れだよ。超クリティカルな10/10の脆弱性が、フロントエンドをコンパイルするノードパッケージに悪意のある正規表現を与えるとハングするなんて、見つけるのが難しいものが本当に大事なことなのか分からなくなってきた。

確か「Beg Bounties」っていう名前だったかな。常にあって、うざいよね。

エージェントを使ったり、モデルに分類・トリアージしてもらうことを考えたことある?現代の問題には現代の解決策が必要だよ。

こういう低労力な報告が嫌だったから、セキュリティの受信箱をチェックして、正当なものをSlackの#securityで私にメンションしてくれる簡単な自動化ツールを作ったんだ。そうすればすぐに目に入るし、完全に自動生成されたものはスパムとしてマークする。正当なメールがスパムフォルダに入ってないかはチェックしてるけど、今のところ誤検知はないよ。

でも、なんで圧倒されてるのにC&Dで返すの?同じ人じゃない場合もあるよね?

ここ5年くらい、すべてのソフトウェアでそうなってる。人々はLinuxカーネルのバグを見つけるのが大事だって振る舞うけど、そのバグを悪用するためには、まず攻撃者があなたのコンピュータでコードを実行できる必要があるってことを完全に無視してる。今はリモートでそれをやるのはめちゃくちゃ難しいし。しかも、皮肉なことに、みんなそんなに気にしてない。最後の本当に悪い脆弱性はJavaのlog4shellだったけど、あれがどうやって導入されたか(つまり、Apacheの誰かが意図的にログステートメントがコードを実行できるようにしたのに、誰もそれを疑問に思わずにプロダクションにプッシュした)を考えると、みんながApacheのライブラリをサービスから完全に取り除くべきだっていう合図だったはずなのに、今でもそのソフトウェアは使われ続けてる。

そうだね、小さなFOSS団体でセキュリティレポートのレビューを手伝ってるんだけど、誰かが公開アクセス可能なSVNサーバーについて「クリティカル」な脆弱性を報告してきた。確かに、オープンソースソフトウェアをホスティングする目的だからね。でも、その報告は明らかに嘘だった。もっとひどいのは、最初は正当なように見えるやつで、AI生成の段落を何十も読まないと、隠れてる有効なものがないか確認しなきゃいけないやつ。

それに、私たちは年に一度のペンテスト契約を狙ってくる企業から、 unsolicitedな脆弱性レポートももらうんだ。倫理的にちょっとグレーだよね。

隠れたところでのセキュリティなんて、元々良い戦略じゃなかったし、今は全く戦略じゃないよね。今世紀の終わりには、たくさんのソフトウェアの実践が見直されて、問題のクラスを排除できるといいな。メモリ安全な言語の使用は素晴らしいスタートだけど、TOCTOU問題や不適切な認証・認可、その他多くの問題をチェックするイノベーションも見たいな。これはエンジニアリングの問題なんだ。単に「バカなことを1/10の頻度でやるモデル」じゃ解決しないし、作業の前後でさらにダブルチェックするモデルを追加しても解決しない。人間がレビューで見つけるのを期待してもダメだし、外側のループを追加しても解決には至らないかも。でも、近づくことはできるかもね。本当に解決するには、真剣なCS研究が必要だよ。

実装の正しさを検証するのはP NPで、真剣なCS研究じゃないよ。

Hacker Newsで議論の続きを見る