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.

Every six months the Steering Council will receive a report of inactive PSRT members 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 six months since the last report was generated. The Steering Council may remove members of the PSRT with a simple vote.

Release Managers must be members of the PSRT for the duration of their term. Steering Council members and the release team experts may join the PSRT if they wish. All of these members may remain in the PSRT regardless of inactivity in vulnerability reports. When a member leaves these roles, their PSRT membership becomes a regular membership subject to the inactivity policy above. PSRT admins are not exempt from the inactivity policy and are included in the report of inactive members.

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 [email protected]. 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.

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.

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).

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 PSRT bot. 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.

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.

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 CVSSv4 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:

git clone https://github.com/python/cpython-ghsa-abcd-efgh-ijkl.git
cd cpython-ghsa-abcd-efgh-ijkl
git checkout -b advisory-fix-1

# (develop a fix)

git add ...
git commit -m "Fix"
git push origin advisory-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 type-security label.

To quickly pull a patch file from a GHSA pull request, you can append .patch to the pull request URL, like so:

curl https://github.com/python/cpython-ghsa-abcd-efgh-ijkl/pull/1.patch \
     --output ghsa-abcd-efgh-ijkl.patch

This patch can then be applied and pushed to the public GitHub repository:

git remote -v
origin    ssh://[email protected]/.../cpython (fetch)
origin    ssh://[email protected]/.../cpython (fetch)

git checkout -b branch-name
git apply ./ghsa-abcd-efgh-ijkl.patch
git push origin branch-name

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 advisory template, 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 type-security and release-blocker 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.

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}