オープンソース プロジェクト向けに
協調的脆弱性開示プロセスを実装するためのガイド

（このページは Guide to implementing a coordinated vulnerability disclosure process for open source projects の参考訳です。）

---

目次

• はじめる前に
  • このガイドについて
  • 脆弱性を報告する人（別名「発見者」）とは誰ですか？
  • 脆弱性報告者が求めるものはなんですか？
• 脆弱性管理インフラストラクチャをセットアップする
• 脆弱性管理チーム (VMT) を作成する
  • レポートの受け付けを用意する
  • プライベート パッチの開発を有効にする
  • CNAの連絡先を確立する
  • 公開禁止リストの作成
  • コミュニケーション テンプレートの選択
• 脆弱性管理プロセスを公開する
• 脆弱性対応プロセスを適用する
  • 手順書
  • 対応プロセス
• 協調的脆弱性開示に対する一般的な課題のトラブルシューティング
• 謝辞

はじめる前に

このガイドは、オープンソース プロジェクトのメンテナーが協調的脆弱性対応プロセスを作成および管理できるようにすることを目的としています。

完璧なソフトウェアはありません。ソフトウェアは人間またはAIによって作られますが、どちらも時々間違いを犯します。これは、オープンソース ソフトウェアだけでなく、クローズド ソース ソフトウェアにも当てはまります。オープン ソース ソフトウェア(OSS)の場合、この問題は、OSSを非常に強力にする要因である複数のコントリビューターによる高度に分散された開発のため、さらに困難になる可能性があります。プロジェクトが終了するまでのある時点で、ユーザー、コントリビューター、セキュリティ研究者などの誰かが、プロジェクトの安全性と有用性に影響を与える脆弱性を発見することがあります。このガイドに沿って対応することで、その準備が整います。

このガイドについて

このガイドは、個人およびOpen Source Security Foundation Vulnerability Disclosure Working Groupの寄稿によって作成されています。OpenSSF Vulnerability Disclosure Working Groupは、協調的脆弱性開示 (「責任ある開示」とも呼ばれます) が、ほとんどのオープンソース プロジェクトにとって適切なモデルであると考えています。このガイドのアドバイスはそのモデルに従っています。このガイドのすべてのアドバイスがすべてのオープンソース プロジェクトに適用されるわけではありません。プロジェクトに合わせて推奨事項や資料の変更が必要となる場合があります。

脆弱性を報告する人（別名「発見者」）とは誰ですか？

脆弱性の報告者（別名「発見者」）は、プロジェクトの脆弱性を報告する人です。セキュリティ問題がどのように報告されるのか、またなぜ人々がそれを報告するのかについては、単一の例はありません。これは、脆弱性の管理と開示を難しくする要因の 1 つです。つまり、相手側の人間は、脆弱性の開示に対して独自の欲求、ニーズ、利益を持っている人間です。これが、現在「責任ある開示」よりも「協調的脆弱性開示」(CVD)というフレーズが好まれる理由の1つです。一般に、報告者とプロジェクト代表者という少なくとも2つの関係者が存在し、うまく協力し対応する必要があります。

OpenSSF Vulnerability Disclosure working groupは、ペルソナを使用して、CVD プロセス内で対話する人物/役割を示しています。脆弱性の報告者はそれらのペルソナの1つであり、セキュリティ コミュニティ内では発見者と呼ばれることがよくあります。この報告者のペルソナは、セキュリティの脆弱性を開発者に報告することについて広範囲でさまざまな欲求を表します。

非常に大まかに言うと、報告者は2種類に分類されます。プロジェクトに直接関係がある報告者と間接的に関係がある報告者です。直接関係する報告者は、プロジェクトのアクティブなユーザーであるか、直接関係するユーザーに代わって作業を行うために雇われています。この報告者は、直接関係するユーザーであるか、直接関係するユーザーのために働いているため、問題にパッチが適用され、スムーズに展開されるようにするという強い動機を持っています。彼らはパッチの開発とテストを手伝いたいかもしれません。彼らには問題を修正するまで見届ける理由があるからです。

間接的な報告者は、セキュリティ研究者で、ペネトレーションテストやセキュリティ監査を行う人々、または自身のプロジェクトの問題を追跡調査した際に、この問題に遭遇したという可能性があります。彼らは、自分たちの仕事を公表することについての調整を含め、パッチ適用と開示のプロセスに深く関与したいと考えている場合もあれば、単に問題を報告してそれ以上関与したくないと考えている場合もあります。

報告者が実際にプロジェクトのコントリビューターまたはメンテナーである可能性がある場合においても注意が必要となります。このような場合、調整は簡単ですが、基本的には同じプロセスに従う必要があります。特に、すべての利害関係者が適切な認識と是正措置を取ることができるように、引き続き適切な公開を行う必要があります。

報告者が脆弱性について伝えることで、プロジェクトチームに対する親切な行動を取っています。

報告者は、プロジェクトの潜在的な脆弱性を報告する際に、おそらく複雑な多くの動機や要望を持っているでしょう。残念ながら、脆弱性を報告しないインセンティブがあり、場合によっては金銭的な利益も関係してきます。脆弱性の報告とプロジェクトのトリアージと処理方法に関する期待を明確することは、問題が解決に向かう際の摩擦を減らすのに役立ちます。CVDを使用する最終的な目標は、そのソフトウェアの消費者に対するリスクを軽減することです。

時間を割いて開発者を見つけ、プロジェクトのプロセスを確認してくれた報告者には感謝をすることが重要です。そのための方法の1つは、プロジェクトの問題を受け取るプロセスについて、可能な限りわかりやすく見つけてもらえるようにし、スムーズで、摩擦が少ないものにすることです。その他の報告者に感謝を示す方法は、後の対応プロセスで共有されます。

