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 peopleinvolved in the remediation of the vulnerability at hand.

The historical approach to collaboration on patch development was to manuallyadd GitHub users to a privatepython/psrt repositorywhich is a mirror of thepython/cpython repository.This approach didn’t allow filtering particular collaborators for specificvulnerabilities, meaning all collaborators had access to all reports and patches.

This manual process discouraged bringing on core developers outsidethe 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 happenin the open. Instead, most work occurs privately by a trusted group to limitaccess to undisclosed vulnerability reports. Given the sensitive nature of thiswork, it appears opaque from the outside, and it’s difficult to get started as anewcomer 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 reportsand 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 theincident or report continues moving towards a resolved state. This is especiallyan issue in the context of a mailing list, where it’s difficult to know whetheran issue is being responded to by someone else already or whether yourdetermination on a report is the same as others within the PSRT.

Ideally, similar to issues, pull requests, and PEPs, one defined personwould be responsible for moving the mitigation task forward to completion.This allows that person tocontribute and make decisions on the task without fear of “stepping on toes”.

Aligning with vulnerability disclosure timelines

Vulnerability reporting best practicesrecommend a 90 daytimeline between the initial disclosure and when a report is made publicto balance the needs of users, the project, and the reporter.Many vulnerability reporting organizations already use this timelineand will disclose vulnerabilities publicly even if the project doesn’tcreate their own mitigation.

To avoid reports getting stuck, forgotten, or published publicly without aremediation this PEP recommends aligning to the 90 days between initialdisclosure 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 todecide who should be admitted, but there must be a system responsible forevaluating PSRT membership.

This PEP proposes limiting PSRT membership only to active coordinatorsof 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 additionalrisk without any additional benefit to projects by having reports beingtriaged and coordinated.

Using GitHub Security Advisories (GHSA)

This PEP proposes adopting GitHub Security Advisories as thesystem to accept vulnerability reports due to its tight integrationwith 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 avulnerability reporting and management platform:

• Managing GitHub teams and accounts as “collaborators” per-reportrather 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 severityfor 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 andcreating comments on a GHSA report.

These missing features have been reported to GitHub and none are blockingthe adoption of GHSA. Some work will need to be done to work around thelack of a complete API for the GHSA feature.

PSRT Membership Policy

The PSRT will run nominationssimilar to core team nominations, wherea nomination of a new member is brought to the PSRT by an existing PSRT memberand then that nomination is voted on by existing PSRT members. New membersare 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 ofexisting PSRT members that is open for one week and is not vetoed by theSteering Council.

A list of PSRT members will be published publicly and kept up-to-date by PSRTadmins.

Once per year the Steering Council will receive a report of inactive members ofthe 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 avulnerability 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 Councilmember may remain in the PSRT regardless of inactivity in vulnerability reports.

This PEP proposes removing all members from the PSRT who haven’t been activein 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, thiswould reduce the PSRT membership size to ~15 members from ~30.

Responsibilities of PSRT members

The responsibilities of PSRT members will be documented publicly in thePython Developer’s Guide, so prospective members know what to expect beforeapplying to join the PSRT. These responsibilities include:

• Being knowledgeable about typical software vulnerability report handlingprocesses, 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 colleaguesor publicly deploying unpublished mitigations or patches ahead of the advisorypublication date.
• Acting as a “Coordinator” of vulnerability reports that are submittedto projects. A coordinator’s responsibility is to move a report through the PSRTprocess to a “finished” state, either rejected or as a published advisory andmitigation, within the industry standard timeline of 90 days.
• As a Coordinator, involving relevant core team members or triagers wherenecessary to make a determination whether a report is a vulnerability anddeveloping a patch. Coordinators areencouraged to involve members ofthe core team to make the best decision for each report rather than workingin isolation.
• As a Coordinator, calculating the severity using CVSS and authoring advisoriesto be shared onsecurity-announce@python.org. These advisories are usedfor CVE records by the PSF CVE Numbering Authority.
• Coordinators that can no longer move a report forwards for any reason mustdelegate 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 teampython/psrt as thecanonical list of PSRT members and aligning the mailing list and Discord to matchinstead of maintaining each separately. Process documentation will be created toensure changes to membership are consistent across these three channels asmembers are added and removed.

This PEP proposes adopting GitHub Security Advisories as the system wherevulnerability reports per project are handled. GHSA will be enabled forrelevant repositories and linked to directly from the top-level PSRTpage on python.org and project security policies.

Along with responsibilities the PSRT process for handling vulnerabilityreports using GHSA, such as how to assign a Coordinator and calculatingseverity, will be added to thePython Developer’s Guide.

Adopting GHSAs will coincide with disabling thepython/psrt privaterepository (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

Thesecurity@python.org mailing list covers more than CPython and pip,like security reports for thepython.org or related websitesand as a general hotline for Python ecosystem-related security issues.Maintaining the mailing list can also be used as a “fall-back” in casethe vulnerability reporting platform changes in the future.

For this reason, the mailing list and PSRT GPG key will continue to functionand be monitored, but reporters will be directed to individual project GitHubSecurity 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 therearen’t an abundance of opportunities to “prove” activity on the scale of months.For this reason along with aligning with existing yearly schedules for theSteering Council, a yearly pruning was recommended.