From ee802b261353a20eb37d21511fb4089b80e7ca7e Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Mon, 18 May 2026 18:29:31 -0700 Subject: [PATCH 1/4] Initial draft of Python 'Security Policy' --- security/index.rst | 1 + security/policy.rst | 154 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 155 insertions(+) create mode 100644 security/policy.rst diff --git a/security/index.rst b/security/index.rst index cbc1eb4e4..dd084b9eb 100644 --- a/security/index.rst +++ b/security/index.rst @@ -7,5 +7,6 @@ Security .. toctree:: :maxdepth: 5 + policy psrt sbom diff --git a/security/policy.rst b/security/policy.rst new file mode 100644 index 000000000..e96d6efa2 --- /dev/null +++ b/security/policy.rst @@ -0,0 +1,154 @@ +=============== +Security Policy +=============== + +The majority of Python Security Response Team +members are volunteers and 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. + +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) +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 +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. + +Vulnerabilities must not depend on malicious control of: + +* what Python code is executed by the interpreter +* locations where code is loaded prior to execution (such as current working + directory, ``PYTHONPATH``) +* configuration files +* environment variables +* command line options +* installed packages or modules +* `.pth files `__ +* caches or ``.pyc`` files + +Vulnerabilities that affect availability (such as DoS, ReDoS) must be +triggerable with data inputs that are reasonably sized for the use-case. +Availability vulnerabilities must also demonstrate an "upward" change in posture +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. +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, +is available in the Threat Model section of the Python Developer Guide. + +What versions of Python are accepting reports? +---------------------------------------------- + +Python accepts security vulnerabilities and will +assign CVE IDs for `supported Python versions`_ that have a status of +`"bugfix" or "security" `_. Versions that are not yet +stable (status of `"feature" or "prerelease" `_) are not +eligible for CVE IDs. If the vulnerability exclusively exists in +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. + +If a vulnerability is platform-dependent, check if the platform is a +`supported platform per PEP 11 `__. +Vulnerabilities that exclusively affect unsupported platforms +may not be accepted. + +.. _supported Python versions: https://devguide.python.org/versions/ +.. _python-status: https://devguide.python.org/versions/#status-key + +What to include and how to structure a vulnerability report? +------------------------------------------------------------ + +For your vulnerability report to be handled efficiently by +the PSRT, the report must include certain information and +be formatted correctly: + +* For the initial report and follow-up communications, avoid + overly long, verbose, or excessive structure (such as headers or tables). + Ideally reports should be a few sentences describing the vulnerability and + a proof-of-concept script that reproduces the issue. +* When reporting large numbers or "batches" of vulnerabilities or + searching for potential vulnerabilities using an LLM, you as a reporter must + verify the validity of all reports prior to submission to the PSRT. + PSRT members WILL NOT spend time confirming the validity of reports, only + 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. +* 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 + or requesting compliance or due-diligence work) + will be discarded without a reply. + +How to submit a vulnerability report? +------------------------------------- + +Submit all potential security vulnerability reports for CPython +to `GitHub Security Advisories `__ +by `opening a new ticket `__. +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 +not sure where to send your report, send an email to +`security at python dot org `__. + +Here's what to expect for how a vulnerability report will be handled: + +* Reporter reports the vulnerability privately to the PSRT. +* If the PSRT determines the report isn't a vulnerability, the issue + can be opened in the public issue tracker. +* If the PSRT determines the report is a vulnerability, the PSRT will + accept your report and a CVE ID will be assigned by the PSF CNA. +* Once a public pull request containing a fix is merged to CPython, + the advisory and CVE record will be published with attribution. + +For more information about how the PSRT handles vulnerabilities, +`consult the Python Developer Guide `__. + +PSF Code of Conduct +------------------- + +Well-being and safety of the Python Security Response Team members is +prioritized over the technical merit of vulnerability reports. +Despite communications being private, vulnerability reporting is subject +to the `PSF Code of Conduct`_. Violations will be reported to the Code of Conduct +team with undisclosed vulnerability information removed, if applicable. + +.. _GHSA: https://github.com/python/cpython/security/advisories/new +.. _PSF Code of Conduct: https://policies.python.org/python.org/code-of-conduct/ + +CVE Numbering Authority (CNA) +----------------------------- + +The Python and pip projects are scoped under the +`Python Software Foundation CVE Numbering Authority `__ +(CNA). This means you must submit all security +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 `__. + +.. _CNA: https://www.python.org/cve-numbering-authority/ + From ac7db7f0197b0e30bbee131ee8d7c63abbd44ad3 Mon Sep 17 00:00:00 2001 From: Seth Larson Date: Tue, 19 May 2026 16:59:51 +0000 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Jelle Zijlstra Co-authored-by: Stan Ulbrych Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Co-authored-by: Emma Smith --- security/policy.rst | 43 +++++++++++++++++++++---------------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/security/policy.rst b/security/policy.rst index e96d6efa2..fb31ffc5d 100644 --- a/security/policy.rst +++ b/security/policy.rst @@ -2,31 +2,30 @@ Security Policy =============== -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 `__. +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 `__ +to GitHub Security Advisories by `opening a new ticket `__. 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 `__. +`security@python.org `__. Here's what to expect for how a vulnerability report will be handled: @@ -148,7 +147,7 @@ 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 `__. +`cna@python.org `__. .. _CNA: https://www.python.org/cve-numbering-authority/ From 846743420e6b865507ef74f111c511742b0e13ed Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Thu, 21 May 2026 11:11:32 -0700 Subject: [PATCH 3/4] Address review feedback --- security/policy.rst | 65 +++++++++++++++++++++------------------------ security/psrt.rst | 2 ++ versions.rst | 1 + 3 files changed, 34 insertions(+), 34 deletions(-) diff --git a/security/policy.rst b/security/policy.rst index fb31ffc5d..9d87a8c06 100644 --- a/security/policy.rst +++ b/security/policy.rst @@ -2,11 +2,11 @@ Security Policy =============== -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 or being banned from the `python` GitHub organization, regardless of technical merit. +Python Security Response Team (PSRT) members balance this work against +many other responsibilities. Please be thoughtful about the time and attention +your report requires. Repeated failure to respect the security policy will +result in future reports being rejected or being banned from the ``python`` +GitHub organization, regardless of technical merit. What types of bugs are vulnerabilities? --------------------------------------- @@ -15,6 +15,9 @@ Not all bugs are vulnerabilities. To avoid causing duplicate work for PSRT members all potential reports must be evaluated against the relevant threat models prior to being submitted to the PSRT. +Where possible, cite the relevant threat model to show that +the threat model has been considered while determining whether +to report a bug as a vulnerability. Vulnerabilities must be exploitable from code, configurations, pre-conditions, and deployments that might feasibly exist in @@ -23,21 +26,16 @@ 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, :mod:`pickle`, :mod:`marshal``, :mod:`shelve``, :mod:`eval``, +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. +as data. The :mod:`ctypes` module is documented to enable modifying arbitrary +locations in memory. -Vulnerabilities must not depend on malicious control of: - -* what Python code is executed by the interpreter -* locations where code is loaded prior to execution (such as current working - directory, ``PYTHONPATH``) -* configuration files -* environment variables -* command line options -* installed packages or modules -* `.pth files `__ -* caches or ``.pyc`` files +Vulnerabilities must not depend on malicious control of Python's launch +conditions, including command line arguments, environment variables, or +modifications to files on the target system. We assume that, at the time Python +is executed, the environment is as intended by the legitimate user, and any +malicious variation from this cannot be mitigated by Python itself. Vulnerabilities that affect availability (such as DoS, ReDoS) must be triggerable with data inputs that are reasonably sized for the use-case. @@ -48,21 +46,21 @@ 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 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 -is available in the Threat Model section of the Python Developer Guide. +For example, a vulnerability in the bundled copy of zlib in Python is a +vulnerability in zlib, not Python. What versions of Python are accepting reports? ---------------------------------------------- Python accepts security vulnerabilities and will -assign CVE IDs for `supported Python versions`_ that have a status of -`"bugfix" or "security" `_. Versions that are not yet -stable (status of `"feature" or "prerelease" `_) are not -eligible for CVE IDs. If the vulnerability exclusively exists in -non-stable versions, then the issue should be handled as a public bug issue. +assign CVE IDs for `supported Python versions `_ that have a status of +`"bugfix" or "security" `_. Versions that are not yet +stable (status of `"feature" or "prerelease" `_) are not +eligible for CVE IDs. If the vulnerability only exists in prerelease versions +(alphas, betas, release candidates), then the issue should be reported as a +regular bug. +Prior to submitting a report, check whether the issue has already been +resolved on the ``main`` branch and only requires backporting. Sometimes features may be marked as "experimental" in Python, even in a stable Python version. @@ -70,13 +68,10 @@ 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 -`supported per :pep:`11`. +supported per :pep:`11`. Vulnerabilities that exclusively affect unsupported platforms may not be accepted. -.. _supported Python versions: https://devguide.python.org/versions/ -.. _python-status: https://devguide.python.org/versions/#status-key - What to include and how to structure a vulnerability report? ------------------------------------------------------------ @@ -87,7 +82,9 @@ be formatted correctly: * For the initial report and follow-up communications, avoid overly long, verbose, or excessive structure (such as headers or tables). Ideally reports should be a few sentences describing the vulnerability and - a proof-of-concept script that reproduces the issue. + a proof-of-concept script that reproduces the issue and provides a clear + indication whether the vulnerability is still present (such as exiting with + ``1`` if vulnerable and ``0`` if not vulnerable). * When reporting large numbers or "batches" of vulnerabilities or searching for potential vulnerabilities using an LLM, you as a reporter must verify the validity of all reports prior to submission to the PSRT. @@ -124,7 +121,7 @@ Here's what to expect for how a vulnerability report will be handled: the advisory and CVE record will be published with attribution. For more information about how the PSRT handles vulnerabilities, -`consult the Python Developer Guide `__. +`consult the Python Developer Guide `__. PSF Code of Conduct ------------------- diff --git a/security/psrt.rst b/security/psrt.rst index 6b53700d8..d0ea659d2 100644 --- a/security/psrt.rst +++ b/security/psrt.rst @@ -84,6 +84,8 @@ following additional responsibilities: * Running nomination elections, including counting final votes and giving the Steering Council an opportunity to veto nominations via email. +.. _psrt-vulnerability-process: + Triaging a vulnerability report ------------------------------- diff --git a/versions.rst b/versions.rst index 58d56b3e0..228b445d9 100644 --- a/versions.rst +++ b/versions.rst @@ -45,6 +45,7 @@ Full chart .. raw:: html :file: _static/release-cycle-all.svg +.. _version-status-key: Status key ========== From e12f3a95d08795f1273908e699263799692d41fa Mon Sep 17 00:00:00 2001 From: "pre-commit-ci[bot]" <66853113+pre-commit-ci[bot]@users.noreply.github.com> Date: Thu, 21 May 2026 18:20:07 +0000 Subject: [PATCH 4/4] [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --- security/policy.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/security/policy.rst b/security/policy.rst index 9d87a8c06..873221e83 100644 --- a/security/policy.rst +++ b/security/policy.rst @@ -147,4 +147,3 @@ CNA contact directly, send an email to `cna@python.org `__. .. _CNA: https://www.python.org/cve-numbering-authority/ -