脆弱性報告者が求めるものはなんですか？

誰かがセキュリティの脆弱性を見つけてプロジェクトに報告する場合、その主な目的は、プロジェクトの安全性を高めるために脆弱性を修正してもらうことです。したがって、ユーザーがソフトウェアの最新バージョンに更新すると、報告されたソフトウェアの問題が対処され脆弱性がなくなるようにするため、脆弱性のパッチを作成してくれるプロジェクトの管理者またはメンテナーを探しています。

多くの場合、脆弱性を報告する人は、他の付随的なことが起こることを望むかもしれません。発見者が求める一般的で合理的なものの例として次のようなものがあります。

• CVEの発行：特定の商用製品またはOSS 製品またはプロジェクトのセキュリティ上の問題には、製品の特定のバージョンの特定の脆弱性を指すCVE番号が発行されることがよくあります。CVE番号は、システムのユーザーが該当するバージョンのソフトウェアが持つセキュリティ リスクについて理解し、代わりのパッチ適用済みのバージョンがどれであるかの判断を助けます。セキュリティ研究者は、該当するCNAから報告された脆弱性のCVE IDを検索し、取得しようとします。これは一般的な対応で、安全で、追加の費用がかかったり、プロジェクトに損害を与えたりするものではありません。必要に応じて、CVEプログラムの詳細についてはここ、またはCommon Vulnerabilities and Exposures wikipediaのページで学ぶことができます。
• 謝辞：脆弱性研究者の貢献に対して公に認め評価を与えることは、彼らがプロジェクトに提供した価値を示す一般的な方法です。通常、これはアップデートが発行されるときにパッチノートに含まれます。
• テクニカル アドバイザリを発行する機能：セキュリティ研究者は、報告されたセキュリティ上の問題を修正するパッチをリリースする日に、自分 (またはその雇用主) のWebサイトにテクニカル アドバイザリを公開しようとする場合があります。テクニカル アドバイザリは、セキュリティ更新プログラムに対するユーザーの認識を向上させ、パッチを適用してリスクを軽減することを奨励するとともに、研究者の調査結果を示すことに役立ちます。セキュリティ上の問題に対する修正のリリース日にアドバイザリを同時に発行することは、オープンソース ソフトウェアと商用ソフトウェアの両方で一般的に行われています。一般的なテクニカル アドバイザリには、レポートの概要、脆弱性の影響、脆弱性の詳細、開発者やエンド ユーザーへの推奨事項、ベンダー/影響を受けるプロジェクトと脆弱性の報告者との間における今後必要となる主要なやり取りのタイムラインが含まれます。

あなたのプロジェクトの脆弱性を報告する無償のセキュリティ研究者が(あなたが選択したバグ報奨金プログラムの一貫でない限り)報告したセキュリティの調査結果に関する詳細と引き換えに金銭を要求することは推奨されていません。

脆弱性管理インフラストラクチャをセットアップする

脆弱性レポートを受け取る前に、準備をしておくことが重要です。CIIベスト プラクティス バッジを取得するため、脆弱性レポートを受け取る準備が必要です。このセクションでは、準備方法について説明します。次のセクションでは、脆弱性レポートを実際に処理する方法について説明します。

プロジェクトにおける脆弱性処理の期待値 (別名「セキュリティ ポリシー」) を確立する

すべてのプロジェクトには、異なる目標、機能、規範があります。セキュリティの脆弱性に対処するための重要な最初のステップは、プロジェクトが脆弱性レポートをどのように受け入れるか、また報告者のコミュニケーションと対応についてどのような期待があるかを、利用者または協力者と共有することです。より大規模で経験豊富なプロジェクトには、オープン ソース内でセキュリティ バグを修正した経験を持つセキュリティ スペシャリストの専任チーム (下記のVMTを参照) が存在する可能性があります。小規模から中規模のプロジェクトでは、これらの訓練を受けた専門家にアクセスできない可能性が高く、その種の作業は単にプロジェクトの専門外です。すべてのソフトウェアには欠陥があることを理解することが重要です。これらの問題の中には、セキュリティに影響を与える側面 (データの機密性、完全性、可用性、または監査ができることに影響を与える) があるものもあります。プロジェクトの開始時にちょっとした準備をしておくことで、この種の報告があったときにチームが何をするかについて話し合い、文書化することができます。

プロセスとツールは、メンテナーやコントリビューターにとって複雑で負担のかかるものである必要はありませんが、報告者がバグレポートを責任のある開発者に確実に渡すことができるように、以下の事項をプロジェクトによって明確に文書化する必要があります。

• セキュリティ脆弱性とされるものについてチームに連絡する方法
• プロジェクトがより広範に共有することを決定するまで脆弱性レポートの内容を非公開にできること
• この問題に関するコミュニケーション/コラボレーションに対する報告者の期待が適切に設定されていること

オープン ソース プロジェクトにおける基本的なセキュリティ ポリシーのテンプレートの例は、このOpenSSFリポジトリ内にあります。プロジェクトは、いくつかの最小限の変更を加えてそれを再利用したり、既存のドキュメントで役立つ要素を利用したりできます。

このガイドでは、これらのトピックと、脆弱性対応の経験豊富なチームが参考にできるその他のオプションについて説明します。

脆弱性管理チーム (VMT) を作成する

セキュリティ問題の解決中にNeed To Knowの原則(必要な情報を必要な人だけが知るという原則)に保つには、問題に対応でき、対処中は機密保持を信頼できる小規模なチームが必要です。脆弱性レポートを管理するこの小さなチームが脆弱性管理チーム (VMT) です。

