PEP: 811
Title: Defining Python Security Response Team membership and responsibilities
Author: Seth Michael Larson <seth@python.org>
Sponsor: Gregory P. Smith <greg@krypto.org>
Discussions-To: https://discuss.python.org/t/104606
Status: Active
Type: Process
Topic: Governance
Created: 22-Oct-2025
Post-History:
  `06-Oct-2025 <https://discuss.python.org/t/104199>`__,
  `28-Oct-2025 <https://discuss.python.org/t/104606>`__,
Resolution: `04-Dec-2025 <https://discuss.python.org/t/104606/20>`__

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 <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, 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 PSRT will run nominations `similar to core team nominations`_, where
a nomination of a new member is brought to the PSRT by an existing PSRT member
and then that nomination is voted on by existing PSRT members. New members
are expected to be drawn from core developers, triagers, or PSF staff.
It is granted by receiving at least two-thirds positive votes from a vote of
existing PSRT members that is open for one week and is not vetoed by the
Steering Council.

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.
The Steering Council may remove members of the PSRT with a simple vote.

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.

.. _similar to core team nominations: https://devguide.python.org/core-team/join-team/

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 <nad@python.org>
* Ee Durbin <ee@python.org>
* Seth Larson <seth@python.org>
* Barry Warsaw <barry@python.org>

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