PEP 811: Defining Python Security Response Team membership and responsibilities (#4669)

Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Carol Willing <[email protected]>

Author: 3 people

.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
 # ...

peps/pep-0811.rst

@@ -0,0 +1,292 @@
+PEP: 811
+Title: Defining Python Security Response Team membership and responsibilities
+Author: Seth Michael Larson <[email protected]>
+Sponsor: Gregory P. Smith <[email protected]>
+Discussions-To: Pending
+Status: Draft
+Type: Process
+Topic: Governance
+Created: 22-Oct-2025
+Post-History:
+  `06-Oct-2025 <https://discuss.python.org/t/104199>`__,
+
+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
+``[email protected]`` 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 <https://docs.github.com/en/code-security/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 <[email protected]>
+* Ee Durbin <[email protected]>
+* Seth Larson <[email protected]>
+* Barry Warsaw <[email protected]>
+
+Admins have the additional responsibilities of managing membership and
+triaging reports to the PSRT mailing list (``[email protected]``).
+
+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 `[email protected]`_. 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.
+
+.. _[email protected]: https://mail.python.org/archives/list/[email protected]/
+.. _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 [email protected] mailing list
+-----------------------------------------------
+
+The ``[email protected]`` 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.