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

 (words.filippo.io)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • オープンソース保守では、通常のイシューやPRは選択的に扱えるが、これまでの脆弱性レポートはユーザー保護のため別対応が必要な例外だった
  • その例外性は、研究者が攻撃者より先に修正の機会を与える希少な洞察と秘密保持を提供することで成り立っており、プロジェクトは迅速な応答・調査・進捗共有・クレジットでそれに報いる構造だった
  • 2026年には、LLMを保守者も攻撃者も実行できるため、ボトルネックは潜在的な問題の発見から実際の脆弱性の選別へ移る
  • 信頼関係のない外部研究者は選別に大きく貢献しにくく、LLM出力のレビューとsecurity@受信トレイの確認のシグナル対ノイズ比は似たものになる
  • 保守者の時間は、報告対応そのものよりも分類、迅速な修正、予防により多く使われるべきであり、LLM分析をCIで実行する方法も必要になる

脆弱性報告が例外だった理由

  • 公開の場で働くオープンソース保守者は、イシュー、PR、フィードバックを贈り物のように受け取り、必要に応じて受け入れたり、無視したり、一部だけ使ったりできる
  • 過去の脆弱性レポートはこの原則から外れる特別なケースだった
    • セキュリティ研究者は即時公開の代わりに非公開報告を選び、プロジェクトが先に修正する時間を与えていた
    • プロジェクトは報告を迅速に確認して調査し、報告者に進捗を共有し、最終的に発見へのクレジットを与えることが一般的な期待だった
  • こうした期待は、報告者がバグ修正や機能実装を要求する人ではなく、プロジェクトにサービスを提供する人だという前提から生まれていた
    • 中核的な価値は、攻撃者がエクスプロイトを出す前に修正版を配布できるようにする洞察と機密性にあった
    • 脆弱性報告を無視すると、ユーザーのセキュリティを気にしていないというシグナルと受け取られていた

2026年に崩れた前提

  • 2026年には、脆弱性報告を特別なものにしていた前提を維持することが難しくなる
    • LLMはほぼすべてのセキュリティ研究者と同等に優秀で、誰でも実行できる
    • 同じツールを保守者も実行でき、攻撃者も実行できる
  • 不足しているのは潜在的な問題を見つける能力ではなく、その中のどれが本当の脆弱性なのかを見極める分類作業である
  • 既存の信頼関係がない外部研究者は、この分類プロセスに有意義に貢献しにくい
    • LLMの出力をレビューする作業と、security@受信トレイをざっと見る作業のシグナル対ノイズ比はほぼ同じである
  • 秘密保持、エンバーゴ、調整の重要性も以前より低下する
    • 攻撃者は全面公開の投稿を待たずに、自分のLLMに脆弱性を尋ねられる
    • ただし攻撃者も防御側と同じ分類ボトルネックに直面する可能性が高い

保守者の優先順位の変化

  • 脆弱性レポートが特別だった時代は終わったのかもしれない
  • 今より重要なのは分類、迅速な修正、予防である
  • LLM分析をCIで実行する方法を見つけるべきである
  • この立場はGo Securityチームの公式見解ではなく、元Go Securityチームリードだった個人の見解である
  • 脆弱性報告の処理とCode of Conductの執行が衝突する場合、正解はない
    • 行為の深刻さ、私的な問題なのかコミュニティに影響するのか、security@を処理するチームのリソースに応じて判断すべきである
  • 公開慣行には複雑な歴史がある
    • 過去には、善意の研究者が法的脅迫や訴追を受けることがあった
    • 2026年のオープンソースの現実では、脆弱性報告のために訴追を恐れる研究者はおらず、プロジェクトも文書化された報告ポリシーの代替として訴追を示唆してはならない
  • curlの1か月間の脆弱性報告チャネル停止は、当初はやりすぎに感じられたが、ユーザー保護のために脆弱性報告対応が最善の時間の使い方なのかは、もはや明らかではない

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見

  • 性急な脆弱性公開は、依然として防御側より攻撃側にはるかに有利だと思う。自分で経験して見てきた限りでは、最先端モデルを使っても誤検知率が90%近いことがある
    付け加えると、「オープンソースの暗号プロトコルの持続可能な保守と開発が、ブロックチェーン技術の幅広い採用に重要である」という文言が見えるが、いまだにブロックチェーン技術を信じている人がいることに驚く

    • その文言がなぜ入っているのか混乱したが、調べてみると Filippo のスポンサーの1社が送ったメッセージだった
      現時点でブロックチェーン技術が世界にもたらした最も価値あるものは、本当に安全な暗号プロトコル実装を作るための強い金銭的インセンティブを提供したことかもしれない。その一部は他のすべての人にとっても有用になる可能性がある
    • ここでいう誤検知とは何を意味するのか気になる。モデルが脆弱性を見つけたと主張したが、確認すると問題ではなかったという意味か？
      この時点では、脆弱性発見やコード理解全般は LLM が得意なこととしてかなり確立されていると思っていたが、実際どうなのか気になる。実体験をもう少し説明してくれるか、参考になる資料を教えてもらえるとありがたい。LLM を使っていないので、最近どの程度なのか感覚がつかみにくく、前提を変えるべきか本気で知りたい

  • 特別な脆弱性報告は特別扱いすべきであり、防御側でよりよい検証方法と公開された脅威モデルを整備すべきだ。そうすれば、優れた報告として認められるためのより高い基準を人々が満たし、検証できるようになる

    • 結局はそう整理されるかもしれない。脆弱性報告は一般には特別なものではないが、深刻度が高い、または信頼性が高い一部の報告は特別な脆弱性報告と見なすべきだ

  • セキュリティ問題を見つけるのが簡単になり参入障壁も下がったことで、セキュリティメーリングリストに以前よりノイズが増えたはずだという点には同意する。それでも、Trail of Bits や Zellic のような評判の高いセキュリティコンサルティング会社からのバグ報告は、今でも間違いなく優先するだろう
    彼らが雑な報告を出さないと信じているからだけではなく、CI で LLM をただ回すよりも、トップクラスのセキュリティ研究者と LLM の組み合わせのほうが優れていると考えるからだ

    • 最近そうしたベンダーと仕事をしたが、雑な報告は依然として入ってくる。ただし報告書の品質はより高い
      LLM は誰が使っても脅威モデルを誤解することがあり、「エクスプロイト」を立証するやり方でも手を抜くことがある。セキュリティ研究者がこうしたミスを見落とすと、結局は保守担当者である私たちに渡ってくる。containerd はこうしたベンダー、LLM 研究会社、既知の基盤モデル企業、そしてインターネット上の J Random User からも雑な報告を受け取ってきた
      Filippo がここで十分に語っていないもう一つの難しさは、重複報告だ。containerd の最近の advisories を見ると、トリアージと注意配分におけるもう一つの大きな問題が重複であることが分かる。たとえば 9 separate researchers/groups にクレジットを与えており、その中には先ほど触れたような評判の高いグループも含まれている。これは (a) LLM は誰が使っても同じ問題を多数見つけ出すこと、(b) 既知の報告者からの報告だからといって必ずしも特別ではないこと、を示している。逆に this one は実際には重複報告がなく、1人にしかクレジットを与えておらず、その報告者は私たちが事前に知っていた人でも関係のあった人でもなかった