Skip to content

Commit ffab026

Browse files
sethmlarsonsethmlarson
committed
Create PEP for PSRT membership and responsibilities
1 parent 33a7a06 commit ffab026

File tree

2 files changed

+323
-0
lines changed

2 files changed

+323
-0
lines changed

‎.github/CODEOWNERS‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -679,6 +679,7 @@ peps/pep-0800.rst @JelleZijlstra
679679
peps/pep-0801.rst @warsaw
680680
peps/pep-0802.rst @AA-Turner
681681
peps/pep-0803.rst @encukou
682+
peps/pep-0811.rst @sethmlarson @gpshead
682683
# ...
683684
peps/pep-2026.rst @hugovk
684685
# ...

‎peps/pep-0811.rst‎

Lines changed: 322 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,322 @@
1+
PEP: 811
2+
Title: Defining Python Security Response Team membership and responsibilities
3+
Author: Seth Michael Larson <seth@python.org>
4+
Sponsor: Gregory P. Smith <greg@krypto.org>
5+
Status: Draft
6+
Type: Process
7+
Created: 23-Oct-2025
8+
9+
Abstract
10+
========
11+
12+
This PEP proposes formalizing the membership and responsibilities policies of
13+
the Python Security Response Team (PSRT). The PSRT is a "highly trusted cabal of
14+
Python developers" which handles security vulnerability disclosures to the
15+
``security@python.org`` mailing list.
16+
17+
The PSRT has access to known vulnerabilities affecting CPython and pip before
18+
they're disclosed to the public. This information is sensitive and if leaked
19+
could harm Python users through zero-day attacks, where an attacker has access
20+
to exploitable vulnerabilities before defenders are notified of fixes and given
21+
a chance to upgrade.
22+
23+
However, the PSRT often needs help from core developers in particular subject
24+
areas to remediate vulnerabilities. This PEP proposes defined membership and
25+
obligations for the PSRT, including a new "Coordinator" role, and proposes
26+
adopting `GitHub Security Advisories <https://docs.github.com/en/code-security/security-advisories>`_
27+
(GHSAs) as the canonical reporting, tracking, and collaboration method between
28+
the PSRT, reporters, and core developers for vulnerabilities.
29+
30+
Motivation
31+
==========
32+
33+
Limit access to pre-disclosure vulnerability reports
34+
----------------------------------------------------
35+
36+
Vulnerability report information prior to disclosure is sensitive,
37+
Python users can be substantially harmed if vulnerabilities are exploited.
38+
For this reason it's critical to limit access to information to only users
39+
involved in the remediation of the vulnerability at hand.
40+
41+
The historical approach to collaboration on patch development was to manually
42+
add GitHub users to a private ``python/psrt`` repository
43+
which was an automatically synced mirror of the ``python/cpython`` repository.
44+
This approach didn't allow filtering particular collaborators for specific
45+
vulnerabilities, meaning all collaborators had access to all reports and patches.
46+
47+
This being a manual process discouraged bringing on core developers outside
48+
the PSRT to collaborate which can make patch development more difficult.
49+
This limitation also meant reporters weren't able to collaborate on patches,
50+
either.
51+
52+
Onboarding new contributors to the PSRT
53+
---------------------------------------
54+
55+
Unlike most open source contributions, the work of the PSRT doesn't happen
56+
in the open. Instead, most work occurs privately to protect undisclosed
57+
vulnerability reports. This means the work is opaque from the outside
58+
so it's difficult to get started as a newcomer and to understand the
59+
expectations of the group.
60+
61+
In practice this has meant that relatively few new members join the PSRT,
62+
which over time could negatively impact the groups ability to triage reports
63+
and develop remediations with the core team.
64+
65+
Lack of defined ownership for vulnerability reports
66+
---------------------------------------------------
67+
68+
Currently PSRT reports don't have a clear "owner" of who is ensuring the
69+
incident or report continues moving towards a resolved state. This is especially
70+
an issue in the context of a mailing list, where it's difficult to know whether
71+
an issue is being responded to by someone else already or whether your
72+
determination on a report is the same as others within the PSRT.
73+
74+
Ideally, similar to issues, pull requests, and PEPs, there is one defined person
75+
who is moving the task forwards completion. This allows that person to
76+
contribute and make decisions on the task without fear of "stepping on toes".
77+
78+
Aligning with vulnerability disclosure timelines
79+
------------------------------------------------
80+
81+
Vulnerability reporting best practices `recommend a 90 day
82+
timeline`_ between the initial disclosure and when a report is made public
83+
to balance the needs of users, the project, and the reporter.
84+
Many vulnerability reporting organizations already use this timeline
85+
and will disclose vulnerabilities publicly even if the project doesn't
86+
create their own mitigation.
87+
88+
To avoid reports getting stuck, forgotten, or published publicly without a
89+
remediation this PEP recommends aligning to the 90 days between initial
90+
disclosure and publishing an advisory.
91+
92+
.. _recommend a 90 day timeline: https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md
93+
94+
Rationale
95+
=========
96+
97+
Steering Council and activity determine membership
98+
--------------------------------------------------
99+
100+
The PSRT has no mechanism for deciding who to admit to or remove from the PSRT.
101+
Combined with the security-sensitive nature of the work it can be difficult to
102+
decide who should be admitted, but there must be a system responsible for
103+
evaluating PSRT membership.
104+
105+
This PEP proposes limiting PSRT membership only to active coordinators
106+
of security vulnerabilities that are core developers or triagers,
107+
members involved in oversight (Steering Council),
108+
and members who need information about security releases (Release Managers).
109+
110+
Activity is recommended as the metric for membership to avoid adding additional
111+
risk without any additional benefit to projects by having reports being
112+
triaged and coordinated.
113+
114+
Using GitHub Security Advisories (GHSA)
115+
---------------------------------------
116+
117+
This PEP proposes adopting GitHub Security Advisories as the
118+
system to accept vulnerability reports due to its tight integration
119+
with services already in use by relevant projects.
120+
121+
CPython and pip already use GitHub for source control, issues, pull requests,
122+
continuous integration (CI), and as a part of the release process.
123+
GHSA supports the following features which are desirable for a
124+
vulnerability reporting and management platform:
125+
126+
* Managing GitHub teams and accounts as "collaborators" per-report
127+
rather than per-project or globally.
128+
* Managing non-PSRT collaborators per-report using GitHub accounts.
129+
* "Pull request"-like user interface for developing remediations.
130+
* Tracking reporter, coordinator, credits, submission time, CVE ID, and severity
131+
for each report within the UI.
132+
* Programatic API for integrating with other services (like CVE) and bots.
133+
134+
However, features that are missing from GHSA are:
135+
136+
* Ability to privately run vulnerability remediation branches on CI.
137+
* Multiple API endpoints are missing for the GHSA, such as retrieving and
138+
creating comments on a GHSA report.
139+
140+
These missing features have been reported to GitHub and none are blocking
141+
the adoption of GHSA. Some work will need to be done to work-around the
142+
lack of a complete API for the GHSA feature.
143+
144+
Specification
145+
=============
146+
147+
PSRT Membership Policy
148+
----------------------
149+
150+
The Python Steering Council may add or remove members and admins of the PSRT.
151+
New PSRT members must core team members or triagers and must be `proposed to
152+
and accepted`_ by the Steering Council.
153+
154+
Once the Steering Council votes on a membership change to the PSRT then
155+
PSRT admins will enact the change.
156+
A list of PSRT members will be published publicly and kept up-to-date by PSRT
157+
admins.
158+
159+
Once per year the Steering Council will receive a report of inactive members of
160+
the PSRT with the recommendation to remove the inactive users from the PSRT.
161+
"Inactive" defined here as a member who hasn't coordinated or commented on a
162+
vulnerability report in the past year since the report was generated.
163+
164+
Members of the PSRT that are a Release Manager or Steering Council
165+
member may remain in the PSRT regardless of inactivity in vulnerability reports.
166+
167+
This PEP proposes removing all members from the PSRT who haven't been active
168+
in the past year and without an exemption for minimum activity (Steering Council,
169+
Release Managers) prior to pubication of this PEP. At the time of writing, this
170+
would reduce the PSRT membership size to ~15 members from ~30.
171+
172+
This PEP also proposes not removing members of the PSRT who are active but
173+
not yet core team members or triagers, allowing them to be "legacied" in
174+
to the new PSRT Membership Policy.
175+
176+
.. _proposed to and accepted: https://github.com/python/steering-council/
177+
178+
PSRT Admins
179+
~~~~~~~~~~~
180+
181+
At least two PSRT members shall serve as admins, determined by the Steering
182+
Council. This PEP proposes maintaining the existing set of PSRT admins:
183+
184+
* Ned Deily <nad@python.org>
185+
* Ee Durbin <ee@python.org>
186+
* Seth Larson <seth@python.org>
187+
* Barry Warsaw <barry@python.org>
188+
189+
Admins have the additional responsibilities of managing membership and
190+
triaging reports to the PSRT mailing list (``security@python.org``).
191+
192+
Responsibilities of PSRT members
193+
--------------------------------
194+
195+
The responsibilities of PSRT members will be documented publicly in the
196+
`Python Developer Guide`_, so prospective members know what to expect before
197+
applying to join the PSRT. These responsibilities include:
198+
199+
* Being knowledgeable about typical software vulnerability report handling
200+
processes, such as CVE IDs, patches, coordinated disclosure, embargoes, etc.
201+
* Not sharing or acting on embargoed information about the reported vulnerability.
202+
Examples of disallowed behavior include, sharing information with colleagues
203+
or publicly deploying unpublished mitigations or patches ahead of the advisory
204+
publication date.
205+
* Acting as a "Coordinator" of vulnerability reports that are submitted
206+
to projects. Coordinators responsibility is to move a report through the PSRT
207+
process to a "finished" state, either rejected or as a published advisory and
208+
mitigation, within the industry standard timeline of 90 days.
209+
* As a Coordinator, involving relevant core team members or triagers where
210+
necessary to make a determination whether a report is a vulnerability and
211+
developing a patch. Coordinators are **encouraged** to involve members of
212+
the core team to make the best decision for each report rather than working
213+
in isolation.
214+
* As a Coordinator, calculating the severity using CVSS and authoring advisories
215+
to be shared on `security-announce@python.org`_. These advisories are used
216+
for CVE records by the PSF CVE Numbering Authority.
217+
* Coordinators that can no longer move a report forwards for any reason must
218+
delegate their Coordinator role to someone else in the PSRT.
219+
* PSRT members that are admins will have additional responsibilities.
220+
* PSRT members that are staff of the Python Software Foundation, as an
221+
"Open Source Steward" defined in `Article 24 of the Cyber Resilience Act`_,
222+
have `additional responsibilities`_, such as reporting actively exploited
223+
vulnerabilities to ENISA/CSIRTs.
224+
225+
.. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/
226+
.. _Article 24 of the Cyber Resilience Act: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_24
227+
.. _additional responsibilities: #responsibilities-of-psf-staff-psrt-members
228+
.. _Python Developer Guide: https://devguide.python.org/developer-workflow/psrt/
229+
230+
Responsibilities of PSRT Admins
231+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
232+
233+
PSRT members that are designated as admins by the Steering Council have the
234+
following additional responsibilities:
235+
236+
* Managing the GitHub team, mailing list, Discord channel, and other
237+
PSRT venues to ensure they are synchronized with the canonical list of
238+
PSRT members determined by the Steering Council.
239+
* On a yearly basis, providing the Steering Council with a report including
240+
a list of inactive PSRT members.
241+
242+
Responsibilities of PSF Staff PSRT members
243+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
244+
245+
The Python Software Foundation acts as the "Open Source Steward" for
246+
CPython, pip, and other projects according to the Cyber Resilience Act (CRA).
247+
Therefore, vulnerability reporting has additional requirements for PSF staff
248+
detailed in CRA `Article 24 <https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_24>`_.
249+
These requirements can be summarized as:
250+
251+
➤ Maintain a vulnerability disclosure policy fostering the voluntary reporting of vulnerabilities.
252+
The policy shall include aspects related to documenting, addressing, and remediating vulnerabilities
253+
and promote the sharing of information concerning discovered vulnerabilities within the open source community.
254+
255+
➤ Cooperate with EU market surveillance authorities (ENISA and CSIRTs) to
256+
mitigate cybersecurity risks.
257+
258+
➤ If a vulnerability is **known to be actively exploited** EU market surveillance
259+
authorities must be notified through the Single Reporting Platform (SRP)
260+
within the following timelines:
261+
262+
* **Within 24 hours of becoming aware of an actively exploited vulnerability:** submit an early warning notification.
263+
* **Within 72 hours of becoming aware of an actively exploited vulnerability:** submit general information,
264+
the product, general nature of the exploit and vulnerability, and mitigating measures taking or mitigating measures that users can take.
265+
* **Within 14 days after a corrective or mitigating measure is available:** a final report including a description
266+
of the vulnerability including severity and impact, information concerning any malicious actor, and details
267+
about the security update or other corrective measures available to remedy the vulnerability.
268+
269+
Note that these additional responsibilities don't apply to all members of the
270+
PSRT, only to PSF staff.
271+
272+
GitHub Security Advisories and GitHub Team
273+
------------------------------------------
274+
275+
This PEP proposes standardizing on the GitHub team ``python/psrt`` as the
276+
canonical list of PSRT members and aligning the mailing list and Discord to match
277+
instead of maintaining each separately. Process documentation will be created to
278+
ensure changes to membership are consistent across these three channels as
279+
members are added and removed.
280+
281+
This PEP proposes adopting GitHub Security Advisories as the system where
282+
vulnerability reports per project are handled. GHSA will be enabled for
283+
relevant repositories and linked to directly from the top-level PSRT
284+
page on python.org and project security policies.
285+
286+
Along with responsibilities the PSRT process for handling vulnerability
287+
reports using GHSA, such as how to assign a Coordinator and calculating
288+
severity, will be added to the `Python Developer Guide`_.
289+
290+
Adopting GHSAs will coincide with disabling the ``python/psrt`` private
291+
repository (which shares a slug with the GitHub team) and syncing machinery,
292+
as this will no longer be needed for patch development.
293+
294+
Continue using security@python.org mailing list
295+
-----------------------------------------------
296+
297+
The ``security@python.org`` mailing list covers more than CPython and pip,
298+
like security reports for the ``python.org`` or related websites
299+
and as a general hotline for Python ecosystem-related security issues.
300+
Maintaining the mailing list can also be used as a "fall-back" in case
301+
the vulnerability reporting platform changes in the future.
302+
303+
For this reason, the mailing list and PSRT GPG key will continue to function
304+
and be monitored, but reporters will be directed to individual project GitHub
305+
Security Advisory forms for submitting vulnerability reports.
306+
307+
Rejected ideas
308+
==============
309+
310+
Should inactive members be more aggressively pruned?
311+
----------------------------------------------------
312+
313+
The PSRT only triages a double-digit number of reports every year, meaning there
314+
aren't an abundance of opportunities to "prove" activity on the scale of months.
315+
For this reason along with aligning with existing yearly schedules for the
316+
Steering Council, a yearly pruning was recommended.
317+
318+
Copyright
319+
=========
320+
321+
This document is placed in the public domain or under the
322+
CC0-1.0-Universal license, whichever is more permissive.

0 commit comments

Comments
 (0)