VMTの主な責任は調整です。VMTはプロセス全体を通じて報告者の連絡窓口となり、報告者が希望する情報を提供し、プロセスを通じてセキュリティの問題を継続的に進めます。一部のチーム メンバーにはプロジェクトのリリース仕組みとセキュリティに精通することが求められますが、それは全員である必要はありません。「調整」の一環として、チームの知識を超える支援が必要なときに、いつ誰を連れて行けばよいかを知ることが挙げられます。

小規模なプロジェクト (1～5人のメンテナー) の場合、そのメンテナーがVMTとなる場合があります。大規模なプロジェクトでは、この作業をメンテナーで分担するなど、複数人のメンテナーで対応する場合があります。

推奨事項：大規模なプロジェクトの場合は、セキュリティ、エンジニアリング、プログラム管理の経験を持つ3～7人のチーム メンバーを選択します。小規模なプロジェクトの場合は、信頼できるメンテナーを選択します(全メンテナーが該当するかもしれません)。現実的には、メンテナー間で責任を分担することをお勧めします。少なくとも2 人のチーム メンバーが、開発プラットフォームでセキュリティの問題/アドバイザリを生成するための適切な権限を持っていることを確認してください（例 セキュリティ アドバイザリ用のGitHubの管理者）。

これらのチーム メンバーが問題に関して非公開で共同作業できるように、電子メール エイリアスを作成します。これがレポートの受け付けに利用するエイリアスとは異なることを確認してください。このチーム内調整用のエイリアスを「security@[yourdomain]」にしないでください。これは外部から受け付けによく利用されるエイリアスとなります。

レポートの受け付けを用意する

脆弱性の報告に関連する情報の場所

脆弱性報告者がプロジェクト（具体的にはプロジェクトのVMT）に連絡して、コード内で見つかったセキュリティの問題を報告できる、簡単でわかりやすい方法が必要であり、報告者にそれが何であるかを伝える必要があります。通常、セキュリティの脆弱性を報告する方法は、プロジェクトのセキュリティ ポリシーやGitHubの SECURITY.mdファイル、またはプロジェクトのWebサイト上の見つけやすいページに記載されています。ここでの目標は、「それをわかりやすくする」ことです。

このセクションでは、脆弱性発見者がセキュリティの脆弱性を報告するためにどのようにプロジェクトへ連絡すればよいかについての説明をどこに記述すべきかについて説明します。次のセクションでは、実際に脆弱性レポートを受け取るためにどのような仕組みやコミュニケーションを取ればよいかについて説明します。

GitHubを利用している場合

GitHubでは、発見されたセキュリティの脆弱性を研究者がプロジェクトに報告する方法に関する説明を含むセキュリティ ポリシーを作成できます。GitHubセキュリティ アドバイザリは、GitHubリポジトリの最上位のセキュリティ タブに「セキュリティ ポリシー」および「セキュリティ アドバイザリ」の情報を表示する機能です。「セキュリティ ポリシー」フィールドに値を入力するには、root、docs、または .github フォルダーにSECURITY.md ファイルを作成する必要があります（GitHubドキュメント: セキュリティ ポリシーの作成）。どちらを選択するにせよ、 SECURITY.mdへのリンクをREADMEファイルに含めることをお勧めします。「セキュリティ」タブは誰にとってもわかりやすいわけではありません。READMEがこの情報を目立たせることができます（開示情報をREADMEに入力するだけでは、セキュリティ タブに表示されません）。

他のサービスを利用している場合

プロジェクトのWebサイトなどに、研究者が発見したセキュリティの脆弱性をプロジェクトに報告する方法の案内を含むセキュリティ ポリシーを記述することも、シンプルに「セキュリティの脆弱性を報告する」ための具体的な連絡先情報を含めることもできます。セキュリティポリシーは、プロジェクトの問題の報告方法を示す文書と同じ場所に配置することをお勧めします。そして合わせて明確に「セキュリティの問題報告する方法」を示すと良いでしょう。このページがトップレベルのページではない場合は、ランディング ページ、セキュリティに関する機能ページ、問い合わせページ、またはその他のトラフィックの多い目立つページにこのドキュメントへのリンクを追加することをお勧めします。サイトに検索機能がある場合、「脆弱性」、「セキュリティのレポート」、および「セキュリティの問題」は、予め組み込んでおきたい一般的なキーワードです。README.mdまたはSECURITY.mdページがある場合は、そこに配置します（ない場合は追加することを検討してください）。

受け付け方法

脆弱性レポートの受け付け方法は、パッチを非公開で開発およびテストする方法によって異なります。どの方法を選択する場合でも、明確な文書と脆弱性管理チーム (VMT) 全体での一貫性があれば、組織化と即応性を維持することができます（たとえば、レポートの半分が電子メール経由で届き、残りの半分がLaunchpadのセキュリティイシューを通じて届いた場合、コミュニケーションミスが発生します）。必然的に、「間違った」方法でレポートを受け取ることになります。レポートを標準ワークフローに組み込んでもらえるよう配慮し、対応を進めてください。

脆弱性の報告者はあなたのために善意で行動をしてくれています。絶対に必要な手順以外は追加しないでください。バランスを保つ精神に基づき、電子メールを利用したレポートの受け付けを問題ない対応とすることは推奨事項であり、少なくとも代替手段として提供されるべきであるということです。

GitHubを利用している場合

プロジェクトがGitHub上にある場合は、その機能が現在ベータ版のみであっても、セキュリティ脆弱性の非公開の報告を有効にすることをお勧めします。これは使いやすい仕組みであり、その使いやすさが重要となります。

別のサービスの指示にも従うことをお勧めします。特に、GitHubのプライベート レポートの仕組みの代わりとして報告に使用できる電子メール アドレスを含めます。

プライベート レポートを有効にせずに GitHub Security Advisoryを使用することもできますが、プライベート レポートを有効にしない場合は、選択されたユーザーのみが脆弱性を報告できるようにします。

