About disclosing vulnerabilities in the industry
脆弱性の開示は、セキュリティの研究者などの脆弱性の報告者とプロジェクトのメンテナとの間の協力が非常に重要な分野です。 潜在的に有害なセキュリティの脆弱性が見つかったときから、脆弱性が世界に向けて公開され、理想的にはパッチが利用可能になるまで、どちらも協力しあって作業しなければなりません。 通常は、誰かがメンテナに対してセキュリティの脆弱性について個人的に知らせると、メンテナはパッチを開発し、検証し、プロジェクトあるいはパッケージのユーザに通知します。
The initial report of a vulnerability is made privately, and the full details are only published once the maintainer has acknowledged the issue, and ideally made remediations or a patch available, sometimes with a delay to allow more time for the patches to be installed. For more information, see the OWASP Cheat Sheet Series about vulnerability disclosure on the OWASP Cheat Sheet Series website.
Best practices for vulnerability reporters
It's good practice to report vulnerabilities privately to maintainers. When possible, as a vulnerability reporter, we recommend you avoid:
- Disclosing the vulnerability publicly without giving maintainers a chance to remediate.
- Bypassing the maintainers.
- Disclosing the vulnerability before a fixed version of the code is available.
- Expecting to be compensated for reporting an issue, where no public bounty program exists.
It's acceptable for vulnerability reporters to disclose a vulnerability publicly after a period of time, if they have tried to contact the maintainers and not received a response, or contacted them and been asked to wait too long to disclose it.
We recommend vulnerability reporters clearly state the terms of their disclosure policy as part of their reporting process. Even if the vulnerability reporter does not adhere to a strict policy, it's a good idea to set clear expectations for maintainers in terms of timelines on intended vulnerability disclosures. For an example of disclosure policy, see the Security Lab's disclosure policy on the GitHub Security Lab website.
Best practices for maintainers
As a maintainer, it's good practice to clearly indicate how and where you want to receive reports for vulnerabilities. If this information is not clearly available, vulnerability reporters don't know how to contact you, and may resort to extracting developer email addresses from git commit histories to try to find an appropriate security contact. This can lead to friction, lost reports, or the publication of unresolved reports.
Maintainers should disclose vulnerabilities in a timely manner. If there is a security vulnerability in your repository, we recommend you:
- Treat the vulnerability as a security issue rather than a simple bug, both in your response and your disclosure. For example, you'll need to explicitly mention that the issue is a security vulnerability in the release notes.
- Acknowledge receipt of the vulnerability report as quickly as possible, even if no immediate resources are available for investigation. This sends the message that you are quick to respond and act, and it sets a positive tone for the rest of the interaction between you and the vulnerability reporter.
- Involve the vulnerability reporter when you verify the impact and veracity of the report. It's likely the vulnerability reporter has already spent time considering the vulnerability in a variety of scenarios, some of which you may have not considered yourself.
- Remediate the issue in a way that you see fit, taking any concerns and advice provided by the vulnerability reporter into careful consideration. Often the vulnerability reporter will have knowledge of certain corner cases and remediation bypasses that are easy to miss without a security research background.
- Always acknowledge the vulnerability reporter when you credit the discovery.
- Aim to publish a fix as soon as you can.
- Ensure that you make the wider ecosystem aware of the issue and its remediation when you disclose the vulnerability. It is not uncommon to see cases where a recognized security issue is fixed in the current development branch of a project, but the commit or subsequent release is not explicitly marked as a security fix or release. This can cause problems with downstream consumers.
Publishing the details of a security vulnerability doesn't make maintainers look bad. Security vulnerabilities are present everywhere in software, and users will trust maintainers who have a clear and established process for disclosing security vulnerabilities in their code.
About reporting and disclosing vulnerabilities in projects on GitHub
There are two processes available on GitHub:
- The standard process: Vulnerability reporters get in touch with the repository maintainers, using contact information located in the security policy for the repository. The repository maintainers then create a draft repository advisory if required.
- Private vulnerability reporting: Vulnerability reporters disclose vulnerability details directly and privately to the repository maintainers by proposing a draft repository advisory and providing details of their findings.
Standard process
The process for reporting and disclosing vulnerabilities for projects on GitHub is as follows:
If you are a vulnerability reporter (for example, a security researcher) who would like report a vulnerability, first check if there is a security policy for the related repository. For more information, see リポジトリへのセキュリティ ポリシーの追加. If there is one, follow it to understand the process before contacting the security team for that repository.
If there isn't a security policy in place, the most efficient way to establish a private means of communication with maintainers is to create an issue asking for a preferred security contact. It's worth noting that the issue will be immediately publicly visible, so it should not include any information about the bug. Once communication is established, you can suggest the maintainers define a security policy for future use.
メモ
For npm only - If we receive a report of malware in an npm package, we try to contact you privately. If you don't address the issue in a timely manner, we will disclose it. For more information, see Reporting malware in an npm package on the npm Docs website.
If you've found a security vulnerability in GitHub, please report the vulnerability through our coordinated disclosure process. For more information, see the GitHub Security Bug Bounty website.
If you are a maintainer, you can take ownership of the process at the very beginning of the pipeline by setting up a security policy for your repository, or otherwise making security reporting instructions clearly available, for example in your project’s README file. For information about adding a security policy, see リポジトリへのセキュリティ ポリシーの追加. If there is no security policy, it's likely that a vulnerability reporter will try to email you or otherwise privately contact you. Alternatively, someone may open a (public) issue with details of a security issue.
As a maintainer, to disclose a vulnerability in your code, you first create a draft security advisory in the package's repository in GitHub. リポジトリ セキュリティ アドバイザリを使用すると、パブリック リポジトリのメンテナーは、プロジェクト内のセキュリティの脆弱性について非公開で話し合い、修正することができます。 共同で修正を行った後、リポジトリ保守担当者はセキュリティ アドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに開示することができます。 セキュリティ アドバイザリを公開することにより、リポジトリ保守担当者は、コミュニティがいっそう簡単にパッケージの依存関係を更新したり、セキュリティの脆弱性の影響を調べたりできるようにします。 For more information, see Repository security advisories.
To get started, see リポジトリ セキュリティ アドバイザリの作成.
Private vulnerability reporting
パブリック リポジトリの所有者と管理者は、リポジトリでプライベート脆弱性レポートを有効にすることができます。 「リポジトリのプライベート脆弱性レポートの構成」を参照してください。
Private vulnerability reporting provides a secure, structured way for security researchers to privately disclose security risks to repository maintainers directly within GitHub. When a vulnerability is reported, repository maintainers are immediately notified, allowing them to review and respond without the risk of premature public disclosure.
Without clear guidance on how to contact maintainers, security researchers may feel forced to disclose vulnerabilities publicly, such as by posting on social media, opening public issues, or contacting maintainers through informal channels, which can expose users to unnecessary risk.
For security researchers, the benefits of using private vulnerability reporting are:
- A clear, structured way to contact maintainers
- A smoother process for disclosing and discussing vulnerability details
- The ability to discuss vulnerability details privately with the repository maintainer
- Reduced risk of vulnerability details being in the public eye before a fix is available
For maintainers, the benefits of using private vulnerability reporting are:
- レポートが解決されたのと同じプラットフォームでレポートを受信する
- 保守担当者に代わってアドバイザリ レポートを作成または開始するセキュリティ研究者
- 修正プログラムが利用可能になる前に、脆弱性が目に見えなくなるリスクが軽減されました
- 脆弱性の詳細についてセキュリティ研究者と非公開で話し合い、パッチで共同作業する機会
また、セキュリティ リサーチャーは、REST API を使って、セキュリティの脆弱性を非公開で報告できます。 「リポジトリ セキュリティ アドバイザリ用の REST API エンドポイント」を参照してください。
メモ
If the repository containing the vulnerability doesn't have private vulnerability reporting enabled, both security researchers and repository maintainers need to follow the instructions described in the Standard process section above.
Next steps
If you are a security researcher, see セキュリティの脆弱性を非公開で報告する to learn how to privately report a vulnerability to a repository maintainer.
If you are a repository maintainer, see リポジトリのプライベート脆弱性レポートの構成 to enable private vulnerability reporting for your repository, or カスタム セキュリティ構成を作成する to manage it across your organization.