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.

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.

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.

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.

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.

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.