プライベート パッチ開発にGitHub Security Advisoryを使用することを選択した場合、それを補足する方法を次に示します。セキュリティ ポリシーでは、脆弱性レポートをVMTに電子メールで送信するよう報告者に指示する必要があります（SECURITY.mdテンプレートを参照）。次に、VMTはSecurity Advisoryを開き、報告者をコラボレータとして追加します（GitHub Security Advisoryに関するGitHub ドキュメントを参照してください）。脆弱性の開示プロセスに関する質問については、そのエイリアスに電子メールを送信することも適切な対応です。

他のサービスを利用している場合

セキュリティの脆弱性を追跡するためにイシュートラッカー (たとえば、Launchpad、 Buganizer、またはBugzilla) を使用している場合、セキュリティ ポリシーは、そのトラッカーでセキュリティ イシューをオープンするように報告者に指示する必要があります。脆弱性開示プロセスに関する質問や、セキュリティ上の問題を解決する際に問題がある場合はVMTエイリアスに電子メールを送信することも適切です。

セキュリティ イシューの機能を備えたイシュー トラッカーを利用していない場合は、別の方法で取り込む必要があります。受け入れ方法では、スパムの氾濫に対処するために、メッセージのコンテンツへのアクセスを検証済みのID (または少なくとも検証済みの電子メール アドレス)に制限する必要があります。ただし、この方法はアクセスが容易でなければならず、摩擦が少ない必要もあります。通常、これは電子メール アドレスになります。

イシュー トラッカーを使用している場合でも、問題を確実に受け取ることができるように、代替の受け付け方法として利用できる電子メール アドレスを記載してください。

Hop-to-Hopの暗号化を使用した電子メールによる脆弱性レポートの受け入れ

脆弱性レポートを受け入れる電子メール サービス（security@PROJECTNAMEなど）では、Hop-to-Hopの暗号化をサポートすることをお勧めします。さらに、ユーザーにHop-to-Hopの暗号化をサポートする電子メール システムを使用すること、および Webベースの電子メール クライアントを使用している場合は、HTTPSを使用することを推奨します。Gmail、Outlook.com、Oath、runbox.com など、広く使用されている電子メール サービスはすでにHop-to-Hopの暗号化をサポートしています。

Hop-to-Hopの暗号化の推奨は、Mail Transfer Agent Strict Transport Security (MTA-STS)です。MTA-STSには暗号化が必要です。代わりにSTARTTLSを使用することもできます。STARTTLSは暗号化通信への切り替えを試みるため正しく動作すれば通信の傍受を防ぎますが、暗号化が完全に担保されるわけではなく被害を受ける可能性がないわけではありません。少なくとも1つを使用してください。脆弱性レポートが暗号化されずにインターネット上に送信されることを許可しないでください。

Hop-to-Hopの暗号化はEnd-to-Endの暗号化ほど強力ではありませんが、多くのは現在End-to-Endの暗号化を使用するのが難しすぎると感じており、脆弱性レポートを取得することがより重要です。

プライベート パッチの開発を有効にする

後のセクションでは、何かがセキュリティ上の問題なのか、通常の問題なのか、非公開でパッチを適用して公開するものなのかを判断する方法について説明します。それがセキュリティ上の問題であり、パッチを提供する場合は、作業を非公開で開発およびテストする方法が必要になります。該当のパッチを公開した状態でテストすると、パッチを提供する前に、監視をしていた攻撃者が脆弱性を知り、悪用する可能性があります。

GitHubを利用している場合

あなたは次の決断を下す必要があります。プライベート パッチ開発にGitHub Security Advisory機能を使用しますか？ 執筆時点のGitHub Security Advisory の提供機能を踏まえると、GitHubを使用するプロジェクトの場合は、基本的にプライベート開発機能を使用してそこでパッチを生成することをお勧めします。

長所：すべての開発が1つのプラットフォーム内で行われ、外部のコントリビューター(パッチ適用を支援できる報告者やその他の専門家など)を簡単に追加でき、脆弱性が公開されたときに作業を「非公開」から「公開」に切り替えるのが簡単です。

短所：プライベート開発の問題の1つは、変更について広範なフィードバックを得ることができないことです。その結果、修正によって問題が十分に解決されていなかったり、予期せぬ悪い結果が生じたりする可能性があります。特に、このアプローチで提案された新たな変更内容を、公開することなく多くの人々と共有することは簡単ではありません。

脆弱性がすでに公に知られ、広く悪用されている場合、秘密を保とうとすることにメリットはありません。脆弱性がすでに広く公に知られている場合は、おそらく修正プログラムも公に開発する方がよいでしょう（より多くの人に助けてもらい、より多くのフィードバックを得ることができるでしょう）。

また、この記事の執筆時点では、GitHub Security Advisoryの一部として作成されたプライベート フォークはCIシステムのような統合にアクセスできないため（ドキュメントを参照）、ローカルでテストを実行する必要があります。

テスト スイートにまだ含まれていない、別の場所(たとえば、会社の内部)で利用可能なハードウェアまたはシステムに対してテストする必要がある場合は、GitHubのプライベート ブランチの外でプロジェクトをフォークし、開発し、テストした方が早い可能性があります。ただし、これにより、パッチを開発している間、内部フォークをメインに合わせて維持するという課題と、支援できる人に関する制限が生じます。

プライベート ミラーを実行することもできますが、これをデフォルトとしてはお勧めしません。セキュリティ パッチの開発とテストのためにプライベート ミラーを実行する場合は、脆弱性レポートを作成する前に、これをセットアップして運用できるようにする必要があります。

他のサービスを利用している場合

多くのイシュー トラッカーは、セキュリティの問題を通常の問題から分離できます。どのトラッカーを選択する場合でも、脆弱性レポート システムには次の機能を強くお勧めします。

