GitHub バグバウンティプログラムの質向上と責任共有、そして未来

セキュリティ研究コミュニティは、GitHub の最大の資産の一つです。世界中の研究者が毎年、脆弱性の発見と修正を支援し、1 億 8000 万人以上の開発者にとってプラットフォームをより安全なものにしています。バグバウンティプログラムが存在する理由は、外部の研究者との協力がセキュリティを向上させる最も効果的な方法の一つであると信じているからです。私たちはこの取り組みに対して深くコミットし続けています。 しかし、すべてのバグバウンティプログラムと同様に、変化する環境に適応する必要があります。私たちが観察していること、それに対する対応、そして GitHub のようなプラットフォームのセキュリティ境界についてどのように考えているかをお伝えします。 ボリュームの問題 過去 1 年間、業界全体の提出件数は大幅に増加しました。AI を含む新しいツールがセキュリティ研究への参入障壁を下げたことは、多くの点で肯定的な発展です。攻撃対象領域を探求する人が増えることは、実際の課題を見つける機会が増えることを意味します。 しかし、正当な報告の増加に伴い、実際のセキュリティ影響を示さない提出件数が急増していることも確認しています。これには、概念実証（Proof of Concept）を伴わない報告や、精査に耐えられない理論的な攻撃シナリオ、すでに公開した不適切リストに含まれる発見などが含まれます。これは GitHub 固有の問題ではありません。業界全体のプログラムが同じ課題に直面しており、一部では完全に終了したケースもあります。 私たちはそのような方向には進みたくありません。むしろ、プログラムをより良くするために投資したいと考えています。 What makes a strong submission 質の高い提出物とは何か 私たちは、完全な提出物とみなす基準をより厳しくしています。今後は、以下の基準に照らして報告書をより厳格に評価します: 動作する概念実証（PoC）と明確なセキュリティ影響の提示。影響を記述するだけでなく、実際に示してください。攻撃者が実際に何を実現できるのか？実際の悪用と具体的なセキュリティ影響を実証する動作する PoC が必要です。理論的に存在するだけでなく、越えられる境界線を示してください。「これが～につながる可能性がある」という報告で、それが実際に起こることを示さない場合、それは不完全です。 スコープと対象外発見事項の理解。提出前に、当社のスコープおよび対象外発見事項リストを確認してください。既知の対象外カテゴリ（DMARC/SPF/DKIM 設定、ユーザー列挙、攻撃経路が実証されていないセキュリティヘッダーの欠如など）を扱う報告書は「適用なし」として処理され、HackerOne Signal や評判に影響を与える可能性があります。 提出前の検証。スキャナ、静的解析ツール、AI アシスタントなどどのようなツールを使用する場合でも、提出前に出力を検証する必要があります。手動レビューを経た偽陽性は、誰かの時間を無駄にする前に検出されます。そうでないものは単なるノイズに過ぎません。 セキュリティ研究における AI の活用を歓迎します これを明確にしておきます：AI ツールを利用する研究者に対して問題はありません。AI は力率を高める要因であり、セキュリティ研究においてその役割がますます重要になると期待しています。私たちも内部のセキュリティプログラムで AI を活用しており、外部の優秀な研究者たちも同様に利用している様子を確認しています。歓迎します。 私たちが求めているのは、これまで一貫して期待してきた基準と同じものです：検証です。AI の支援を受けた発見であっても、検証され、再現され、動作する概念実証（PoC）を伴って提出されたものであれば素晴らしい報告となります。一方、検証も再現も影響の実証もないまま出力されたものは該当しません。これは新しい基準ではなく、スキャナ出力や静的解析、あるいはその他のツールに対して適用しているのと同じ基準です。提出物の正確性に対する責任は、人間である研究者にあります。 また、研究者の皆様には、報告書を簡潔かつ構造化して作成いただくようお願いいたします。優れた報告書には次の 3 つの要素が必要です：問題の短い要約、サポート証拠（スクリーンショット、HTTP リクエスト、ターミナル出力）を伴う明確な再現手順、そして攻撃者が実際に達成できることを説明する影響記述です。それだけです。多頁にわたる理論的な物語や、背景情報の繰り返し、AI 生成による埋め草のような冗長な報告書は、実際の発見が埋もれてしまうため、トリアージ（選別）を遅らせてしまいます。報告書が明確で直接的であればあるほど、私たちは迅速に対応できます。 ツールは何でも構いません。重要なのは作業の質です。 GitHub のセキュリティモデルを理解する：共有責任 私たちが頻繁に目にするあるパターンには、独自の議論の余地があります。多くの報告書では、ユーザーが悪意のあるリポジトリや作成された課題、信頼できないコードなど攻撃者が制御するコンテンツと相互作用し、望ましくない結果を経験するシナリオが記述されています。これらの報告は概して文章が良く、観察点も技術的に正確ですが、セキュリティの境界線がどこにあるのかを誤解しています。 私たちは、プラットフォーム全体にわたる悪意のあるコンテンツの検出と処理のために、自動化されたスキャンから手動レビューに至るまで、システムとチームに多大な投資を行っています。ただし、GitHub は共有責任モデルに基づいて運営されています。ユーザーには以下の責任があります: 信頼するリポジトリ、課題、コードを選択すること。GitHub には 6 億以上のリポジトリがホストされています。それらすべてが悪意のないものではありません。ユーザーは、自分が相互作用するものについて判断を下すことが期待されます。 実行または相互作用を行う前にコンテンツを確認すること。これはコード、スクリプト、ワークフロー、およびその他の実行可能コンテンツに適用されます。 リポジトリをクローンすることは、そのコードを信頼することを選択することを理解すること。Git フック、ビルドスクリプト、および他のリポジトリレベルの自動化は、ユーザーがそのリポジトリをチェックアウトすることを選んだために実行されます。 自身の環境を安全に構成すること。トークン管理、認証情報の保存、ローカルセキュリティ設定はユーザーの責任です。 「攻撃」には、被害者が攻撃者によって制御されたコンテンツを積極的に探し出し、それと関与することが必要となるケースがあります（悪意のあるリポジトリのクローン作成、信頼できないコードの分析を AI ツールに依頼する、改ざんされたファイルを開くなど）。このような場合、セキュリティ境界は、そのコンテンツを信頼するというユーザーの判断によって定義されます。これらのシナリオは通常、GitHub のセキュリティ制御を迂回するものとはみなされません。 一般的な例 研究者が責任範囲を適切に把握できるよう、共有責任に該当するパターンをいくつか以下に示します。 シナリオ｜なぜそれが共有責任なのか ユーザーが AI ツールに入力したコンテンツを通じたプロンプトインジェクション｜ユーザーがそのコンテンツを信頼すると決定した ユーザーがチェックアウトしたリポジトリ内で実行される Gitフックまたはフィルタによるコードの実行｜これは設計上、Git の動作原理そのものです ユーザーがクローンしたリポジトリ内の悪意のあるコンテンツ｜クローンは信頼の行為です 信頼できない入力を処理する際に LLM が予期せぬ出力を生成する｜ユーザーがその入力を提供すると決定しました これらの分野における研究は依然として極めて価値があります。もし、私たちの防御に盲点がある（ユーザーが悪意のあるコンテンツを積極的に信頼することを必要とせず、実際のセキュリティ制御を迂回する方法）と考えられる場合は、ぜひお知らせください。それが私たちが最も聞きたい内容です。そのような発見は、私たちが受け取る中で最も影響力のある提出物の一部となります。また、利用規約に違反するコンテンツを見つけた場合は、必ず報告してください。 研究者にとっての意味 すでに質の高い研究を提出されている方々へ、ありがとうございます。あなた方にとって変わることはありませんが、キューのノイズを削減することで、対応時間がより迅速になります。 バグバウンティに新しく参加される方、ようこそ！数分時間を割いてスコープをお読みいただき、対象外リストを確認した上で、提出前に動作する概念実証（PoC）の構築にお投資ください。新規研究者からの質の高い報告は常に高く評価され、感謝されています。 もしこれまで数量を優先されてきたのであれば、深さへとシフトすることをお勧めします。1 つのよく調査され検証された発見は、10 の推測に基づく発見よりも、バウンティ報酬と評判の両面で価値があります。当プログラムから最も多くの報酬を得ている研究者こそが、深く掘り下げる人々です。 低リスクな発見に対する報酬方法の変更 すべての有効な報告が意味のあるセキュリティリスクを意味するわけではありません。一部の報告は、攻撃に悪用されるものではありませんが、強化の機会やドキュメント上のギャップを特定しており、それでも私たちが改善を行うべき点を示しています。そのような作業にも感謝しています。 今後はこれらのケースに対する扱いを更新します。著しいセキュリティへの影響を示さないものの、コードまたはドキュメントの修正につながる報告については、バウンティ報酬ではなく GitHub のグッズ（スワッグ）として表彰いたします。これにより貢献を認めつつ、プラットフォームセキュリティに最も大きな影響を与える発見に対してバウンティリソースを集中させることができます。 低リスクな発見における数量最適化よりも、研究者がより深く高インパクトのある研究に時間を投資し、それに相応しい報酬を得ることを望んでいます。 今後の展望 私たちは、GitHub のバグバウンティプログラムを、研究者およびプラットフォームのセキュリティのために業界最高水準の一つにするために尽力しています。つまり、より迅速なトリアージ（選別）、明確なコミュニケーション、そして有効な発見が適切な注目と報酬を得られるようにすることです。品質基準を引き上げることは、その投資の一部です。 セキュリティ研究者は、それを利用するすべての開発者にとって GitHub をより安全なものにしています。この取り組みは重要であり、私たちはそれを当然のこととして扱いません。 ハッキングを楽しんでください！

GitHub バグバウンティプログラムの質向上と責任共有、そして未来

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト