tidy up

content/github/managing-security-vulnerabilities/about-disclosing-vulnerabilities.md

@@ -8,7 +8,7 @@ versions:
 
 ### About disclosing vulnerabilities in the industry
 
-When someone lets an organization maintainer know privately about a vulnerability, the maintainer typically develops a fix, validates it, and notifies the repository users. 
+{% data reusables.security-advisory.disclosing-vulnerabilities %}
 
 The initial report of a vulnerability is made privately, and the full details are only published once a patch has been made 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](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html#commercial-and-open-source-software)" on the OWASP Cheat Sheet Series website.
 
@@ -19,7 +19,7 @@ Security researchers should report vulnerabilities privately to maintainers. It'
 - Not contact the maintainer 
 - Disclose the vulnerability before the code has been patched
 
-It's seen as fine for security researchers 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.
+It's fine for security researchers 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.
 
 #### Best practices for maintainers
 
@@ -28,11 +28,11 @@ Maintainers should disclose vulnerabilities in a timely manner, if a security vu
 - Not identify the vulnerability as a security issue 
 - Wait an unacceptably long time to create a fix
 
-Publishing the details of a security vulnerability doesn't make maintainers look bad. Security vulnerabilities are present everywhere in sofware nowadays, and users will be grateful if maintainers have a clear and established process for disclosing security vulnerabilities in their code.
+Publishing the details of a security vulnerability doesn't make maintainers look bad. Security vulnerabilities are present everywhere in sofware nowadays, 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 {% data variables.product.prodname_dotcom %}
 
-Here at {% data variables.product.company_short %}, the process for reporting and disclosing vulnerabilities is as follows:
+The process for reporting and disclosing vulnerabilities in {% data variables.product.prodname_dotcom_the_website %} is as follows:
 
  If you are 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 "[About security policies](/github/managing-security-vulnerabilities/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. 
 
@@ -40,13 +40,11 @@ Here at {% data variables.product.company_short %}, the process for reporting an
  
 {% note %}
 
-**Note**: _For npm only_ - If you report a vulnerability to npm, 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)" in the npm Docs website.
+**Note**: _For npm only_ - If you report a vulnerability to npm, 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.
 
 {% endnote %}
 
- As a maintainer, to disclose a vulnerability that exists in your repository (for example if someone got in touch and reported a vulnerability to you), you first create a draft security advisory in your package's repository in {% data variables.product.prodname_dotcom %}. 
- 
- {% data reusables.security-advisory.security-advisory-overview %} For more information, see "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)."
+ As a maintainer, to disclose a vulnerability that exists in your repository (for example if someone got in touch and reported a vulnerability to you), you first create a draft security advisory in your package's repository in {% data variables.product.prodname_dotcom %}. {% data reusables.security-advisory.security-advisory-overview %} For more information, see "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)."
 
 
  To get started, see "[Creating a security advisory](/github/managing-security-vulnerabilities/creating-a-security-advisory)."

content/github/managing-security-vulnerabilities/about-github-security-advisories.md

@@ -14,6 +14,8 @@ versions:
 
 ### About {% data variables.product.prodname_security_advisories %}
 
+{% data reusables.security-advisory.disclosing-vulnerabilities %} For more information, see "[About disclosing vulnerabilities](/github/managing-security-vulnerabilities/about-disclosing-vulnerabilities)."
+
 {% data reusables.security-advisory.security-advisory-overview %}
 
 With {% data variables.product.prodname_security_advisories %}, you can:

data/reusables/security-advisory/disclosing-vulnerabilities.md

@@ -0,0 +1 @@
+Vulnerability disclosure is an area where collaboration between security researchers and organizations is very important, from the moment a potentially harmful security vulnerability is found, right until a patch is available, and the vulnerability is disclosed to the world. Typically, when someone lets an organization maintainer know privately about a security vulnerability, the maintainer develops a fix, validates it, and notifies the repository users.