• チケットごとに変更ログが利用可能です。
• メンバーシップを制限でき、メンバーIDは多要素認証と互換性があります
• 非公開の発行/チケットは、開示後に公開することができます。
• 問題や調整のコミュニケーションは一時的なものではありません。
• レポートプロセスでは、対応するプロジェクトでまだ使用されていないサービスや、一般的に使用されていない開発者ツールで、ユーザー アカウントの作成は必要ありません。

CNAの連絡先を確立する

CNA (CVE Numbering Authorities) は、新しい脆弱性にCVE番号を割り当てることができる組織です。CNAにはさまざまなスコープがあり、そのスコープ外ではCVEを発行しません。(例: (架空の) SpeakerCompanyは自社の製品でオープン ソース ソフトウェアを使用していますが、その範囲はSpeakerCompanyソフトウェアにのみ見つかる脆弱性に限定される可能性があり、アップストリームの問題に対するCVEリクエストは処理されません。) CNAは多数あります。VMTの唯一の「事前作業」は、プロジェクトを範囲とするCNAを少なくとも1つ知っておくことと、CVE割り当てのために最初に相談する場所を知っておくことです。CVEの運営を管理する組織である MITREは、オープンソース プロジェクトの「最後の手段のCNA」でもあり、適切なスコープがない場合に使用できます。

公開禁止リストの作成

まず結論をまとめると、公開禁止の通知には慎重な運用と管理が必要であり、VMTに対してさらなる責任が追加され、開示プロセスに追加の時間が必要になります。プロジェクトに重要なベンダー エコシステムがない限り、公開禁止の通知はおそらく必要ありません。

企業がプロジェクトをマネージド サービスとして提供している場合、またはプロジェクトが企業の基盤システムにとって重要であり、その基盤システムがユーザーを危険にさらす可能性がある場合、おそらく「公開禁止リスト」を用意することが適切です。公開禁止リストは、メンバーシップが特定のユーザーに制限されている読み取り専用のアナウンス リストです。プロジェクトと脆弱性の性質によっては、マネージド サービスのユーザーは、ユーザーの危険にさらされる可能性を減らすための措置をプロバイダーに依存する場合があります。公開前に通告を行うことで、サービス プロバイダーは公開後に迅速にパッチを適用し、ユーザーが危険にさらされる時間を短縮できるよう準備する時間が与えられます。

公開禁止の通知は、PRの問題を回避したり、知名度の高いユーザーに優遇措置を提供したりするためのものではありません。それは、ユーザーのシステムを制御するディストリビュータやプロバイダーに準備時間を与えることで、有害なエクスプロイトからユーザーを保護することです。また、ディストリビュータは、さまざまな環境でパッチをテストして評価し、公開リリース前に修正できる問題を報告することもできます。この追加のテスト検証は、複雑なパッチの場合に役立ちます。VMT上の誰かが公開禁止の発表に対する返信を監視していることを確認してください。

公開禁止の通知の使用にはリスクがないわけではありません。公開禁止の通知により、早期にこの脆弱性を知る人の数が増加し、脆弱性が発見されてからパッチが適用されるまでの時間が長くなります。Project Zeroチームは次のように述べています。「公開禁止措置の下で脆弱性を共有すると、漏洩リスクの増加、パッチリリースサイクルの遅延、組み入れ基準の一貫性の欠如など、意図しない結果がいくつか観察されました。」公開禁止の通知の使用を決定するときは、脆弱性の重大度と悪用可能性、パッチ適用の複雑さ(プロバイダーは準備に実際に時間が必要か、それとも簡単に展開できるパッチなのか)、公開禁止リストの利用や範囲について管理で必要となるリソース コストを考慮してください。すべての脆弱性(重大度に関係なく)について、すべてのユーザーが同じように影響を受けるわけではありません。たとえば、脆弱性の悪用がネットワーク環境の上で行われ、一部のユーザーが強力なネットワーク セキュリティ制御を導入している場合、そのユーザーはその影響を受けない可能性があります。そのため、通知には悪用されているコードの経路に関する情報と、影響を受けるセキュリティ設定に関する詳細が含まれる場合があります。

公開禁止リストがプロジェクトに関連する場合は、VMTが管理する制限付きの読み取り専用アナウンス リストを作成する必要があります。VMTは、アクセス要求を承認し、正確なリストを維持する（古いメンバーを削除するなど）責任がありますが、リストへのアクセスを要求するのはプロバイダーの責任です。アクセスを要求するための要件と手順をセキュリティ文書に記載します。

コミュニケーション テンプレートの選択

事前に作成した内容が多ければ多いほど、対応すべき問題が発生したときにやるべきことが少なくなります。セキュリティ ポリシー (SECURITY.md)、公開禁止の通知、および公開テンプレートについては、Templatesのディレクトリを参照してください。

脆弱性管理プロセスを公開する

セキュリティ上の問題が発生した場合にプロジェクトが何を行うか、また通常の時間に加えて時間ベースの開示期限がある場合は、報告者とユーザーの両方にとって有益です。これは、報告者がプロセスを追跡するのに役立ち、ユーザーが開示を見たときに問題がどのように処理されたかを理解するのに役立ちます。このプロセスに従う場合は、このドキュメントにリンクするだけです。ユーザーや報告者は、VMTがアクティブかどうかを知りたい場合もあります。定期的なステータス更新がこれに役立ちます。

脆弱性対応プロセスを適用する

手順書

脆弱性への対応と開示プロセスに関する段階的な手順については、Runbook.mdを参照してください。

対応プロセス

1 問題を受け取ったことを直ちに確認します

問題を受け取ったことをすぐに確認します。この時点では、おそらく問題を評価していないでしょう。あなたは自分が取り組んでいることを彼らに知らせているだけです。これは迅速に、たとえば1～2日以内に行う必要があります。

