[EDI] Configuring private vulnerability reporting for an organization (#59798)

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Author: sophietheking

content/code-security/concepts/vulnerability-reporting-and-management/about-coordinated-disclosure-of-security-vulnerabilities.md

@@ -7,6 +7,9 @@ redirect_from:
   - /code-security/security-advisories/repository-security-advisories/about-coordinated-disclosure-of-security-vulnerabilities
   - /code-security/security-advisories/guidance-on-reporting-and-writing/about-coordinated-disclosure-of-security-vulnerabilities
   - /code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/about-coordinated-disclosure-of-security-vulnerabilities
+  - /code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-private-vulnerability-reporting-for-an-organization
+  - /code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-an-organization
+  - /code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-an-organization
 versions:
   fpt: '*'
   ghec: '*'
@@ -33,13 +36,14 @@ It's good practice to report vulnerabilities privately to maintainers. When poss
 
 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](https://securitylab.github.com/advisories#policy) on the GitHub Security Lab website.
+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](https://securitylab.github.com/advisories#policy) on the {% data variables.product.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.
@@ -50,16 +54,16 @@ Maintainers should disclose vulnerabilities in a timely manner. If there is a se
 
 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 {% data variables.product.prodname_dotcom %}
+## About reporting and disclosing vulnerabilities in projects on {% data variables.product.github %}
 
-There are two processes available on {% data variables.product.prodname_dotcom %}:
+There are two processes available on {% data variables.product.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 {% data variables.product.prodname_dotcom %} is as follows:
+The process for reporting and disclosing vulnerabilities for projects on {% data variables.product.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 [AUTOTITLE](/code-security/getting-started/adding-a-security-policy-to-your-repository#about-security-policies). If there is one, follow it to understand the process before contacting the security team for that repository.
 
@@ -68,11 +72,11 @@ The process for reporting and disclosing vulnerabilities for projects on {% data
 > [!NOTE]
 > _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](https://docs.npmjs.com/reporting-malware-in-an-npm-package) on the npm Docs website.
 
- If you've found a security vulnerability in {% data variables.product.prodname_dotcom %}, please report the vulnerability through our coordinated disclosure process. For more information, see the [{% data variables.product.prodname_dotcom %} Security Bug Bounty](https://bounty.github.com/) website.
+ If you've found a security vulnerability in {% data variables.product.github %}, please report the vulnerability through our coordinated disclosure process. For more information, see the [{% data variables.product.github %} Security Bug Bounty](https://bounty.github.com/) 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 [AUTOTITLE](/code-security/getting-started/adding-a-security-policy-to-your-repository#about-security-policies). 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 {% data variables.product.prodname_dotcom %}. {% data reusables.security-advisory.security-advisory-overview %} For more information, see [AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories).
+ As a maintainer, to disclose a vulnerability in your code, you first create a draft security advisory in the package's repository in {% data variables.product.github %}. {% data reusables.security-advisory.security-advisory-overview %} For more information, see [AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories).
 
  To get started, see [AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory).
 
@@ -82,7 +86,7 @@ The process for reporting and disclosing vulnerabilities for projects on {% data
 
 Private vulnerability reporting provides a secure, structured way for security researchers to privately disclose security risks to repository maintainers directly within {% data variables.product.prodname_dotcom %}. 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. Private vulnerability reporting helps avoid these situations by offering a dedicated, private reporting workflow.
+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:
 
@@ -95,7 +99,13 @@ For maintainers, the benefits of using private vulnerability reporting are:
 
 {% data reusables.security-advisory.private-vulnerability-reporting-benefits %}
 
-For more information for security researchers and repository maintainers, see [AUTOTITLE](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) and [AUTOTITLE](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/managing-privately-reported-security-vulnerabilities), respectively.
+{% data reusables.security-advisory.private-vulnerability-api %}
 
 > [!NOTE]
 > 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](#standard-process) section above.
+
+## Next steps
+
+If you are a security researcher, see [AUTOTITLE](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) to learn how to privately report a vulnerability to a repository maintainer.
+
+If you are a repository maintainer, see [AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository) to enable private vulnerability reporting for your repository, or [AUTOTITLE](/code-security/securing-your-organization/enabling-security-features-in-your-organization/creating-a-custom-security-configuration) to manage it across your organization.

content/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-private-vulnerability-reporting-for-an-organization.md

@@ -15,5 +15,4 @@ children:
   - /configuring-default-setup-for-code-scanning-at-scale
   - /configuring-advanced-setup-for-code-scanning-with-codeql-at-scale
   - /enforcing-dependency-review-across-an-organization
-  - /configuring-private-vulnerability-reporting-for-an-organization
 ---

content/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/index.md

@@ -20,8 +20,6 @@ security_advisories:
       /code-security/how-tos/report-and-fix-vulnerabilities/fix-reported-vulnerabilities/managing-privately-reported-security-vulnerabilities
     - >-
       /code-security/how-tos/report-and-fix-vulnerabilities/configure-vulnerability-reporting/configuring-private-vulnerability-reporting-for-a-repository
-    - >-
-      /code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-private-vulnerability-reporting-for-an-organization
     - >-
       /code-security/how-tos/report-and-fix-vulnerabilities/fix-reported-vulnerabilities/creating-a-repository-security-advisory
     - >-

data/learning-tracks/code-security.yml

@@ -1 +1 @@
-Security researchers can also use the REST API to privately report security vulnerabilities. For more information, see [Privately report a security vulnerability](/rest/security-advisories/repository-advisories#privately-report-a-security-vulnerability).
+Security researchers can also use the REST API to privately report security vulnerabilities. See [AUTOTITLE](/rest/security-advisories/repository-advisories#privately-report-a-security-vulnerability).

data/reusables/security-advisory/private-vulnerability-api.md

@@ -1 +1 @@
-Owners and administrators of public repositories can enable private vulnerability reporting on their repositories. For more information, see [AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository).
+Owners and administrators of public repositories can enable private vulnerability reporting on their repositories. See [AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository).

data/reusables/security-advisory/private-vulnerability-reporting-enable.md

@@ -1,3 +1,3 @@
-When private vulnerability reporting is enabled for a repository, security researchers will see a new button in the **Advisories** page of the repository. The security researcher can click this button to privately report a security vulnerability to the repository maintainer.
+When private vulnerability reporting is enabled, security researchers see a **Report a vulnerability** button on the repository’s "Advisories" page, which allows them to submit a private report.
 
 ![Screenshot showing the "Report a vulnerability" button for a repository where private vulnerability reporting has been enabled.](/assets/images/help/security/report-a-vulnerability-button.png)