Members¶

The PSRT publishes a fulllist of members and admins, included in the table below:

Vulnerability report triage¶

Vulnerability reports are sent to one of two locations,the long-standingsecurity@python.org mailing listor using the private vulnerability reporting featureof GitHub Security Advisories (GHSA).

For reports sent tosecurity@python.org, a PSRT adminwill triage the report and if the report seems plausible(that is, not spam and for the correct project) will reply withinstructions on how to report the vulnerability on GitHub.

If the reporter doesn’t want to use GitHub’s Security Advisories featurethen the PSRT admins can create a draft report on behalf of the reporter.

Coordinating a vulnerability report¶

Each report will have a member of the PSRT assigned as the “coordinator”.The coordinator will be responsible for following the below process andwill be publicly credited on vulnerability records post-publication.

If a coordinator can’t complete the process for any reason (time obligation,vacation, etc.) they must find a replacement coordinator in the PSRTand reassign the vulnerability report appropriately.

Coordinators are expected to collaborate with other PSRT and core team memberswhen needed for guidance on whether the report is an actual vulnerability,severity, advisory text, and fixes.

The vulnerability coordination process is:

• Coordinator will determine whether the report constitutes a vulnerability. If the report isn’t a vulnerability,the reporter should be notified appropriately. Close the GHSA report, the report can be reopened ifsufficient evidence is later obtained that the report is a vulnerability.

• After a vulnerability report is accepted, a Common Vulnerabilities and Exposures (CVE) ID must be assigned. If this is not doneautomatically, then a CVE ID can be obtained by the coordinator sending an email tocna@python.org.No details about the vulnerability report need to be shared with the PSF CVE Numbering Authority (CNA) for a CVE ID to be reserved.

• If the report is a vulnerability, the coordinator will determine the severity of the vulnerability. Severity is one of:Low,Medium,High, andCritical. Coordinators can use their knowledge of the code, how the code is likely used,or another mechanism like Common Vulnerability Scoring System (CVSS) for determining a severity. Add this information to the GitHub Security Advisory.

• Once a CVE ID is assigned, the coordinator will share the acceptance and CVE ID with the reporter.Use this CVE ID for referencing the vulnerability. The coordinator will ask the reporterif the reporter would like to be credited publicly for the report and if so, how they would like to be credited.Add this information to the GitHub Security Advisory.

• The coordinator authors the vulnerability advisory text. The advisory must include the following information:

  • Title should be a brief description of the vulnerability and affected component(for example, “Buffer over-read in SSLContext.set_npn_protocols()”)

  • Short description of the vulnerability, impact, and the conditions where the affected component is vulnerable, if applicable.

  • Affected versions. This could be “all versions”, but if the vulnerability exists in a new featureor removed feature then this could be different. Include versions that are end-of-life in this calculation(for example, “Python 3.9 and earlier”, “Python 3.10 and later”, “all versions of Python”).

  • Affected components and APIs. The module, function, class, or method must be specified so users cansearch their codebase for usage. For issues affecting the entire project, this can be omitted.

  • Mitigations for the vulnerability beyond upgrading to a fixed version, if applicable.

  This can all be done within the GitHub Security Advisory UI for easier collaboration between reporter and coordinator.

• The coordinator determines the fix approach and who will provide a fix.Some reporters are willing to provide or collaborate to create a fix,otherwise relevant core team members can be invited to collaborate bythe coordinator.

  • ForLow andMedium severity vulnerabilities it is acceptableto develop a fix in public.The pull request must be marked with thesecurity andrelease-blockerlabels so that a release is not created without including the fix.

  • ForHigh andCritical severity vulnerabilities the fix must bedeveloped privately using GitHub Security Advisories’ “Private Forks” feature.Core team members can be added to the GitHub Security Advisory via “collaborators”to work on the fix together. Once a fix is approved privately and tested,a public issue and pull request can be created withthesecurity andrelease-blocker labels.

• Once the pull request is merged the advisory can be published. The coordinator will send the advisory by emailtosecurity-announce@python.org using the below template. Backport labels must be added as appropriate.After the advisory is published a CVE record can be created.

Handling code signing certificate reports¶

Python signs binaries using Azure Trusted Signing and Apple Developer IDcertificates. If a code signing certificate is reported as “compromised” or“malware signed with certificate”, the Python Security Response Team mustrequest 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 signingcertificates, any reportsmust be verifiable independently by the PSRT beforetaking destructive actions, such as revoking certificates. With thisinformation the PSRT can take investigative steps to verify the report, such as:

• Downloading and checking artifacts from the associated Azure Pipelinesexecutions against the reported list of checksums.

• Verifying the validity of the signatures.Past reports have contained signatures thatpurported to be from Python code signing certificates, but were not valid.

• Checking the Azure Pipelines and Azure Trusted Signing audit logs for signs ofcompromise.

If any signs of compromise or incorrectly signed binaries are discovered by thePSRT, only then will certificates be revoked and an advisory published.If compromise is reported, the following non-destructive actions can be taken bythe PSRT without verifying the reported information as a precaution, ifrelevant:

• Rotating secrets associated with code signing (TrustedSigningSecret forAzure Trusted Publishing).

• Resetting passwords for accounts with access to signing certificates.

Template responses¶

These template responses should be used as guidance for messagingin 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.

Directing to GitHub Security Advisories:

Thanks for submitting this report.We use GitHub Security Advisories for triaging vulnerability reports,are you able to submit your report directly to GitHub?https://github.com/python/cpython/security/advisories/newIf you're unable to submit a report to GitHub (due to not having a GitHubaccount or something else) let me know and I will create a GitHub SecurityAdvisory on your behalf, although you won't be able to participate directlyin discussions.

Rejecting a vulnerability report:

Thanks for your report. We've determined that the report doesn't constitutea vulnerability. Let us know if you disagree with this determination.If you are interested in working on this further, you can optionally open apublic issue on GitHub.

Accepting a vulnerability report:

Thanks for your report. We've determined that the reportis a vulnerability. We've assigned {CVE-YYYY-XXXX} and determineda severity of {Low,Medium,High,Critical}. Let us know if you disagreewith the determined severity.If you would like to be publicly credited for this vulnerability as thereporter, please indicate that, along with how you would like to becredited (name or organization).Please keep this vulnerability report private until we've publishedan advisory to ``security-announce@python.org``.

Advisory email:

Title: [{CVE-YYYY-XXXX}] {title}There is a {LOW, MEDIUM, HIGH, CRITICAL} severity vulnerabilityaffecting {project}.{description}Please see the linked CVE ID for the latest information onaffected versions:* https://www.cve.org/CVERecord?id={CVE-YYYY-XXXX}* {pull request URL}