The Python Security Response Team (PSRT) is responsible for handling vulnerability reports for CPython and pip.
To report security issues:
https://www.python.org/dev/security/
Members
The PSRT publishes a full list of members and admins, included in the table below:
Name
GitHub username
Notes
Adam Turner
AA-Turner
Barry Warsaw
warsaw
Admin
Bénédikt Tran
picnixz
Benjamin Peterson
benjaminp
Damian Shaw
notatallshaw
Donald Stufft
dstufft
Dustin Ingram
di
Ee Durbin
ewdurbin
Admin
Emma Smith
emmatyping
Glyph Lefkowitz
glyph
Gregory P. Smith
gpshead
Hugo van Kemenade
hugovk
Release Manager
Jacob Coffee
JacobCoffee
Jelle Zijlstra
JelleZijlstra
Kushal Das
kushaldas
Kirill Podoprigora
eclips4
Larry Hastings
larryhastings
Łukasz Langa
ambv
Release Manager
Ned Deily
ned-deily
Admin, Release Manager
Pablo Galindo Salgado
pablogsal
Release Manager
Paul McMillan
paulmcmillan
Petr Viktorin
encukou
Pradyun Gedam
pradyunsg
Savannah Ostrowski
savannahostrowski
Release Manager
Serhiy Storchaka
serhiy-storchaka
Seth Larson
sethmlarson
Admin
Stan Ulbrych
StanFromIreland
Admin
Steve Dower
zooba
Release Manager
Thomas Wouters
Yhg1s
Release Manager
Tim Peters
tim-one
William Woodruff
woodruffw
See also the
.
How can I join the PSRT?
Anyone can join the PSRT following a nomination process
similar to core team nominations
. Nomination for a new member is brought to the PSRT by an existing PSRT member and then this nomination is voted on by existing PSRT members. The nomination succeeds if the nomination receives at least two-thirds positive votes from a vote of existing PSRT members that is open for one week and not vetoed by the Steering Council.
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 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.
Responsibilities of PSRT members
Below are the responsibilities of PSRT members:
Being knowledgeable about typical software vulnerability report handling processes, such as CVE IDs, patches, coordinated disclosure, embargoes.
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 CVSSv4 and authoring advisories to be shared on
. These advisories are used for CVE records by the
.
Coordinators that can no longer move a report forwards for any reason must delegate their Coordinator role to someone else in the PSRT.
Responsibilities of PSRT admins
PSRT members who are designated as admins by the Steering Council have the following additional responsibilities:
Triaging the [email protected] mailing list.
Managing PSRT membership access including the GitHub team, the mailing list, and Discord channel, 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.
Running nomination elections, including counting final votes and giving the Steering Council an opportunity to veto nominations via email.
Triaging a vulnerability report
PSRT members coordinate reports from when they are first submitted to a “finished” state. Finished states include marking a report as a “non-issue”, opening a public issue on GitHub, or a merged patch with an accompanying CVE and advisory to [email protected]. Reports should reach a finished state within 90 days of being received by the PSRT.
Reports enter the system through [email protected] or on a project GitHub Security Advisory (GHSA) ticketing system. For projects that use GHSA, reports to [email protected] should have reporters
re-open their report using GHSA
.
┌────────────────────────┐ │ Received a report... │ └──┬──────────────────┬──┘ │ │ ┌────────────▼──────────────┐ ┌─▼──────────┐ │ ..via [email protected] │ │ ..via GHSA │ └────────────┬──────────────┘ └─┬──────────┘ │ │ ┌────────────▼──────────────┐ │ │ PSRT admin reviews email │ │ └───┬───────────────────┬───┘ │ │ │ │ ┌───▼────┐ ┌────▼───┐ │ │ Reject │ │ Accept │ │ └────────┘ └────┬───┘ │ │ │ ┌───────────────────────▼───┐ │ │ PSRT asks reporter to │ │ │ open via GHSA │ │ └────────────┬──────────────┘ │ │ │ ┌──▼──────────────────▼──┐ │ GHSA in state 'Triage' │ └────────────────────────┘ New report in GitHub Security Advisories (GHSA)
Once a report is in GHSA, a “Coordinator” must be assigned to be responsible for moving the report through the process. The “Coordinator” role is assigned using a “Credit” in a GHSA ticket (Select Edit > Credit > Add a GitHub username and the ‘Coordinator’ role).
Important
Assigning the “Coordinator” role to each GHSA ticket is important, as this metadata records whether a PSRT member is
to avoid being removed due to inactivity.
If a GHSA ticket is idle for three days without a coordinator assigned, a PSRT member who is not a Release Manager or Steering Council member will be automatically assigned as coordinator by the
. If a coordinator can’t complete the process they must find a replacement coordinator in the PSRT and re-assign the GHSA ticket.
┌────────────────────────┐ │ GHSA in state 'Triage' │ └─┬────────────────────┬─┘ │ │ ┌──────────────────▼─────────┐ ┌────────▼───────────────────┐ │ │ │ After 3 days idle, │ │ PSRT member volunteers │ │ Coordinator is assigned │ │ as Coordinator │ │ automatically by bot │ └──────────────────┬─────────┘ └────────┬───────────────────┘ │ │ ┌─▼────────────────────▼─┐ │ GHSA update 'Credit' │ │ field to Coordinator │ └────────────┬───────────┘ │ ┌────────────▼────────────┐ │ Coordinator determines │ ┌───┤ whether report... ┼──┐ │ └────────────┬────────────┘ │ │ │ │ ┌────────────▼──┐ ┌───────────▼───────────┐ ┌─▼─────────────┐ │..is an invalid│ │ ..is a bug, but not │ │..is a security│ │ or non-issue │ │ security relevant │ │ issue │ └────────────┬──┘ └───────────┬───────────┘ └─┬─────────────┘ │ │ │ │ ┌────────────▼───────────┐ │ │ │ Coordinator opens a │ │ │ │ public GitHub issue │ │ │ └─┬──────────────────────┘ │ │ │ │ ┌──────────▼─────▼───────┐ ┌────────────▼───────────┐ │ Close the GHSA ticket │ │ GHSA in state 'Draft' │ └────────────────────────┘ └────────────────────────┘ Determining whether a report is a vulnerability
The coordinator will make a determination about a report, either marking the ticket as a non-issue, as an issue that isn’t a security vulnerability, or as a security vulnerability. If the Coordinator needs help from core team experts in making the determination, the experts may be added as ‘Collaborators’ to the GHSA ticket. Accepted security vulnerabilities will be moved to the ‘Draft’ state in GHSA. Only repository admins can accept advisories; however, PSRT members may accept reports through the PSRT bot by prepending [ACCEPTED] to the GHSA’s title.
If the report isn’t a vulnerability, coordinators close the GHSA ticket after optionally opening a public GitHub issue. Note that reporters often will not open a GitHub issue on their own, as there is no longer an incentive for them to do so without a CVE being assigned. Similarly to accepting, only repository admins can close advisories; however, PSRT members may close reports through the PSRT bot by prepending [CLOSED] (for regular bugs), [INVALID] (for spam), [DUPLICATE] (for duplicates), or [COMPLETED] (for completed tickets where an advisory has been issued) to the GHSA’s title.
Remediating a vulnerability report
Once a report has been accepted as a vulnerability, the remediation development process begins. Coordinators move the GHSA ticket to a ‘Draft’ state using the green Accept as Draft button (repository admins) or the PSRT bot’s [ACCEPTED] title tag. Once in this state, the PSRT bot will automatically assign a CVE ID from the Python Software Foundation CVE Numbering Authority and create a temporary private fork.
Once a vulnerability has been accepted there are three things the Coordinator must prepare before sending an advisory and closing the GHSA ticket:
Severity calculated using CVSSv4.
Pull request containing the fix merged with a public GitHub issue.
Advisory title and short description of the vulnerability.
Severity scoring
Severity of a vulnerability can be difficult to assess objectively due to not knowing how software is used in all situations. Severity is calculated from expected or known use, not from worst-case hypothetical scenarios.
The PSRT and PSF CNA use
for calculating the severity of a vulnerability. GHSA tickets provide a CVSSv4 calculator within the ticket UI. Note that GitHub defaults to CVSSv3, change the scoring algorithm to CVSSv4 before scoring in the ticket UI. As with all aspects of PSRT operations, coordinators are encouraged to ask for help in calculating a severity from other PSRT members.
Developing a patch privately
Patch development can begin once a report has been accepted, as the PSRT bot will automatically create a temporary private fork for the advisory. The fork can also be created earlier by repository admins or reporters by selecting the Start a temporary private fork button within the GHSA ticket. Note that due to the size of Git repositories, this fork repository may take several minutes to create. Once the fork has been created any PSRT member or GHSA collaborator can clone the fork and develop a fix and push a branch:
gitclonehttps://github.com/python/cpython-ghsa-abcd-efgh-ijkl.git cdcpython-ghsa-abcd-efgh-ijkl gitcheckout-badvisory-fix-1 # (develop a fix) gitadd... gitcommit-m"Fix" gitpushoriginadvisory-fix-1 From here a pull request can be opened within the GHSA ticket to be reviewed privately. The coordinator can add core team experts as collaborators as necessary to the GHSA to develop the patch and to review the patch if the expertise for patch development or review aren’t available within PSRT. Coordinators are not necessarily responsible for developing patches themselves: only with seeing that a patch is developed in a timely fashion by involving experts as necessary.
Once the patch has been approved a public GitHub issue and pull request can be opened. Generate a blurb in the category Security for the public pull request. Public issues and pull requests for security fixes should use the
label.
To quickly pull a patch file from a GHSA pull request, you can append .patch to the pull request URL, like so:
curlhttps://github.com/python/cpython-ghsa-abcd-efgh-ijkl/pull/1.patch\--outputghsa-abcd-efgh-ijkl.patch This patch can then be applied and pushed to the public GitHub repository:
gitremote-v originssh://[email protected]/.../cpython(fetch) originssh://[email protected]/.../cpython(fetch) gitcheckout-bbranch-name gitapply./ghsa-abcd-efgh-ijkl.patch gitpushoriginbranch-name Important
CPython’s backport infrastructure is used for tracking backported patches. Use one GitHub issue per CVE to accurately track backports of vulnerability fixes. For new CVEs, even when related to a previous issue, open a new GitHub issue to accurately track fixed versions.
Important
Repository admins should not select the green Publish advisory or Merge pull request buttons within GHSA. Advisories are published to the mailing list, and the Merge pull request button within GHSA bypasses all continuous integration and branch protection steps. Use a public pull request instead.
Publishing an advisory
Once the vulnerability fix has been merged into the main branch via a public GitHub pull request, an advisory must be published. The advisory requires the severity, a title, and a short description of the vulnerable module, functions, behavior and fix. This short description can optionally include mitigation steps if applying the patch isn’t the only way to mitigate the vulnerability.
Send an email to the [email protected] mailing list using the
, including title, severity, description.
The advisory email will be received by PSF CVE Numbering Authority operators and used to publish a CVE record.
Begin the backporting process for all Python branches still receiving security updates. Add the
and
labels to each backport pull request so that release managers can find them prior to releasing.
After an advisory email is sent, the GHSA ticket can be closed. As only repository admins can close advisories directly, PSRT members can prepend [COMPLETED] to the GHSA’s title and the PSRT bot will close the ticket.
The PSRT bot
The
is a GitHub App that automates parts of the GHSA workflow described above. GitHub only allows repository admins to modify security advisories, so the bot enables any PSRT member to move a report through the process using title tags.
The bot runs hourly (or by manual dispatch) and for each open GHSA ticket:
Adds the PSRT GitHub team as collaborators, giving members access to new reports.
Moves tickets from the ‘Triage’ to the ‘Draft’ state when the title contains the [ACCEPTED] tag.
Closes tickets when the title contains one of the closing tags ([CLOSED], [INVALID], [DUPLICATE], or [COMPLETED]).
For accepted (‘Draft’) tickets, creates the temporary private fork if one doesn’t already exist, and reserves a CVE ID.
Tags are case-insensitive and can appear anywhere in the title, though for visibility they are prepended.
Handling code signing certificate reports
Python signs binaries using Azure Trusted Signing and Apple Developer ID certificates. If a code signing certificate is reported as “compromised” or “malware signed with certificate”, the Python Security Response Team must request the following information from the reporter:
Checksum(s) of binaries signed by certificate.
Signature(s) of binaries signed by certificate.
To avoid unnecessary user confusion and churn around revoking code signing certificates, any reports must be verifiable independently by the PSRT before taking destructive actions, such as revoking certificates. With this information the PSRT can take investigative steps to verify the report, such as:
Downloading and checking artifacts from the associated Azure Pipelines executions against the reported list of checksums.
Verifying the validity of the signatures.
have contained signatures that purported to be from Python code signing certificates, but were not valid.
Checking the Azure Pipelines and Azure Trusted Signing audit logs for signs of compromise.
If any signs of compromise or incorrectly signed binaries are discovered by the PSRT, only then will certificates be revoked and an advisory published. If compromise is reported, the following non-destructive actions can be taken by the PSRT without verifying the reported information as a precaution, if relevant:
Rotating secrets associated with code signing (TrustedSigningSecret for Azure Trusted Publishing).
Resetting passwords for accounts with access to signing certificates.
Template responses
These template responses should be used as guidance for messaging in various points in the process above. They are not required to be sent as-is, please feel free to adapt them as needed for the current context.
Submit using GitHub Security Advisories
Thanks for submitting this report. We use GitHub Security Advisories for triaging vulnerability reports, please review our security policy before submitting: https://devguide.python.org/security/policy/ Then submit your report here: https://github.com/python/cpython/security/advisories/new Rejecting a vulnerability report
Thanks for your report. We've determined that the report doesn't constitute a vulnerability. Let us know if you disagree with this determination. If you are interested in working on this further, you can optionally open a public issue on GitHub. Rejecting a duplicate report
Thanks for your report. We've determined that this submission is a duplicate of an issue that is already being tracked internally. Please refrain from public disclosure until the issue has been resolved. Advisory email
Title: [{CVE-YYYY-XXXX}] {title} There is a {LOW, MEDIUM, HIGH, CRITICAL} severity vulnerability affecting {project}. {description} Please see the linked CVE ID for the latest information on affected versions: * https://www.cve.org/CVERecord?id={CVE-YYYY-XXXX} * {pull request URL} Members emeritus
Members who have previously served on the PSRT.
Name
GitHub username
Notes
Anthony Baxter
Release Manager
Christian Heimes
tiran
Georg Brandl
birkenfeld
Huzaifa Sidhpurwala
Jesse Noller
Mark Hammond
mhammond
Nam Nguyen
Neal Norwitz
Trent Mick