diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index c4cd5005378..ad28f35ce2a 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -686,6 +686,7 @@ peps/pep-0807.rst @dstufft # ... peps/pep-0809.rst @zooba peps/pep-0810.rst @pablogsal @DinoV @Yhg1s +peps/pep-0811.rst @sethmlarson @gpshead # ... peps/pep-2026.rst @hugovk # ... diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst new file mode 100644 index 00000000000..7bd52938d53 --- /dev/null +++ b/peps/pep-0811.rst @@ -0,0 +1,292 @@ +PEP: 811 +Title: Defining Python Security Response Team membership and responsibilities +Author: Seth Michael Larson +Sponsor: Gregory P. Smith +Discussions-To: Pending +Status: Draft +Type: Process +Topic: Governance +Created: 22-Oct-2025 +Post-History: + `06-Oct-2025 `__, + +Abstract +======== + +This PEP proposes formalizing the membership and responsibilities policies of +the Python Security Response Team (PSRT). The PSRT is a "highly trusted cabal of +Python developers" which handles security vulnerability disclosures to the +``security@python.org`` mailing list. + +The PSRT receives access to known vulnerabilities affecting CPython and pip before +they're disclosed to the public. This information is sensitive and if leaked +could harm Python users through zero-day attacks, where an attacker has access +to exploitable vulnerabilities before defenders are notified of fixes and given +a chance to upgrade. + +However, the PSRT often needs help from core developers in particular subject +areas to remediate vulnerabilities. This PEP proposes defined membership and +obligations for the PSRT, including a new "Coordinator" role, and proposes +adopting `GitHub Security Advisories `_ +(GHSAs) as the canonical reporting, tracking, and collaboration method between +the PSRT, reporters, and core developers for vulnerabilities. + +Motivation +========== + +Limit access to pre-disclosure vulnerability reports +---------------------------------------------------- + +Vulnerability report information prior to disclosure is sensitive, +Python users can be substantially harmed if vulnerabilities are exploited. +For this reason it's critical to limit access to information to only people +involved in the remediation of the vulnerability at hand. + +The historical approach to collaboration on patch development was to manually +add GitHub users to a private ``python/psrt`` repository +which is a mirror of the ``python/cpython`` repository. +This approach didn't allow filtering particular collaborators for specific +vulnerabilities, meaning all collaborators had access to all reports and patches. + +This manual process discouraged bringing on core developers outside +the PSRT to collaborate, which can make patch development more difficult. +This limitation also meant vulnerability reporters weren't able to collaborate on patches, +either. + +Onboarding new contributors to the PSRT +--------------------------------------- + +Unlike most open-source contributions, the work of the PSRT doesn't happen +in the open. Instead, most work occurs privately by a trusted group to limit +access to undisclosed +vulnerability reports. Given the sensitive nature of this work, it appears opaque from the outside, and +it's difficult to get started as a newcomer and to understand the +expectations of the group. + +In practice this has meant that relatively few new members join the PSRT, +which over time could negatively impact the group's ability to triage reports +and develop remediations with the core team. + +Lack of defined ownership for vulnerability reports +--------------------------------------------------- + +Currently PSRT reports don't have a clear "owner" of who is ensuring the +incident or report continues moving towards a resolved state. This is especially +an issue in the context of a mailing list, where it's difficult to know whether +an issue is being responded to by someone else already or whether your +determination on a report is the same as others within the PSRT. + +Ideally, similar to issues, pull requests, and PEPs, one defined person +would be responsible for moving the mitigation task forward to completion. +This allows that person to +contribute and make decisions on the task without fear of "stepping on toes". + +Aligning with vulnerability disclosure timelines +------------------------------------------------ + +Vulnerability reporting best practices `recommend a 90 day +timeline`_ between the initial disclosure and when a report is made public +to balance the needs of users, the project, and the reporter. +Many vulnerability reporting organizations already use this timeline +and will disclose vulnerabilities publicly even if the project doesn't +create their own mitigation. + +To avoid reports getting stuck, forgotten, or published publicly without a +remediation this PEP recommends aligning to the 90 days between initial +disclosure and publishing an advisory. + +.. _recommend a 90 day timeline: https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md + +Rationale +========= + +Steering Council and activity determine membership +-------------------------------------------------- + +The PSRT has no mechanism for deciding who to admit to or remove from the PSRT. +Combined with the security-sensitive nature of the work it can be difficult to +decide who should be admitted, but there must be a system responsible for +evaluating PSRT membership. + +This PEP proposes limiting PSRT membership only to active coordinators +of security vulnerabilities that are core developers or triagers, +members involved in oversight (Steering Council), +and members who need information about security releases (Release Managers). + +Activity is recommended as the metric for membership to avoid adding additional +risk without any additional benefit to projects by having reports being +triaged and coordinated. + +Using GitHub Security Advisories (GHSA) +--------------------------------------- + +This PEP proposes adopting GitHub Security Advisories as the +system to accept vulnerability reports due to its tight integration +with services already in use by relevant projects. + +CPython and pip already use GitHub for source control, issues, pull requests, +continuous integration (CI), and as a part of the release process. +GHSA supports the following features which are desirable for a +vulnerability reporting and management platform: + +* Managing GitHub teams and accounts as "collaborators" per-report + rather than per-project or globally. +* Managing non-PSRT collaborators per-report using GitHub accounts. +* "Pull request"-like user interface for developing remediations. +* Tracking reporter, coordinator, credits, submission time, CVE ID, and severity + for each report within the UI. +* Programmatic API for integrating with other services (like CVE) and bots. + +However, features that are missing from GHSA are: + +* Ability to privately run vulnerability remediation branches on CI. +* Multiple API endpoints are missing for the GHSA, such as retrieving and + creating comments on a GHSA report. + +These missing features have been reported to GitHub and none are blocking +the adoption of GHSA. Some work will need to be done to work around the +lack of a complete API for the GHSA feature. + +Specification +============= + +PSRT Membership Policy +---------------------- + +The Python Steering Council may add or remove members and admins of the PSRT. +New PSRT members must be core team members, triagers, or PSF staff, +and must be `proposed to and accepted`_ by the Steering Council. + +Once the Steering Council votes on a membership change to the PSRT then +PSRT admins will enact the change. +A list of PSRT members will be published publicly and kept up-to-date by PSRT +admins. + +Once per year the Steering Council will receive a report of inactive members of +the PSRT with the recommendation to remove the inactive users from the PSRT. +"Inactive" is defined here as a member who hasn't coordinated or commented on a +vulnerability report in the past year since the last report was generated. + +Members of the PSRT who are a Release Manager or Steering Council +member may remain in the PSRT regardless of inactivity in vulnerability reports. + +This PEP proposes removing all members from the PSRT who haven't been active +in the past year and without an exemption for minimum activity (Steering Council, +Release Managers) prior to publication of this PEP. At the time of writing, this +would reduce the PSRT membership size to ~15 members from ~30. + +This PEP also proposes not removing members of the PSRT who are active but +not yet core team members or triagers, allowing them to be "legacied" in +to the new PSRT Membership Policy. + +.. _proposed to and accepted: https://github.com/python/steering-council/ + +PSRT Admins +~~~~~~~~~~~ + +At least two PSRT members shall serve as admins, determined by the Steering +Council. This PEP proposes maintaining the existing set of PSRT admins: + +* Ned Deily +* Ee Durbin +* Seth Larson +* Barry Warsaw + +Admins have the additional responsibilities of managing membership and +triaging reports to the PSRT mailing list (``security@python.org``). + +Responsibilities of PSRT members +-------------------------------- + +The responsibilities of PSRT members will be documented publicly in the +`Python Developer's Guide`_, so prospective members know what to expect before +applying to join the PSRT. These responsibilities include: + +* Being knowledgeable about typical software vulnerability report handling + processes, such as CVE IDs, patches, coordinated disclosure, embargoes, etc. +* Not sharing or acting on embargoed information about the reported vulnerability. + Examples of disallowed behavior include sharing information with colleagues + or publicly deploying unpublished mitigations or patches ahead of the advisory + publication date. +* Acting as a "Coordinator" of vulnerability reports that are submitted + to projects. A coordinator's responsibility is to move a report through the PSRT + process to a "finished" state, either rejected or as a published advisory and + mitigation, within the industry standard timeline of 90 days. +* As a Coordinator, involving relevant core team members or triagers where + necessary to make a determination whether a report is a vulnerability and + developing a patch. Coordinators are **encouraged** to involve members of + the core team to make the best decision for each report rather than working + in isolation. +* As a Coordinator, calculating the severity using CVSS and authoring advisories + to be shared on `security-announce@python.org`_. These advisories are used + for CVE records by the PSF CVE Numbering Authority. +* Coordinators that can no longer move a report forwards for any reason must + delegate their Coordinator role to someone else in the PSRT. +* PSRT members that are admins will have additional responsibilities. + +.. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/ +.. _Python Developer's Guide: https://devguide.python.org/developer-workflow/psrt/ + +Responsibilities of PSRT Admins +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +PSRT members who are designated as admins by the Steering Council have the +following additional responsibilities: + +* Managing the GitHub team, mailing list, Discord channel, and other + PSRT venues to ensure they are synchronized with the canonical list of + PSRT members determined by the Steering Council. +* On a yearly basis, providing the Steering Council with a report including + a list of inactive PSRT members. + +GitHub Security Advisories and GitHub Team +------------------------------------------ + +This PEP proposes standardizing on the GitHub team ``python/psrt`` as the +canonical list of PSRT members and aligning the mailing list and Discord to match +instead of maintaining each separately. Process documentation will be created to +ensure changes to membership are consistent across these three channels as +members are added and removed. + +This PEP proposes adopting GitHub Security Advisories as the system where +vulnerability reports per project are handled. GHSA will be enabled for +relevant repositories and linked to directly from the top-level PSRT +page on python.org and project security policies. + +Along with responsibilities the PSRT process for handling vulnerability +reports using GHSA, such as how to assign a Coordinator and calculating +severity, will be added to the `Python Developer's Guide`_. + +Adopting GHSAs will coincide with disabling the ``python/psrt`` private +repository (which shares a slug with the GitHub team) and syncing machinery, +as this will no longer be needed for patch development. + +Continue using security@python.org mailing list +----------------------------------------------- + +The ``security@python.org`` mailing list covers more than CPython and pip, +like security reports for the ``python.org`` or related websites +and as a general hotline for Python ecosystem-related security issues. +Maintaining the mailing list can also be used as a "fall-back" in case +the vulnerability reporting platform changes in the future. + +For this reason, the mailing list and PSRT GPG key will continue to function +and be monitored, but reporters will be directed to individual project GitHub +Security Advisory forms for submitting vulnerability reports. + +Rejected Ideas +============== + +Should inactive members be more aggressively pruned? +---------------------------------------------------- + +The PSRT only triages a double-digit number of reports every year, meaning there +aren't an abundance of opportunities to "prove" activity on the scale of months. +For this reason along with aligning with existing yearly schedules for the +Steering Council, a yearly pruning was recommended. + +Copyright +========= + +This document is placed in the public domain or under the +CC0-1.0-Universal license, whichever is more permissive.