2 問題を評価する

問題が脆弱性であるかどうかを評価するには、次のものが必要です。

• 報告者が振る舞いを確認した手順を文書化したもの
• 関連するシステム、バージョン、またはパッケージに関する情報

脆弱性として報告されたすべてが脆弱性であるわけではありません。一般に、データの機密性、整合性、または可用性が損なわれる場合、それは脆弱性です。これは、リモート コードの実行、権限の昇格、または意図しないアクセスを有効にすることによって発生する可能性がありますが、脆弱性と他の望ましくない動作(セキュリティ以外のバグ)を区別するのは、これらの領域の1つ以上の侵害があることです。

「最適化された」セキュリティを備えていない意図的な設計上の決定は、通常、脆弱性ではありません。セキュリティを向上させるための提案は、脆弱性と同じではありません。たとえば、問題箇所が脆弱性につながる可能性を低くしたり、その影響を軽減したりできるように、ソフトウェアを強化することは良いことです。それでも、ソフトウェアを強化する方法に関する提案自体は脆弱性レポートではありません。脆弱性は、何かが意図したとおりに動作しない状況を引き起こし、データ、システム、またはリソースへの意図しないアクセスやサービスの欠如を引き起こすことを指します。

評価	応答する内容
意図したとおりに動作する	これが意図された動作であることを報告者に伝えてください。この動作を改善できると思われる場合は、報告者は機能リクエストを提出することもできます。セキュリティイシューをクローズします。この評価で返答するときは、元のレポートが不明瞭で、VMTが元のレポートを意図せず誤解していた場合に備えて、なぜこの結論に至ったのかを説明する必要があります。
バグ	これは望ましくない動作ではあるがセキュリティ上の問題ではないことを報告者に伝え、これをバグとして再提出するよう依頼してください。セキュリティイシューをクローズします。
機能リクエスト	これが意図された動作であることを報告者に伝えてください。この動作を改善できると思われる場合は、報告者は機能リクエストを提出することもできます。セキュリティイシューをクローズします。
脆弱性	この望ましくない動作がセキュリティ上の問題を引き起こすことを確認したことを報告者に伝えてください。プロセスを続行します。

3 脆弱性報告者と公開禁止期間に付いて話し合う

通常、脆弱性報告者は受け入れることのできる公開禁止期間に付いて明記します。「公開禁止期間」とは、脆弱性報告が一般に公開されない期間であり、プロジェクトが自ら脆弱性に対応し、修正し、公開することを可能にする期間です。これは、プロジェクトが要求した公開禁止期間である場合もあれば、そうでない場合もあります。公開禁止期間に関する勧告や規範は、さまざまなグループの間で異なっています

