From ffab026b74ac54a4218e03866011769f4dffae09 Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Mon, 24 Jun 2024 14:30:03 -0500 Subject: [PATCH 1/8] Create PEP for PSRT membership and responsibilities --- .github/CODEOWNERS | 1 + peps/pep-0811.rst | 322 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 323 insertions(+) create mode 100644 peps/pep-0811.rst diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 42c10c3dcb3..1b5f1c3460b 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -679,6 +679,7 @@ peps/pep-0800.rst @JelleZijlstra peps/pep-0801.rst @warsaw peps/pep-0802.rst @AA-Turner peps/pep-0803.rst @encukou +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..231dc009e30 --- /dev/null +++ b/peps/pep-0811.rst @@ -0,0 +1,322 @@ +PEP: 811 +Title: Defining Python Security Response Team membership and responsibilities +Author: Seth Michael Larson +Sponsor: Gregory P. Smith +Status: Draft +Type: Process +Created: 23-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 has 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 users +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 was an automatically synced 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 being a manual process discouraged bringing on core developers outside +the PSRT to collaborate which can make patch development more difficult. +This limitation also meant 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 to protect undisclosed +vulnerability reports. This means the work is opaque from the outside +so 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 groups 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, there is one defined person +who is moving the task forwards 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. +* Programatic 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 core team members or triagers 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" defined here as a member who hasn't coordinated or commented on a +vulnerability report in the past year since the report was generated. + +Members of the PSRT that 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 pubication 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 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. Coordinators 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. +* PSRT members that are staff of the Python Software Foundation, as an + "Open Source Steward" defined in `Article 24 of the Cyber Resilience Act`_, + have `additional responsibilities`_, such as reporting actively exploited + vulnerabilities to ENISA/CSIRTs. + +.. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/ +.. _Article 24 of the Cyber Resilience Act: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_24 +.. _additional responsibilities: #responsibilities-of-psf-staff-psrt-members +.. _Python Developer Guide: https://devguide.python.org/developer-workflow/psrt/ + +Responsibilities of PSRT Admins +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +PSRT members that 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. + +Responsibilities of PSF Staff PSRT members +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Python Software Foundation acts as the "Open Source Steward" for +CPython, pip, and other projects according to the Cyber Resilience Act (CRA). +Therefore, vulnerability reporting has additional requirements for PSF staff +detailed in CRA `Article 24 `_. +These requirements can be summarized as: + +➤ Maintain a vulnerability disclosure policy fostering the voluntary reporting of vulnerabilities. +The policy shall include aspects related to documenting, addressing, and remediating vulnerabilities +and promote the sharing of information concerning discovered vulnerabilities within the open source community. + +➤ Cooperate with EU market surveillance authorities (ENISA and CSIRTs) to +mitigate cybersecurity risks. + +➤ If a vulnerability is **known to be actively exploited** EU market surveillance +authorities must be notified through the Single Reporting Platform (SRP) +within the following timelines: + +* **Within 24 hours of becoming aware of an actively exploited vulnerability:** submit an early warning notification. +* **Within 72 hours of becoming aware of an actively exploited vulnerability:** submit general information, + the product, general nature of the exploit and vulnerability, and mitigating measures taking or mitigating measures that users can take. +* **Within 14 days after a corrective or mitigating measure is available:** a final report including a description + of the vulnerability including severity and impact, information concerning any malicious actor, and details + about the security update or other corrective measures available to remedy the vulnerability. + +Note that these additional responsibilities don't apply to all members of the +PSRT, only to PSF staff. + +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 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. From b7e18b60d8f3f423b8562ae1dce8b723532d1583 Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Wed, 22 Oct 2025 15:43:32 -0500 Subject: [PATCH 2/8] python/psrt repository isn't automatically synced --- peps/pep-0811.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst index 231dc009e30..7fa23367f21 100644 --- a/peps/pep-0811.rst +++ b/peps/pep-0811.rst @@ -40,7 +40,7 @@ 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 was an automatically synced mirror of the ``python/cpython`` 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. @@ -304,7 +304,7 @@ 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 +Rejected Ideas ============== Should inactive members be more aggressively pruned? From d24489134f4262ecb71101cf561aba44398a75a5 Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Wed, 22 Oct 2025 20:57:02 +0000 Subject: [PATCH 3/8] Apply suggestions from code review Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> --- peps/pep-0811.rst | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst index 7fa23367f21..52d6ade77f5 100644 --- a/peps/pep-0811.rst +++ b/peps/pep-0811.rst @@ -4,7 +4,7 @@ Author: Seth Michael Larson Sponsor: Gregory P. Smith Status: Draft Type: Process -Created: 23-Oct-2025 +Created: 22-Oct-2025 Abstract ======== @@ -35,7 +35,7 @@ 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 users +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 @@ -52,14 +52,14 @@ either. Onboarding new contributors to the PSRT --------------------------------------- -Unlike most open source contributions, the work of the PSRT doesn't happen +Unlike most open-source contributions, the work of the PSRT doesn't happen in the open. Instead, most work occurs privately to protect undisclosed vulnerability reports. This means the work is opaque from the outside so 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 groups ability to triage reports +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 @@ -129,7 +129,7 @@ vulnerability reporting and management platform: * "Pull request"-like user interface for developing remediations. * Tracking reporter, coordinator, credits, submission time, CVE ID, and severity for each report within the UI. -* Programatic API for integrating with other services (like CVE) and bots. +* Programmatic API for integrating with other services (like CVE) and bots. However, features that are missing from GHSA are: @@ -138,7 +138,7 @@ However, features that are missing from GHSA are: 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 +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 @@ -148,7 +148,7 @@ PSRT Membership Policy ---------------------- The Python Steering Council may add or remove members and admins of the PSRT. -New PSRT members must core team members or triagers and must be `proposed to +New PSRT members must be core team members or triagers and must be `proposed to and accepted`_ by the Steering Council. Once the Steering Council votes on a membership change to the PSRT then @@ -158,15 +158,15 @@ 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" defined here as a member who hasn't coordinated or commented on a -vulnerability report in the past year since the report was generated. +"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 that are a Release Manager or Steering Council +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 pubication of this PEP. At the time of writing, this +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 @@ -193,17 +193,17 @@ Responsibilities of PSRT members -------------------------------- The responsibilities of PSRT members will be documented publicly in the -`Python Developer Guide`_, so prospective members know what to expect before +`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 + 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. Coordinators responsibility is to move a report through the PSRT + 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 @@ -217,7 +217,7 @@ applying to join the PSRT. These responsibilities include: * 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. -* PSRT members that are staff of the Python Software Foundation, as an +* PSRT members who are staff of the Python Software Foundation, as an "Open Source Steward" defined in `Article 24 of the Cyber Resilience Act`_, have `additional responsibilities`_, such as reporting actively exploited vulnerabilities to ENISA/CSIRTs. @@ -225,12 +225,12 @@ applying to join the PSRT. These responsibilities include: .. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/ .. _Article 24 of the Cyber Resilience Act: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_24 .. _additional responsibilities: #responsibilities-of-psf-staff-psrt-members -.. _Python Developer Guide: https://devguide.python.org/developer-workflow/psrt/ +.. _Python Developer's Guide: https://devguide.python.org/developer-workflow/psrt/ Responsibilities of PSRT Admins ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -PSRT members that are designated as admins by the Steering Council have the +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 @@ -250,7 +250,7 @@ These requirements can be summarized as: ➤ Maintain a vulnerability disclosure policy fostering the voluntary reporting of vulnerabilities. The policy shall include aspects related to documenting, addressing, and remediating vulnerabilities -and promote the sharing of information concerning discovered vulnerabilities within the open source community. +and promote the sharing of information concerning discovered vulnerabilities within the open-source community. ➤ Cooperate with EU market surveillance authorities (ENISA and CSIRTs) to mitigate cybersecurity risks. @@ -285,7 +285,7 @@ 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 Guide`_. +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, From b59e69f2f8c7429ccbe070f4fc5b95565cf3338b Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Thu, 23 Oct 2025 13:14:08 +0000 Subject: [PATCH 4/8] Apply suggestions from code review Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> --- peps/pep-0811.rst | 44 +++++++++++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 17 deletions(-) diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst index 52d6ade77f5..f937b7bc555 100644 --- a/peps/pep-0811.rst +++ b/peps/pep-0811.rst @@ -2,9 +2,12 @@ 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: Pending Abstract ======== @@ -248,23 +251,30 @@ Therefore, vulnerability reporting has additional requirements for PSF staff detailed in CRA `Article 24 `_. These requirements can be summarized as: -➤ Maintain a vulnerability disclosure policy fostering the voluntary reporting of vulnerabilities. -The policy shall include aspects related to documenting, addressing, and remediating vulnerabilities -and promote the sharing of information concerning discovered vulnerabilities within the open-source community. - -➤ Cooperate with EU market surveillance authorities (ENISA and CSIRTs) to -mitigate cybersecurity risks. - -➤ If a vulnerability is **known to be actively exploited** EU market surveillance -authorities must be notified through the Single Reporting Platform (SRP) -within the following timelines: - -* **Within 24 hours of becoming aware of an actively exploited vulnerability:** submit an early warning notification. -* **Within 72 hours of becoming aware of an actively exploited vulnerability:** submit general information, - the product, general nature of the exploit and vulnerability, and mitigating measures taking or mitigating measures that users can take. -* **Within 14 days after a corrective or mitigating measure is available:** a final report including a description - of the vulnerability including severity and impact, information concerning any malicious actor, and details - about the security update or other corrective measures available to remedy the vulnerability. +* Maintain a vulnerability disclosure policy fostering the voluntary reporting + of vulnerabilities. The policy shall include aspects related to documenting, + addressing, and remediating vulnerabilities and promote the sharing of + information concerning discovered vulnerabilities within the open-source + community. + +* Cooperate with EU market surveillance authorities (ENISA and CSIRTs) to + mitigate cybersecurity risks. + +* If a vulnerability is **known to be actively exploited** EU market + surveillance authorities must be notified through the Single Reporting + Platform (SRP) within the following timelines: + + * **Within 24 hours of becoming aware of an actively exploited + vulnerability:** submit an early warning notification. + * **Within 72 hours of becoming aware of an actively exploited + vulnerability:** submit general information, + the product, general nature of the exploit and vulnerability, and + mitigating measures taking or mitigating measures that users can take. + * **Within 14 days after a corrective or mitigating measure is available:** a + final report including a description of the vulnerability including + severity and impact, information concerning any malicious actor, and details + about the security update or other corrective measures available to remedy + the vulnerability. Note that these additional responsibilities don't apply to all members of the PSRT, only to PSF staff. From 91c53cc5099031ea30265db6e62189b5f3bbc0e7 Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Thu, 23 Oct 2025 08:45:17 -0500 Subject: [PATCH 5/8] Add Post-History for pre-PEP discussion --- peps/pep-0811.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst index f937b7bc555..cd0661770c0 100644 --- a/peps/pep-0811.rst +++ b/peps/pep-0811.rst @@ -7,7 +7,8 @@ Status: Draft Type: Process Topic: Governance Created: 22-Oct-2025 -Post-History: Pending +Post-History: + `06-Oct-2025 `__, Abstract ======== From c1871302934c1bf76257d2a209ca1874f2f2c28c Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Thu, 23 Oct 2025 14:33:29 -0500 Subject: [PATCH 6/8] Remove CRA requirements from PEP --- peps/pep-0811.rst | 43 ------------------------------------------- 1 file changed, 43 deletions(-) diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst index cd0661770c0..a314e5cc9db 100644 --- a/peps/pep-0811.rst +++ b/peps/pep-0811.rst @@ -221,14 +221,8 @@ applying to join the PSRT. These responsibilities include: * 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. -* PSRT members who are staff of the Python Software Foundation, as an - "Open Source Steward" defined in `Article 24 of the Cyber Resilience Act`_, - have `additional responsibilities`_, such as reporting actively exploited - vulnerabilities to ENISA/CSIRTs. .. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/ -.. _Article 24 of the Cyber Resilience Act: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_24 -.. _additional responsibilities: #responsibilities-of-psf-staff-psrt-members .. _Python Developer's Guide: https://devguide.python.org/developer-workflow/psrt/ Responsibilities of PSRT Admins @@ -243,43 +237,6 @@ following additional responsibilities: * On a yearly basis, providing the Steering Council with a report including a list of inactive PSRT members. -Responsibilities of PSF Staff PSRT members -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Python Software Foundation acts as the "Open Source Steward" for -CPython, pip, and other projects according to the Cyber Resilience Act (CRA). -Therefore, vulnerability reporting has additional requirements for PSF staff -detailed in CRA `Article 24 `_. -These requirements can be summarized as: - -* Maintain a vulnerability disclosure policy fostering the voluntary reporting - of vulnerabilities. The policy shall include aspects related to documenting, - addressing, and remediating vulnerabilities and promote the sharing of - information concerning discovered vulnerabilities within the open-source - community. - -* Cooperate with EU market surveillance authorities (ENISA and CSIRTs) to - mitigate cybersecurity risks. - -* If a vulnerability is **known to be actively exploited** EU market - surveillance authorities must be notified through the Single Reporting - Platform (SRP) within the following timelines: - - * **Within 24 hours of becoming aware of an actively exploited - vulnerability:** submit an early warning notification. - * **Within 72 hours of becoming aware of an actively exploited - vulnerability:** submit general information, - the product, general nature of the exploit and vulnerability, and - mitigating measures taking or mitigating measures that users can take. - * **Within 14 days after a corrective or mitigating measure is available:** a - final report including a description of the vulnerability including - severity and impact, information concerning any malicious actor, and details - about the security update or other corrective measures available to remedy - the vulnerability. - -Note that these additional responsibilities don't apply to all members of the -PSRT, only to PSF staff. - GitHub Security Advisories and GitHub Team ------------------------------------------ From 7b92d49ab25248eaae40b94966286d12506fc5ba Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Fri, 24 Oct 2025 17:44:32 +0000 Subject: [PATCH 7/8] Apply suggestions from code review Co-authored-by: Carol Willing --- peps/pep-0811.rst | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst index a314e5cc9db..7bab67ef4f1 100644 --- a/peps/pep-0811.rst +++ b/peps/pep-0811.rst @@ -18,7 +18,7 @@ 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 has access to known vulnerabilities affecting CPython and pip before +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 @@ -48,18 +48,19 @@ 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 being a manual process discouraged bringing on core developers outside -the PSRT to collaborate which can make patch development more difficult. -This limitation also meant reporters weren't able to collaborate on 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 to protect undisclosed -vulnerability reports. This means the work is opaque from the outside -so it's difficult to get started as a newcomer and to understand the +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, @@ -75,8 +76,9 @@ 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, there is one defined person -who is moving the task forwards completion. This allows that person to +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 From 34abffbb7469c7d0a6ce7bf6998f7f25c7881b4c Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Fri, 24 Oct 2025 14:24:49 -0500 Subject: [PATCH 8/8] Also mention PSF staff as a potential PSRT pre-req --- peps/pep-0811.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst index 7bab67ef4f1..7bd52938d53 100644 --- a/peps/pep-0811.rst +++ b/peps/pep-0811.rst @@ -154,8 +154,8 @@ 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 or triagers and must be `proposed to -and accepted`_ by the Steering Council. +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.