Microsoftは、同社のバグバウンティプログラム全体で、報告内容の完全性に関する新たな要件を導入しました。報奨金の支払額は、研究者が最初に提出する報告の質とより密接に結び付けられることになります。
Microsoft Security Response Center（MSRC）が2026年10月20日に発表したもので、これまで複数あった報告品質のレベルを、「Complete（完全）」と「Not Complete（不完全）」の2段階の評価に置き換えます。
新しい方式は、太平洋時間10月20日午前8時以降に提出された報告に適用されます。それ以前に提出された報告は、従来の要件が引き続き適用されます。
報奨金の対象となる「Complete」の報告は、対象となる「Not Complete」の報告より高い報奨金を受け取れる可能性があります。ただし、報告が完全であっても、深刻度やセキュリティへの影響、報奨金の対象になるかどうかが決まるわけではありません。
「Complete」の報告と認められるには、Microsoftのエンジニアが追加のやり取りをほとんど、あるいはまったく必要とせずに、脆弱性を独自に理解・再現・評価できるだけの正確な情報と裏付け資料が必要です。
中心となる要件は、明確な再現手順、信頼性が高く最小化された概念実証（PoC）、脆弱性の種類、そして詳細な技術分析です。
研究者は、影響を受ける環境、プラットフォーム、関連するバージョンのほか、該当する場合は影響を受けるコンポーネントも特定しなければなりません。
また、可能な限り根本原因を説明し、攻撃者に必要な前提条件、悪用可能となる条件、脆弱性を引き起こすために必要な状況も記載する必要があります。影響の説明では、攻撃者が何を達成できるのか、どのリソースやシステムが影響を受けるのかを明らかにしなければなりません。
Microsoftは、最初の提出時に含まれていた文書と証拠に基づいて、報告の完全性を評価します。必須の要素や成果物が欠けている場合は、「Not Complete」と評価されます。
MSRCが追加情報を求めることもありますが、研究者は、その後のやり取りで補えるからといって、最初から十分な証拠を提出する必要がなくなるとは考えるべきではありません。
裏付けとなる証拠は、Webアプリケーション、AIシステム、Microsoftが保有するオープンソースソフトウェア、オンプレミス製品によって異なります。
脆弱性の種類によっては、クラッシュダンプ、Time Travel Debuggingのトレース、コールスタック、PoCのソースコード、スクリプト、Process Monitorのログ、パケットキャプチャ、動画によるデモの提出が求められる場合があります。
オンプレミス製品の場合、メモリ破損やサービス拒否（DoS）の発見では、クラッシュデータ、コールスタック、PoCのソースコードが必要になることがあります。
ファイルリダイレクトに関する報告ではProcess Monitorのログが、NTLM強制認証やリレーに関する発見ではパケットキャプチャが必要になる場合があります。Webアプリケーションの報告では、動画による証拠やスクリプトが求められることもあります。AI関連の報告は、引き続きMicrosoftが公開しているAI報告ガイドラインに従う必要があります。
Microsoftによると、再現手順、PoCの詳細、技術的な説明、影響に関する情報は、Researcher Portalの提出フォームの該当欄に直接記入する必要があります。
添付ファイルの報告書で、これらの入力欄の代わりにすることはできません。研究者はあわせて、プログラムの対象範囲、テストのルール、協調的な脆弱性開示の要件を守る必要があり、影響を実証するためだけに許可された範囲を超えて活動してはなりません。
同社は、今回の変更の背景には、AIを活用した調査の増加もあるとしています。MicrosoftはAIの利用を推奨していますが、提出される報告は技術分析を正確に反映し、証拠を含んでいなければなりません。狙いは、評価の迅速化、確認依頼の削減、そして実用的な調査により見合った報奨金の実現です。
脅威調査を効率化し、手作業を減らすためにANY.RUNを活用している16,000以上のSOCチームに加わりましょう。チームでの導入を検討する
翻訳元: https://cyberpress.org/microsoft-changes-bug-bounty-rules/
