このドキュメントはVulnerability Disclosure - OWASP Cheat Sheet Seriesの日本語訳です。
このチートシートは、セキュリティ研究者と組織の両方に、脆弱性の公開プロセスに関するガイダンスを提供することを目的としています。これは、共同作業が非常に重要な分野ですが、両者の間に対立が生じることもよくあります。
研究者は
- すべてのテストが合法的で認可されていることを確認すること
- 他人のプライバシーを尊重すること
- 組織のセキュリティチームに連絡するための合理的な努力をすること
- 脆弱性を検証・再現できるように、十分な詳細情報を提供すること
- 確立されたバグバウンティプログラム以外で、脆弱性の報告に対して支払いや報酬を要求しないこと
組織は
- 研究者が脆弱性を安全に報告するための明確な方法を提供すること
- バグバウンティプログラムの範囲と条件を明確に設定すること
- 合理的な時間軸で報告に対応すること
- 研究者とオープンにコミュニケーションをとること
- 研究者に対して法的措置をとるようなことはしないこと
- 必要に応じてCVE-IDの取得を要求すること
- 明確なセキュリティアドバイザリと変更履歴を公開すること
- 報酬やクレジット表記を提示すること
脆弱性を開示する際には、いくつかの異なるモデルがあり、以下のセクションで紹介します。
プライベート・ディスクロージャー・モデルでは、脆弱性は非公開で対象となる組織に限定して報告されます。組織は脆弱性の詳細を公開するかどうかを選択できます。しかしながら、この選択は研究者ではなく組織の判断で行われるため、多くの脆弱性が公開されることはありません。バグバウンティプログラムの大半は、研究者がこのモデルに従うことを要求しています。
このモデルの主な問題点は、ベンダーが対応しない場合や、脆弱性を修正しないことを決めた場合、その詳細が公表されない可能性があることです。歴史的には、企業が脆弱性を無視したり隠そうとしたりすることに研究者がうんざりして、完全公開のアプローチをとるようになりました。
フル・ディスクロージャー・アプローチでは、脆弱性が発見され次第、その脆弱性の詳細情報が公開されます。つまり、攻撃者はパッチが提供される前に、脆弱性の詳細情報（時にはエクスプロイトコードを含む）を入手できることになります。フル・ディスクロージャー・アプローチは、主に報告された脆弱性を無視している組織に対して、修正プログラムの開発と公開を迫るために用いられます。
このため、フル・ディスクロージャー・アプローチには非常に議論の余地があり、多くの人から無責任だと思われています。一般的には他のすべての方法が失敗した場合や、エクスプロイトコードがすでに公開されている場合など、最後の手段としてのみ考慮されるべきです。
レスポンシブル・ディスクロージャーとは、上記2つのアプローチの中間的なものです。レスポンシブル・ディスクロージャーでは、最初の報告は非公開で行い、パッチが利用可能になった時点で脆弱性の詳細情報を公開します（パッチのインストールに時間を要する場合もあります）。
多くの場合、研究者は、組織が報告に回答する、あるいは、パッチを提供するための期限も提示します。この期限が守られない場合、研究者はフル・ディスクロージャー・アプローチを採用し、その詳細を公表することがあります。
GoogleのProject Zeroも同様の手法を採用しており、組織がパッチを公開したかどうかに関わらず、90日経過後に脆弱性の詳細情報を公開しています。
このセクションはセキュリティ研究者が組織に脆弱性を報告する方法についてのガイダンスを提供することを目的としています。
セキュリティ調査や脆弱性の報告を行う前に、管轄の法律を知り、理解していることを確認してください。このチートシートは法律上のアドバイスではなく、そのように扱うべきではありません。
以下のポイントでは、検討すべきいくつかの分野を紹介しています。
- バグバウンティや類似のプログラムの下でテストを実施する場合、組織はセーフハーバー・ポリシーを確立している可能性があり、プログラムの対象範囲と規則の範囲内であれば、合法的にテストを実施することができます。対象範囲を注意深く読むようにしてください。対象範囲や規則を逸脱すると、犯罪行為となる可能性があります。
- 国によってはリバースエンジニアリングを制限する法律があるため、ローカルにインストールされたソフトウェアに対するテストが許可されない場合があります。
- セキュリティの脆弱性に関する情報を提供する条件として、あるいはその詳細を公表したり業界の規制当局に報告したりしないことと引き換えに、支払いやその他の報酬を要求してはいけません。
- バグバウンティの支払いを受けた場合、これらは一般的に所得とみなされ、課税対象となる可能性があります。この収入を報告し、適切な税金を支払うことは、受け取った側の責任です。
- 業務の一環として、あるいは雇用者が所有する機器に脆弱性を発見した場合、雇用者はこれらを報告したり、バグ報奨金を請求したりすることを妨げる場合があります。契約書をよく読み、その前に法的なアドバイスを受けることを検討してください。
脆弱性を報告するための最初のステップは、適切な報告先を見つけることです。ディスクロージャーポリシーを明確に公開している組織もありますが、多くの組織では公開していないため、問題を報告する適切な場所を見つけるのは難しいでしょう。
明確なディスクロージャーポリシーがない場合、以下の場所に連絡先がある場合があります。
- BugCrowd、HackerOne、huntr.dev、Open Bug Bounty、Standoffなどのバグバウンティプログラム
- RFC 9116に従い、ウェブサイトの
/.well-known/security.txtに配置されたsecurity.txtファイル - 既存のトラッキングシステム(issue tracking system)
security@またはabuse@などのメールアドレス- ウェブサイトの一般的な「お問い合わせ」ページ
- ソーシャルメディアプラットフォーム
- 組織への電話連絡
- コミュニティへの働きかけ
セキュリティの専門家ではない人に（特にソーシャルメディア上で）連絡を取る場合、最初の連絡を受けた人に脆弱性の詳細を開示するのではなく、適切な連絡先スタッフの詳細を要求してください。
組織に直接連絡できない場合は、国やセクターごとのCERTが支援してくれるかもしれません。
追記：日本の場合はIPA 独立行政法人 情報処理推進機構への届出制度があります。
セキュリティ担当者が特定されたら、脆弱性の詳細について最初の報告を行う必要があります。この報告は、暗号化されたチャネル（PGPキーの使用など）で行うのが理想的ですが、多くの組織はこれをサポートしていません。
最初の報告には、次を記載すべきです:
- 脆弱性を理解し、再現できるように十分な詳細情報を提供すること
- HTTPリクエストとレスポンス、HTMLスニペット、スクリーンショット、またはその他の裏付けとなる証拠
- 報告する前に、個人情報を消去してください
- 組織によっては、脆弱性が存在しなかったと主張する場合がありますので、脆弱性が存在したことを証明する十分な証拠を用意してください
- プルーフ・オブ・コンセプト(PoC)コード（ある場合）
- 脆弱性の影響
- 適切と思われる参考文献など
多くの場合、特に小規模な組織では、セキュリティのバックグラウンドを持たない開発者やITスタッフがセキュリティレポートを扱うことがあります。つまり、彼らは多くのセキュリティ概念や用語に精通していない可能性があるため、報告は明確かつシンプルな言葉で書くべきです。
また、その問題をどのようにして緩和したり解決したりするかについて、推奨事項を提示することも有益でしょう。しかし、システムやアプリケーションの詳細が分かっている場合や、推奨事項に非常に自信がある場合を除き、開発者にもっと一般的なガイダンス（OWASP チートシートなど）を紹介した方が良いかもしれません。
脆弱性の詳細を一定期間後に公開することを計画している場合（一部の責任ある情報開示の方針に従った場合）、その旨を最初のメールで明確に伝える必要があります。ただし、受信者を脅しているように聞こえないようなトーンで伝えるようにしてください。
確立されたバグバウンティプログラムを組織が持っていない場合、最初の連絡で支払いや報酬について尋ねることは避け、問題が認識される（あるいは理想的には修正される）まで待ってください。特に、脆弱性の詳細を明らかにする前に支払いを要求してはいけません。 これは、よく言えば、会社を騙そうとしているように見え、悪く言えば、恐喝になるかもしれません。
単純な脆弱性であれば、最初の報告だけで解決できるかもしれませんが、多くの場合、研究者と組織の間で何度もメールのやり取りが行われます。特に、より複雑な脆弱性の場合、開発者や管理者は問題を解決するための追加情報や推奨事項を求めることがあります。また、修正プログラムが実行された後に、問題の再テストの支援を求められることもあります。この再テストを実施する義務はありませんが、要求が妥当である限り、修正プログラムに対するフィードバックを提供することは非常に有益です。
また、組織の反応が鈍い場合や、定められた脆弱性の公開期限が近づいている場合には、その組織に催促をする必要があるかもしれません。情報開示のプロセスが敵対的になると、どちらの当事者も利益を得られませんので、このコミュニケーションがプロフェッショナルでポジティブなものであることを確認してください。
問題の解決に時間がかかっている場合は我慢してください。開発者は組織内のさまざまな人から大きなプレッシャーを受けており、完全にオープンなコミュニケーションをとることができないかもしれません。企業内での修正プログラムの試行、開発、レビュー、テスト、デプロイには、多くの研究者が予想している以上のかなりの時間がかかります。
あらゆる努力をしても、組織によっては、セキュリティに関心がなかったり、連絡が取れなかったり、脆弱性を開示する研究者を積極的に敵視したりする場合があります。場合によっては、研究者に対して法的措置を取ると脅すことさえあります。このようなことが起こると、研究者は非常に落胆しますが、思い詰めないことが重要です。このような事態に陥った場合、いくつかの選択肢が考えられます。
- 脆弱性を公開し、ネガティブな反応に対処し、訴訟に発展する可能性もあります。彼らは高価な弁護士を抱えており、あらゆる種類の法的措置を取るには費用と時間がかかります。この方法を取る前に、本当にそれだけの価値があるのかを自問してみてください。
- 脆弱性を匿名で公開する。しかし、あなたが既にその組織と連絡を取り、脆弱性を報告しようとしていた場合、その開示の背後に誰がいるのかがかなり明らかになっている可能性があります。この方法を取る場合は、自分自身を守るために十分な運用上のセキュリティ対策を講じていることを確認してください。
- 業界団体やデータ保護当局などの第三者に脆弱性を報告する。
- 別のことに取り組みましょう。
セキュリティに純粋な関心を持ち、セキュリティ研究者に対して非常にオープンで協力的な組織は数多くあります。脆弱性が極めて深刻なものでない限り、無関心な組織のために自分のキャリアや生活を犠牲にしたり、リスクを負ったりする価値はありません。
脆弱性にパッチが適用された（または適用されなかった）後、その詳細を公開するかどうかを決定する必要があります。これは、理想的にはベンダとの話し合いによって行われるべきであり、最低でもベンダには公開するつもりであることを通知し、公開された詳細へのリンクを提供する必要があります。開示内容は通常次の通りです。
- 脆弱性とその影響についての高レベルの要約
- どのバージョンに脆弱性があり、どのバージョンが修正されたかの詳細
- 技術的な詳細、または概念実証のためのコード(PoC)
- 緩和策やワークアラウンド
- ベンダーが公開しているアドバイザリへのリンク
- 発見、ベンダーとのコミュニケーション、リリースまでのタイムライン
組織によっては詳細情報をまったく公開しないことや、ユーザーがセキュリティパッチをインストールするための時間を確保するために公開を遅らせることを要求する場合があります。組織との良好な関係を維持するためにも、この点について妥協点を探してみる価値はあるでしょう。
動作するのPoC（または動作するエクスプロイトコード）を公開するかどうかは、議論の対象となります。これを攻撃者的な行動と捉え、犯罪者がユーザーを危険にさらすのを直接手助けしていると主張する人もいるでしょう。一方で、このコードは、システム管理者やペネトレーションテスト担当者がシステムをテストするために使用することができます。また、攻撃者は、その脆弱性が十分に価値のあるものであれば、実用的なエクスプロイトコードを開発したり、リバースエンジニアリングを行ったりすることができます。
敵対的な状況（組織が無反応であったり、所定の期間が経過した後など）で詳細を公開した場合、脅迫や法的措置を受ける可能性があります。これに法的根拠があるかどうかは、管轄する地域や、その組織と何らかの秘密保持契約を結んでいるかどうかによって異なります。このような行為を行う前に、自分の法的立場を理解しておいてください。
多くのバグバウンティプログラムでは、研究者が組織の同意なしに詳細を公開することを禁じていることに注意してください。公開した場合、報奨金の没収やプラットフォームからの追放につながる可能性がありますので、公開する前にプログラムのルールを確認してください。
このセクションは、組織が脆弱性レポートをどのように受け入れ、受け取るかについてのガイダンスを提供することを目的としています。
バグバウンティプログラムは、研究者が脆弱性を発見し、組織に報告することを奨励するために、報酬を提供するものです。報酬は通常、金銭ですが、物品（記念品）の場合もあります。このプロセスは、BugCrowdやHackerOneなどの第三者機関によって管理されることが多く、研究者と組織の間を仲介します。
バグバウンティプログラムを導入する際には、次の領域を明確に定義する必要があります:
- どのようなシステムやアプリケーションが対象となるか
- 本番環境かステージング/テスト環境か？
- 第三者が管理・所有するシステムを除くか
- どのような種類の脆弱性が報奨金の対象となるのか（SSL/TLSの問題？ HTTPセキュリティヘッダの欠落？ バージョンの公開？）
- セーフハーバー・ポリシーなどの法的規定
- disclose.ioプロジェクトでは、いくつかのポリシー例を提供しています
- 法的なアドバイスは、このチートシートではなく、弁護士から受けてください。
- 報償金をいくらにするか、どのように決定するか
- 膨大な数の脆弱性が発見された場合、このプログラムは非常に高価なものになる可能性があります
- 少なすぎると研究者がプログラムに見向きもしないかもしれません
- 初期対応、確認、支払い、問題解決までのタイムライン
バグバウンティはマイクロソフトをはじめとする多くの大企業で採用されており、米国国防総省など、商業部門以外でも利用され始めています。しかし、小規模な組織にとってはバグバウンティは大きな課題をもたらし、時間とリソースに相当な投資が必要となります。これらの課題には以下のようなものがあります。
- 報告に対応するための十分な時間とリソースがあること
- 報告を効果的にトリアージするための十分なスキルを持ったスタッフがいること
- レポートには大量の誤報が含まれている可能性があります
- 管理されたバグバウンティプログラムは、（コストをかけて）初期のトリアージを行うことで役立つかもしれません
- 大量の誤認識や無価値なレポートへの対応
- 実稼働中のシステムを個人がテストすることによる影響（未熟な攻撃者が理解できない自動化ツールを実行することも含む）
- 正当なテストトラフィックと悪意のある攻撃を区別できないこと
- 研究者が対象範囲を超え、テストすべきではないシステムをテストしてしまうこと
- プログラムを運営するための金銭的コスト（年間数十万ドルの報奨金を支払う企業もあります）
- プログラムの運営方法に不満を持つ研究者への対応（報奨金の額に異議を唱えたり、報告された課題が重複していたり範囲外であったりすると怒るなど）
これらの潜在的な問題はありますが、バグバウンティプログラムは、アプリケーションやシステムの脆弱性を発見するための素晴らしい方法です。しかし、バグバウンティプログラムは、すでに成熟した脆弱性の開示プロセスを持ち、脆弱性を解決するための強力な内部プロセスに支えられている組織のみが利用すべきです。
プロセスの中で最も重要なステップは、セキュリティ・リサーチャーがあなたの組織に連絡する方法を提供することです。セキュリティ・リサーチャーが連絡を取りやすければ、セキュリティ・レポートを受け取る可能性が高くなります。以下のリストには、このために使用される一般的なメカニズムがいくつか含まれていますが、これらをより多く実装できると良いでしょう。
- 「お問い合わせ」ページにセキュリティ専門の連絡先を設置
- バグトラッカーでセキュリティ問題を報告するための専用の説明書
- 一般的な
security@のメールアドレス - RFC 9116に従い、ウェブサイトの
/.well-known/security.txtにsecurity.txtファイルを配置する - サードパーティのバグバウンティプログラムの利用
また、窓口のスタッフ（メインの連絡先、ウェブチャット、電話回線を監視するスタッフなど）が、セキュリティ問題の報告をどのように処理するか、また、その報告を組織内の誰にエスカレーションすべきかを認識していることが重要です。
連絡先に加えて、研究者が脆弱性を報告する際に従うべきガイドラインを提示するのも良いでしょう。これには次のようなものがあります。
- 問題の確認と解決に役立つと思われる具体的な情報を要求すること
- バグトラッカーで問題に特定のカテゴリを使用したり、機密扱いにしたりすること
- 暗号化通信のためのPGPキーの提供
- 初動対応とトリアージのためのタイムラインを確立
- セーフハーバー規定の制定
研究者と組織の間のコミュニケーションは、脆弱性開示プロセスの中でも最も難しい点の一つであり、双方が不満を抱き、プロセスに不満を持つことになりがちです。
以下のアウトラインは、理想的なコミュニケーションプロセスの一例です。
- 研究者が追加情報を提供するための明確な仕組みを持って、最初の連絡先の要求に応えること
- 脆弱性の詳細を認識し、トリアージを実行するためのタイムラインを提供する
- 必要に応じて、追加の説明や詳細を求める
- 脆弱性を確認し、修正プログラムを導入するためのスケジュールを提示する
- 提供される報酬や賞金の詳細を確認する
- 必要であれば、研究者に脆弱性の再テストを依頼する
- 脆弱性が解消されていることを確認する
このプロセスを通じて、現在の状況と、脆弱性をトリアージして修正するまでの予想されるタイムラインを定期的に更新します。たとえこれらのスケジュールが確定していなくても、継続的なコミュニケーションによって、脆弱性が忘れ去られていないという安心感を得ることができます。
脆弱性を発見したと称して組織に近づき、その詳細を伝える前に支払いを要求する人物がいます。このような要求は正当なものかもしれませんが、多くの場合、単なる詐欺です。
1つの選択肢は、仲介されたバグバウンティープラットフォームを通じて情報開示を行うよう依頼することです。これは詐欺師がこのようなプラットフォームを利用しようとする可能性が低いため、双方にとって一定の保護となります。
脆弱性が解決されたら（そして再テストされたら）、そのソフトウェアのセキュリティアドバイザリで詳細を公表しなければなりません。重要なことはセキュリティ問題の詳細を公表することは、ベンダを悪者にするものではないということです。すべてのソフトウェアにはセキュリティ上の脆弱性があり、それを処理し公開するための明確で確立されたプロセスを示すことは、問題を隠そうとするよりもはるかにソフトウェアのセキュリティに対する信頼性を高めることになります。
少なくともセキュリティアドバイザリには以下の内容が含まれていなければなりません:
- 脆弱性の影響を含む高レベルの要約
- 脆弱性のあるバージョンの明確なリスト
- パッチバージョンの明確なリスト
- ソフトウェアに脆弱性がある場合の注意点（例えば、特定の構成のみが影響を受ける場合など）
- 一時的な解決策として実施可能な回避策や緩和策
- 脆弱性のCVE
可能であれば、次も含めると良いでしょう:
- 脆弱性開示プロセスのタイムライン
- 脆弱性を発見した研究者のクレジット
- 脆弱性の技術的詳細
- IDS/IPSのシグネチャやその他の侵害された痕跡(IoC)
セキュリティアドバイザリは、開発者やシステム管理者が簡単に見つけられるようにする必要があります。一般的な公開方法には次のようなものがあります。
- ウェブサイトにある「セキュリティ」または「セキュリティ・アドバイザリ」の専用ページ
- セキュリティ関連のメーリングリストやフォーラム
- メインのchange logやリリースノートからのリンク
研究者の中には、その脆弱性に関する独自のテクニカル・レポートを公開している場合があります。このレポートには、通常、その脆弱性を悪用するために必要な詳細情報（場合によっては、実際に動作するエクスプロイトコードも）が含まれています。より深刻な脆弱性の場合、エクスプロイトコードが利用可能になる前にシステム管理者がパッチをインストールする時間を確保するために、研究者に完全な詳細情報の公開を一定期間（1週間など）遅らせるよう依頼するのが賢明でしょう。しかし、パッチがリリースされれば、攻撃者はその脆弱性をリバースエンジニアリングして独自のエクスプロイトコードを開発することができるため、完全なリリースを遅らせることの価値は限られています。
プライベートなシステムの脆弱性については、その脆弱性が解決された後に詳細を公開するかどうかを決定する必要があります。ほとんどのバグバウンティプログラムでは、問題が解決された後に詳細を公開するかどうかの選択肢を組織に与えていますが、通常は必須ではありません。
これらの情報を公開することで、組織がセキュリティに対して積極的かつ透明性の高いアプローチをとっていることを示すことができますが、一方で、恥ずかしい不備や誤った設定が公開されてしまう可能性もあります。将来、情報漏洩やデータ流出が発生した場合には、組織内のセキュリティ文化が脆弱であることの証拠として使用される可能性もあります。さらに、内部の技術的な詳細が公開され、攻撃者が他の同様の問題を特定するのに役立つ可能性もあります。このように、この決定は慎重に検討されるべきであり、法的アドバイスを受けるのが賢明かもしれません。
研究者がバグバウンティプログラム以外で脆弱性を発見して報告（基本的に無料のセキュリティテストを提供）し、脆弱性の公開プロセスを通じてプロフェッショナルで親切な行動をとった場合、今後もこのような積極的な交流を奨励するために、何らかの報酬を提供するのが良いでしょう。金銭的な報酬が不可能な場合は、以下のような他の多くのオプションを検討してください:
- 組織が提供するサービスや製品の割引やクレジット
- 仮想的な報酬（ゲーム内の特別なアイテム、カスタムアバターなど）
- Tシャツやステッカーなどのノベルティ（記念品）
- 殿堂入り、またはそれに類するもの