- [distros mailing list](https://oss-security.openwall.org/wiki/mailing-lists/distros) 7日以下を推奨し、最大で14日です。
- [CERT/CC 報告から45日後に脆弱性を一般に公開します](https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy)、いくつかの例外を除いて利用可能な修正がない場合にも実施します。
- [The CERT® Guide to Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) (August 2017) では「ベンダーとコーディネーターに対し、24～48時間の通知は一般的ですが、最近の開示では45～90日が通常の期間のようです。」と示されています。
- [Googleのアプリケーション セキュリティ ポリシーは90日の期限を利用](https://www.google.com/about/appsecurity/)

90日は、様々なグループに標準で受け入れられる最長の公開禁止期間であることに注意してください。多くの標準の公開禁止期間は短くなっています。問題の複雑さ、問題が積極的に悪用されているかどうか、またはパッチの公開の問題に応じて、多少時間が前後する場合があります。脆弱性報告者がプロジェクトに十分な時間を与えていないと思われる場合、ここで、脆弱性報告者により長い公開禁止時間が必要な理由を主張すると良いでしょう。[協調的な脆弱性開示のためのCERT®ガイド](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf)は、提供者と報告者の両方が「ポリシーで宣言された開示までの期間を、厳密な期限とするのではなくむしろ双方の会話を開始する出発点として扱う」ことを推奨しています。

重要なのは、(可能であれば)すべての関係者が公開禁止期間に合意することです。また、脆弱性の報告者との継続的なコミュニケーションが不可欠です。ほとんどの脆弱性の報告者は、明確な対応が進んでいるという根拠、継続的なコミュニケーション、追加の時間に対する論理的な根拠があれば、好意的に期間の延長に合意してくれるでしょう。
公開禁止期間(別名「リスクの日数」)は、トレードオフを意味します。公開禁止中の日々に、攻撃者がその脆弱性を発見し、ソフトウェアのユーザーを攻撃する可能性があるためです。対照的に、ユーザーや一般の利用者は脆弱性の危険性を知らないままになります。しかし、一旦公開禁止期間が終了すれば、脆弱性を知らなかった攻撃者が、すぐに脆弱性を知り、それを悪用することができるようになります。脆弱性が発見されてから適切に修正されるまでの時間は、短ければ短いほどいいでしょう。過去の苦い経験から、多くのサプライヤーが、期限を設けずに危険な脆弱性にさらされたユーザーをただ放置していることが分かっています。そのため、期限を設けないということは、多くの脆弱性報告者対し、そのプロジェクトは、自身が提供するソフトウェアの安全性の確保に積極的に対立する立場を取ることを示してしまっています。

4 問題に対するパッチを作成する

報告者に問題を確認したことを伝え、パッチの開発を開始し、まだ取得していない場合は[CVE entry](https://cve.mitre.org/about/index.html)のリクエスト行ってください。また、報告者にパッチの開発プロセスに参加したいかどうかを尋ねてください。あなたは自身の開発ツールやテストツールを使い、パッチを作成し、リリースの準備を進めます(しかし、リリースは行ってはいけません)。
評価プロセスでは、影響を受けるバージョンを特定しておく必要があります。パッチを準備する際には、下位互換性とアップグレードの要件に注意してください(たとえば、v1.0.0は影響を受けますが、パッチには互換性がなく、パッチを適用するにはv1.7.0 以降にアップグレードする必要があります)。これらの詳細は、開示のお知らせで伝える必要があります。
パッチを作成するときは、ユーザーが更新するのが簡単であることが不可欠です(少なくともソフトウェアの最新リリースを使用しているユーザーにとって)。変更により、ユーザーが別のAPIを使用することや、絶対に避けられない場合を除き、ユーザー機能の削除は行ってはいけません。現実的に、ある変更は簡単なアップデートを含みます。脆弱性を完全に修正するためにそのような変更が絶対に必要な場合は、ユーザーへの影響を最小限に抑え、変更を適用せずに脆弱性を軽減する方法を探します(多くのユーザーはそのような変更をタイムリーにインストールできないため)。
パッチ適用の問題については、このガイドの [トラブルシューティング] (#troubleshooting-the-process) セクションを参照してください。

5 問題のCVEを取得する

**報告者にCVEエントリの作成に関与したいかどうか、およびエントリにクレジットされたいかどうかを尋ねます。** 表彰をすることは、報告者に感謝する多くの方法の1つです。脆弱性報告者がクレジットを望まない限り、脆弱性報告者へのクレジットを省略することは不適切です。

あなたの [特定したCNA]  (#establish-a-cna-contact) を通じて、CVE番号を予約し、説明を提出してください。CNAにパッチを作成中であることを伝え、該当する場合は公開前に非公開通知を行う。CNAがあなたのCVEエントリのリストアップを調整できるように、公開日について最新の情報を入手しておいてください。

6 公開日の決定

脆弱性のCVEを取得する利点は、ユーザーに脆弱性を通知し、修正されたことを確認するためのパスを提供することです。多くの組織はCVEを特に追跡しているため、あなたの脆弱性の発表を見ていなかったとしてもCVEレポートに気づくことができます。
また、[OSV スキーマ](https://ossf.github.io/osv-schema/) を使用して JSON エントリを作成し、HTTP経由でアクセス可能な場所に公開することをお勧めします。このスキーマを使用すると、マシンで読み取り可能なバージョン情報をエンコードできるため、ユーザーは自分がプロジェクトで利用するソフトウェアのバージョンに簡単に脆弱性が影響するか簡単に確認することができます。

7 # （該当する場合）公開禁止措置を受けているプロバイダーに通知する

    多くの国では、金曜日、土曜日、日曜日を休日としています。したがって、脆弱性が一般に知られていない場合（たとえば、悪用されていない場合）、月曜日、火曜日、または水曜日に公開する方がよいことがよくあります。さらに、広く認識されている休日に脆弱性修正をリリースすることは避けてください。これにより、就業中にユーザーは更新の時間を確保することができます。

8 （該当する場合）禁輸措置を受けているプロバイダーに通知する

公開禁止の通知は、公開予定日の1〜30営業日前に送信されます。この時間枠は、問題の重大度と悪用可能性、パッチの複雑さ、およびプロジェクトが使用されているプロバイダーの種類によって異なります(プロバイダーは5日で詳細を把握し、パッチを適用できるでしょうか? 10日必要でしょうか?)。また、祝日や重要なイベントも考慮してください。公開予定日に向けて調整や準備を行うプロバイダーの能力に影響を与える可能性があります(たとえば、小売業者がプロジェクトを頻繁に使用する場合、[米国のブラックフライデーのショッピングデー](<https://en.wikipedia.org/wiki/Black_Friday_(shopping)>))に対応できるという想定は持たないでください)。

通知には、CVE ID、問題の説明、報告者のクレジット(該当する場合)、影響を受けるバージョン、パッチの提供方法、および公開日を含める必要があります。ガイドの対応する[テンプレート](#communication テンプレート) の例を参照してください。

9 リリースおよび問題を一般公開する

一般に向けて公開した日に、開示のアナウンス([テンプレート](#communication-templates)参照)を公表してください。GitHubセキュリティ アドバイザリを使用している場合、プライベート セキュリティ アドバイザリを「公開」すると、「セキュリティ」タブに追加されます。GitHubセキュリティ アドバイザリを使用していない場合は、リリースノートまたはセキュリティ情報にお知らせを公開してください。修正された脆弱性の CVE ID がある場合は、このリリースで修正された脆弱性のCVE IDを含めます。

また、コミュニティの適切なメーリングリスト(つまり、セキュリティannounce@リストや、影響の大きい脆弱性の通知に適した一般的なメーリングリスト)にアナウンスを送信することをお勧めします。

10 速やかに開示する

攻撃者がこの脆弱性を悪用し始める前に、ユーザーが更新する時間をもう少し確保できることを期待して、この脆弱性がどのように悪用されるかについての詳細を一時的に差し控えることを選択できます。これは、攻撃者が脆弱性をどのように悪用できるかが明らかでない場合にのみ意味があり、ほとんどの場合、攻撃者はそれを明白に感じるでしょう。さらに、攻撃者は通常、ソフトウェアに加えられた変更を(ソースまたは実行可能ファイルの形式で)確認し、攻撃を簡単に判断できます。したがって、詳細な情報を差し控えることは、それがまったく役立つ少数のケースであっても、せいぜい数日間しか役に立ちません。

協調的脆弱性開示に対する一般的な課題のトラブルシューティング

場合によっては、協調的脆弱性開示プロセスがスムーズに進まないことがあります。このセクションでは、遭遇する可能性のあるいくつかの潜在的な課題に対するアドバイスを提供します。

これが実際にセキュリティ上の問題であるかどうかわからない

脆弱性レポートを受け取ったものの、それがセキュリティ上の問題であるかどうかがわからない場合は、VMT内のドメインの専門家に質問するか、脆弱性を報告した人に追加の質問を試みることができます。報告が短すぎる、または不明瞭な場合は、次のような質問をするとよいでしょう。

• 脆弱性はコードのどの行にありますか？
• この脆弱性は具体的にどのようにセキュリティ リスクを引き起こすのでしょうか？
• コードをそのままにしておくと、攻撃者は最終的に何をすることができるでしょうか？
• どうすれば問題を再現できるでしょうか？/簡単に見せていただける動作するPOCはありますか？
• 問題を解決するには何をしなければなりませんか？（注意：提供されたすべてのパッチのセキュリティを検証しなければいけません、それに提供元は関係ありません。偶発的に安全でないコミットや意図的に悪意のあるコミットを防ぐよう最善を尽くす必要があります。）

場合によっては、脆弱性研究者が喜んで追加の時間を投資して、問題をより深く理解できるように、また、問題を修正できるように支援してくれる場合があります。相手がそうした場合は、相手の時間を尊重し、協力的かつ率直な態度でアプローチし、協力して脆弱性を修復できるようにしてください。

報告者があまり応答を返さない

最初の報告の後、報告者はどの程度対応するかを選択します (これが、協調的脆弱性開示の「協調」の部分です)。再現できないレポートを受け取り、何度も報告者に連絡を試みた場合は、問題を再現できなかったこと、およびセキュリティ勧告を発行しないことを伝える丁寧な最終通知を送信してください。将来的に問題が再現できる場合は、イシューを再度発行いただけるよう案内します。

パッチ開発がうまくいかない

問題を完全に解決するパッチの開発にうまくいかない場合は、いくつかの選択肢があります。

• さらなる助けを求める。
  修正の開発がうまくいかない場合は、問題に取り組む人員を、VMTを超えて拡大しても問題ありません。影響のある箇所について特に詳しいプロジェクトのコントリビューターはいますか? このセキュリティ分野を専門とする人を知っていますか? (例: ネットワーキング セキュリティ、コンテナ セキュリティなど) VMTメンバーは会社に支援できるリソース (例: 脆弱性対応チーム) を持っていますか?

• 部分的にパッチを適用する（悪用の連鎖を断ち切る）。
  より多くの支援を得ている場合、公開禁止期間が間もなく終了する場合、完全な修正がまだない場合は、公開時期までに悪用の連鎖を断ち切るパッチがある方が、パッチがないよりも望ましいです。これは、情報開示後に完全な修正への取り組みを中止するという意味ではなく、現在持ちうる解決策をリリースするという意味です。この文脈において、「悪用の連鎖を断ち切る」とは、悪用をより困難にする部分的な修正を作成することを意味します。このオプションでは、このパッチでは問題が完全に解決されないことを伝え、文書化する必要があります。ユーザーは、パッチ適用後であっても、自分の攻撃に対する脆弱の程度を理解する必要があります。包括的な修正を行った場合は、ユーザーに最新情報を案内するために、過去のお知らせに更新を忘れずに追加してください。(たとえば、包括的な修正のリリース ノートには、「$CVEIDに対処するさらなるセキュリティの改善」と記載できます。)

• パッチを適用せずに情報を開示し、その詳細を十分に文書化する。
  問題が解決できない場合、ユーザーは知らないよりも知っていた方が良いです。「隠蔽によるセキュリティ」は、脆弱性管理における弱い防御策です。既存の脆弱性は悪意のある者によって発見され、悪用される可能性があります。一般的な環境での関連する回避策も含めて、問題を十分に文書化し、公の場で引き続き取り組んでください。

誰かが当社と協力せずに脆弱性を公表した

研究論文、メディア記事、セキュリティカンファレンスのプレゼンテーション、またはソーシャルメディアのいずれで発見されたとしても、あなたが事前に認識していなかったプロジェクトの脆弱性を誰かが公に公開した場合、最善の策は、それを通常のプロジェクトノイシューとして扱うことです(結局のところ、すでに公開されています)。ただし、特に問題が公開された場合や重大な問題の場合は、高い優先度を割り当ててユーザーとコミュニケーションをとってください。問題を認識していること、問題がどのように処理されているか、更新情報をどこで確認する必要があるかを伝えてください。この種の問題に公的に対処すると、他の人がこの情報を見つけてVMTに連絡する必要がなくなるため、コミュニケーションの負担のかなりの部分が軽減されます。

脆弱性は実際に活発に悪用されていると考えられます

オープンソース ソフトウェアは強力であり、OSSプロジェクトの緩和策が実施されていないセキュリティ上の欠陥は、世界中の人々や組織に対して実際に影響を与える可能性があります。オープン ソース(およびクローズド ソースにおいても!)プロジェクトのセキュリティの脆弱性が悪用されると、下流の依存関係者やソフトウェアの直接的および間接的なユーザーが侵害される可能性があります。これらのいわゆる「サプライチェーン」攻撃の例は、近年主要なメディアで詳しく文書化されています。

コードの脆弱性が脅威アクターによって積極的に悪用されていると信じる理由がある場合は、ユーザーに迅速に通知し、セキュリティ リスクを修正するパッチを発行することが重要です。私たちは、この課題に直面している OSS プロジェクトの管理者向けに追加のリソースを追加して、このガイドの将来のバージョンを更新することを目指しています。

謝辞

Google Open Source Programs Office and Google security teams、OpenStack Vulnerability Management Process、Project Zero’s disclosure process、Kubernetes security and disclosure processなど、このガイドの活動に貢献した広範なセキュリティおよびオープンソース コミュニティに感謝します。

翻訳協力：松本央