パブリック リポジトリに対する管理者権限を持つユーザーであれば誰でも、セキュリティ アドバイザリを作成できます。
パブリック リポジトリに対する管理者権限を持つユーザーは、そのリポジトリ内のすべてのセキュリティ アドバイザリに対する管理者権限も持ちます。 セキュリティアドバイザリに対する管理者権限を持っている人は、コラボレータを追加でき、コラボレータはセキュリティアドバイザリに対する書き込み権限を持ちます。
Note
セキュリティ研究者の場合は、保守担当者に直接連絡して、自分が管理していないリポジトリで自分に代わってセキュリティ アドバイザリを作成または CVE を発行するように依頼する必要があります。 しかし、リポジトリに対してプライベート脆弱性レポートが有効になっている場合は、脆弱性を自分で_個人的に_報告できます。 詳しくは、「セキュリティの脆弱性を非公開で報告する」を参照してください。
リポジトリ セキュリティ アドバイザリについて
脆弱性の開示は、セキュリティの研究者などの脆弱性の報告者とプロジェクトのメンテナとの間の協力が非常に重要な分野です。 潜在的に有害なセキュリティの脆弱性が見つかったときから、脆弱性が世界に向けて公開され、理想的にはパッチが利用可能になるまで、どちらも協力しあって作業しなければなりません。 通常は、誰かがメンテナに対してセキュリティの脆弱性について個人的に知らせると、メンテナはパッチを開発し、検証し、プロジェクトあるいはパッケージのユーザに通知します。詳しくは、「セキュリティ脆弱性の調整された開示について」をご覧ください。
リポジトリ セキュリティ アドバイザリを使用すると、パブリック リポジトリのメンテナーは、プロジェクト内のセキュリティの脆弱性について非公開で話し合い、修正することができます。 共同で修正を行った後、リポジトリ保守担当者はセキュリティ アドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに開示することができます。 セキュリティ アドバイザリを公開することにより、リポジトリ保守担当者は、コミュニティがいっそう簡単にパッケージの依存関係を更新したり、セキュリティの脆弱性の影響を調べたりできるようにします。
リポジトリ セキュリティ アドバイザリを使うと、次のことができます。
- セキュリティアドバイザリのドラフトを作成し、そのドラフトを用いて、プロジェクトに対する脆弱性の影響について非公開で議論します。 詳しくは、「リポジトリ セキュリティ アドバイザリの作成」をご覧ください。
- 一時的なプライベートフォークで、脆弱性を修正するため非公式でコラボレートします。
- パッチがリリースされたら、脆弱性のコミュニティに警告するため、セキュリティアドバイザリを公開してください。 詳しくは、「リポジトリ セキュリティ アドバイザリの公開」をご覧ください。
リポジトリ セキュリティ アドバイザリを使い、すでに別の場所で公開したセキュリティ脆弱性の詳細をコピーして新しいセキュリティアドバイザリに貼り付けることにより、その詳細を再度公開できます。
REST API を使って、リポジトリ セキュリティ アドバイザリを作成、一覧表示、更新することもできます。 詳しくは、「リポジトリ セキュリティ アドバイザリ用の REST API エンドポイント」をご覧ください。
セキュリティアドバイザリに貢献した個人にクレジットを付与することができます。 詳しくは、「リポジトリ セキュリティ アドバイザリの編集」をご覧ください。
セキュリティポリシーを作成して、プロジェクト中のセキュリティ脆弱性を報告するための指示を出すことができます。 詳しくは、「リポジトリへのセキュリティ ポリシーの追加」を参照してください。
セキュリティアドバイザリをリポジトリ中で作成した場合、そのセキュリティアドバイザリはリポジトリに残ります。 依存関係グラフによってサポートされる任意のエコシステムのセキュリティ アドバイザリを、github.com/advisories の GitHub Advisory Database に公開しています。 GitHub Advisory Database に公開されているアドバイザリに、だれでも変更を送信することができます。 詳しくは、「GitHub Advisory Database でのセキュリティ アドバイザリの編集」をご覧ください。
特にnpmに対するものであるセキュリティアドバイザリについては、npmセキュリティアドバイザリにも公開します。 詳細については、npmjs.com/advisories を確認してください。
GitHub Security Lab に参加して、セキュリティ関連のトピックを見たり、セキュリティのツールやプロジェクトに貢献したりすることもできます。
CVE 識別番号
GitHub Security Advisories は、共通脆弱性識別子(CVE) リストに基づいています。 GitHub上のセキュリティアドバイザリフォームは、CVEの記述フォーマットにマッチする標準化されたフォームです。
GitHub は CVE Numbering Authority (CNA) であり、CVE 識別番号を割り当てる権限があります。 詳しくは、CVE の Web サイトで、CVE の概要に関するページと「CVE の番号付け機関」をご覧ください。
GitHub でパブリックリポジトリのセキュリティアドバイザリを作成する場合、セキュリティの脆弱性に対する既存の CVE 識別番号を提供するオプションがあります。 プロジェクト中のセキュリティ脆弱性に対する CVE 識別番号が必要であり、まだ持っていない場合は、GitHub に CVE 識別番号を要求できます。 GitHubは通常、リクエストを72時間以内にレビューします。 CVE識別番号をリクエストしても、セキュリティアドバイザリはパブリックにはなりません。 セキュリティ アドバイザリが CVE の対象である場合、GitHub によってそのアドバイザリ用に CVE 識別番号が予約されます。 ユーザーがセキュリティ アドバイザリを公開した後、GitHub は CVE の詳細を公開します。 セキュリティ アドバイザリに対する管理者アクセス許可を持っているすべてのユーザーは、CVE 識別番号を要求できます。
使いたい CVE がすでにある場合は (たとえば、GitHub 以外の CVE Numbering Authority (CNA) を使う場合)、その CVE をセキュリティ アドバイザリ フォームに追加します。 これはたとえば、公開時に送信することを計画している他の通信先と、アドバイザリが一貫しているようにしたい場合に生じるかもしれません。 CVE が別の CNA によってカバーされている場合、GitHub ではプロジェクトにそれを割り当てることはできません。
セキュリティアドバイザリを公開し、GitHub が CVE 識別番号を脆弱性に割り当てたら、GitHub は CVE を MITER データベースに公開します。 詳しくは、「リポジトリ セキュリティ アドバイザリの公開」をご覧ください。
公開されたセキュリティアドバイザリの Dependabot alerts
GitHubは、公開されたそれぞれのセキュリティアドバイザリをレビューし、GitHub Advisory Databaseに追加し、そのセキュリティアドバイザリを使って影響されるリポジトリにDependabot alertsを送信することがあります。 セキュリティアドバイザリがフォークから生ずる場合、ユニークな名前の下でパブリックなパッケージレジストリに公開されたパッケージをフォークが所有しているときにのみアラートが送信されます。 このプロセスには最大で72時間がかかり、GitHubがさらなる情報を求めてあなたに連絡することがあります。
Dependabot alerts の詳細については、「Dependabot アラートについて」と「Dependabot のセキュリティ アップデート」を参照してください。 GitHub Advisory Database の詳細については、「GitHub Advisory Database でのセキュリティ アドバイザリの参照」を参照してください。