From 676b9df75b9c5cdb00169cda65f699f98534732d Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Mon, 18 May 2026 18:29:31 -0700 Subject: [PATCH 1/2] Initial draft of Python 'Security Policy' --- index.rst | 1 + security-and-threat-model/index.rst | 153 ++++++++++++++++++++++++++++ 2 files changed, 154 insertions(+) create mode 100644 security-and-threat-model/index.rst diff --git a/index.rst b/index.rst index 4a478e7cc..176a32520 100644 --- a/index.rst +++ b/index.rst @@ -288,6 +288,7 @@ Full table of contents testing/index development-tools/index core-team/index + security-and-threat-model/index internals versions diff --git a/security-and-threat-model/index.rst b/security-and-threat-model/index.rst new file mode 100644 index 000000000..d6234fd3e --- /dev/null +++ b/security-and-threat-model/index.rst @@ -0,0 +1,153 @@ +========================= +Security and threat model +========================= + +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 a777b0eb86ef8cea09c43248bbb0631712c1c22b Mon Sep 17 00:00:00 2001 From: Seth Larson Date: Tue, 19 May 2026 16:59:51 +0000 Subject: [PATCH 2/2] 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-and-threat-model/index.rst | 43 ++++++++++++++--------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/security-and-threat-model/index.rst b/security-and-threat-model/index.rst index d6234fd3e..94c85dc95 100644 --- a/security-and-threat-model/index.rst +++ b/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 `__. +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,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 `__. +`cna@python.org `__. .. _CNA: https://www.python.org/cve-numbering-authority/