address some review comments

Author: mchammer01

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

@@ -10,14 +10,15 @@ versions:
 
 {% 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.
+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](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html#commercial-and-open-source-software)" on the OWASP Cheat Sheet Series website.
 
 #### Best practices for security researchers
 
-Security researchers should report vulnerabilities privately to maintainers. It's not acceptable to:
-- Disclose the vulnerability publicly
-- Not contact the maintainer 
-- Disclose the vulnerability before a fixed version of the code is available
+Security researchers should try to report vulnerabilities privately to maintainers. When possible, please avoid:
+- Disclosing the vulnerability publicly
+- Bypassing the maintainer 
+- 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 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.
 
@@ -26,19 +27,20 @@ It's acceptable for security researchers to disclose a vulnerability publicly af
 Maintainers should disclose vulnerabilities in a timely manner. If there is a security vulnerability in your repository, you should:
 - Treat the vulnerability as a security issue rather than a simple bug
 - Plan to disclose the vulnerability responsibly
+- Give credit where credit is due
 - Aim to publish a fix as soon as you can
 
-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.
+Publishing the details of a security vulnerability doesn't make maintainers look bad. Security vulnerabilities are present everywhere in software 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 %}
 
-The process for reporting and disclosing vulnerabilities in {% data variables.product.prodname_dotcom_the_website %} is as follows:
+The process for reporting and disclosing vulnerabilities for projects on {% 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. If there isn't a security policy for the repository, you may try to privately contact the maintainer based on information available in the _security.md_ file.
 
 {% 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)" on the npm Docs website.
+**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.
 
 {% endnote %}
 

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

@@ -1 +1 @@
-Vulnerability disclosure is an area where collaboration between security researchers and project maintainers 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 a maintainer know privately about a security vulnerability, the maintainer develops a fix, validates it, and notifies the repository users. 
+Vulnerability disclosure is an area where collaboration between security researchers and project maintainers is very important, from the moment a potentially harmful security vulnerability is found, right until a vulnerability is disclosed to the world, ideally with a patch available. Typically, when someone lets a maintainer know privately about a security vulnerability, the maintainer develops a fix, validates it, and notifies the users of a project or a package.