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..dea3cbe7e --- /dev/null +++ b/security/policy.rst @@ -0,0 +1,156 @@ +=============== +Security policy +=============== + +:ref:`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 the reporter 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 models +prior to being submitted to the PSRT. +Where possible, cite the relevant threat model to show that +the latter has been considered while determining whether +to report a bug as a vulnerability. + +Vulnerabilities must be exploitable from code, configurations, +pre-conditions, or deployments that may exist in 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 is not considered a vulnerability. +For example, :mod:`pickle`, :mod:`marshal`, :mod:`shelve`, :func:`eval`, +and :func:`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 Python's launch +conditions, including (but not limited to) 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, crashes, +dead-locks, and resource exhaustion) 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" one. +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, a vulnerability in the bundled copy of zlib in Python is a +vulnerability in zlib, not Python. + +What versions of Python accept reports? +--------------------------------------- + +Python accepts vulnerability reports and will +assign CVE IDs for :ref:`supported Python versions ` that have a +status of :ref:`"bugfix" or "security" `. Versions that are +not yet stable (status of :ref:`"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. +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`. +Vulnerabilities that exclusively affect unsupported platforms +may not be accepted. + +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 and provides a clear + indication of 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 factual validity (such as whether APIs have been hallucinated) + of the content in all reports prior to submission to the PSRT. +* Do not include severity or CVSS information in your initial report, + this information will be determined by the PSRT. +* Ideally, include a minimal patch with the mitigation for the report. +* Always include the versions of Python that were tested, + and indicate which were found to be vulnerable. +* Submit reports as plain-text only, including attachments. + No PDFs, binaries, notebooks, or other files that cannot be safely reviewed. + If your proof-of-concept depends on a specially constructed binary file, + please include a script to construct it rather than the file itself. +* Proof-of-concept scripts longer than a few lines should be wrapped with a + `collapsed section`_ using ``
`` for better readability. +* 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. + +.. _collapsed section: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-collapsed-sections + +How to submit a vulnerability report? +------------------------------------- + +Submit all potential security vulnerability reports for CPython +by `opening a new ticket `__. +Do not open a public GitHub issue to report a security vulnerability. +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@python.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 reporter + may open a public issue. +* If the PSRT determines the report is a vulnerability, the PSRT will + accept the 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, +see :ref:`psrt-vulnerability-process`. + +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 for a CVE ID +to be issued for Python or pip. To reach the PSF +CNA contact directly, send an email to +`cna@python.org `__. + +.. _CNA: https://www.python.org/cve-numbering-authority/ diff --git a/security/psrt.rst b/security/psrt.rst index 6b53700d8..7e780b6f8 100644 --- a/security/psrt.rst +++ b/security/psrt.rst @@ -1,3 +1,5 @@ +.. _psrt: + Python Security Response Team (PSRT) ==================================== @@ -84,6 +86,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 ==========