Apply suggestions from code review

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Stan Ulbrych <stan@python.org>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Emma Smith <emma@emmatyping.dev>

Author: 5 people

security-and-threat-model/index.rst

@@ -2,31 +2,30 @@
 Security and threat model
 =========================
 
-The majority of Python Security Response Team
-members are volunteers and therefore you must respect this volunteered time
+The majority of Python Security Response Team (PSRT)
+members are volunteers. Therefore, you must respect this volunteered time
 by following this security policy. Repeated failure to
 respect the security policy will result in future reports
-being rejected, regardless of technical merit.
+being rejected or being banned from the `python` GitHub organization, regardless of technical merit.
 
 What types of bugs are vulnerabilities?
 ---------------------------------------
 
 Not all bugs are vulnerabilities. To avoid causing
 duplicate work for PSRT members all potential reports
-must be evaluated against the relevant threat model(s)
+must be evaluated against the relevant threat models
 prior to being submitted to the PSRT.
 
 Vulnerabilities must be exploitable from code, configurations,
 pre-conditions, and deployments that might feasibly exist in
-the real-world. For example, a vulnerability only affecting code
-that does not make sense to write in a production program
+the real world. For example, a vulnerability only affecting code
+that does not make sense in a production program
 will not be accepted as a vulnerability.
 
 Documented functionality will not be considered a vulnerability.
-For example, ``pickle``, ``marshal``, ``shelve``, ``eval``, and ``exec``
-are documented to execute arbitrary Python code that is supplied as data.
-The ``ctypes`` module is documented to enable modifying arbitrary locations
-in memory.
+For example, :mod:`pickle`, :mod:`marshal``, :mod:`shelve``, :mod:`eval``,
+and :mod:`exec` are documented to execute arbitrary Python code that is supplied
+as data. The :mod:`ctypes` module is documented to enable modifying arbitrary locations in memory.
 
 Vulnerabilities must not depend on malicious control of:
 
@@ -47,12 +46,12 @@ for the attacker, rather than a "lateral" change in posture.
 This is to avoid handling performance improvements as security vulnerabilities.
 
 Vulnerabilities in dependencies of Python (such as zlib, Tcl/Tk, or OpenSSL)
-are not vulnerabilities in Python unless Python's usage of the dependency
-interferes with secure usage of the dependency.
+are not vulnerabilities in Python unless Python's use of the dependency
+interferes with secure use of the dependency.
 For example, Python is not vulnerable because it bundles a vulnerable
 version of zlib, users are expected to upgrade their own dependencies.
 
-The complete threat model for Python and standard library modules,
+The complete threat model for Python and standard library modules
 is available in the Threat Model section of the Python Developer Guide.
 
 What versions of Python are accepting reports?
@@ -67,11 +66,11 @@ non-stable versions, then the issue should be handled as a public bug issue.
 
 Sometimes features may be marked as
 "experimental" in Python, even in a stable Python version.
-These features are not eligible for security vulnerabilities,
-instead open a public GitHub issue.
+These features are not eligible for security vulnerabilities.
+Instead open a public GitHub issue.
 
-If a vulnerability is platform-dependent, check if the platform is a
-`supported platform per PEP 11 <https://peps.python.org/pep-0011/>`__.
+If a vulnerability is platform-dependent, check if the platform is
+`supported per :pep:`11`.
 Vulnerabilities that exclusively affect unsupported platforms
 may not be accepted.
 
@@ -96,7 +95,7 @@ be formatted correctly:
   whether a valid bug report is a vulnerability or not.
 * Do not include severity or CVSS information in your initial report,
   this information will be determined by the PSRT.
-* Optionally, include a minimal patch with the mitigation for the report.
+* Ideally, include a minimal patch with the mitigation for the report.
 * If the vulnerability only affects certain Python versions, optionally
   include the versions of Python that are affected.
 * Reports that do not contain a potential security vulnerability (such as spam
@@ -107,12 +106,12 @@ How to submit a vulnerability report?
 -------------------------------------
 
 Submit all potential security vulnerability reports for CPython
-to `GitHub Security Advisories <GHSA>`__
+to GitHub Security Advisories
 by `opening a new ticket <GHSA>`__.
 Do not open a public GitHub issue to report a security vulnerability.
-For all other projects (pip, python.org, tools, etc) or if you're
+For all other projects (such as pip, python.org and tools) or if you're
 not sure where to send your report, send an email to
-`security at python dot org <mailto:security@python.org>`__.
+`security@python.org <mailto:security@python.org>`__.
 
 Here's what to expect for how a vulnerability report will be handled:
 
@@ -148,6 +147,6 @@ The Python and pip projects are scoped under the
 vulnerability reports to the PSRT to receive
 a CVE ID for Python or pip. To reach the PSF
 CNA contact directly, send an email to
-`cna at python dot org <mailto:cna@python.org>`__.
+`cna@python.org <mailto:cna@python.org>`__.
 
 .. _CNA: https://www.python.org/cve-numbering-authority/