This month I focused on Python's vulnerability data infrastructure, both for the CVE Numbering Authority and the Open Source Vulnerability database. I authored a blog post about the results of this work and how it works.
Before these improvements, most of the work to keep vulnerability records up-to-date was done manually. This worked okay since the number of vulnerabilities that the Python Software Foundation CNA emitted each year was ~10. However, if we plan to scale out our CNA scope or to rely on less full-time staffing then adding automation will be required.
I've automated three aspects of our vulnerability data infrastructure:
- Discovery of all fixed versions of CPython relying on metadata from CPython's backport infrastructure.
- Creation of new Open Source Vulnerability (OSV) records from CVE records.
- Keeping CVE and OSV updated as security fixes are backported over time.
I published three advisories and vulnerability records using the new infrastructure: CVE-2024-5642, CVE-2024-4032, and CVE-2024-0397.
I'm in the process of authoring a PEP to codify the membership policy for the PSRT. I already have a sponsor for the PEP and will be submitting it next week after the first round of review.
The PEP provides structure to the historically informal process around membership for the PSRT which is important due to the sensitive nature of the vulnerability reports that are handled by the PSRT. The proposal ensures:
- Need-to-know basis for who is handling vulnerability reports.
- Definition of who should be a PSRT member (Active and prominent people in the Python community, Steering Council members, and Release Managers).
- Python Steering Council oversight into the PSRT operations and arbiter of membership.
- Process for removal of inactive members on a yearly cadence to synchronize with Steering Council elections.
Upon acceptance, a one-time removal of inactive members will occur to reduce the list of PSRT members by approximately half.
I'm also working on migrating the PSRT from using a mailing list for tracking reports to using GitHub Security Advisories in order to decrease mean-time to resolution, enabling individuals to carry a vulnerability report end-to-end via assignees, and allowing for increased collaboration between PSRT members and other core developers to speed up the merging of fixes.
We ran into issues in the past year adopting GHSA due to a lack of features allowing automation. We've decided that after a year of waiting for the situation to improve we're moving forward and building some of these features ourselves, including "default collaborative teams" and working around a lack of webhooks for automation support.
PyPI announced Trusted Publisher support in April 2023 and has seen over 13,000 projects voluntarily adopt the feature.
I've authored a new guide for the OpenSSF Securing Software Repositories WG that describes the why and how of Trusted Publishers in addition to a set of design decisions and gotchas discovered by implementations like PyPI and Rubygems.org.
The guide is nearing completion and is soliciting its final round of feedback from the group before being published to the working group and the OpenSSF blog.
- Published a write-up of PyCon US 2024 as the Security Developer-in-Residence.
- Contributed all accomplishments to the PSF Newsletter for Q2.
- Continued mentorship of Google Summer of Code contributor. Nate is making excellent progress on adopting the Hardened Compiler Options for C/C++ guide to CPython.
- Authored the Python Language Summit blog post on discussions of CPython development model post-xz.
- Reviewing PEP 740 (publish provenance for PyPI) and other work for generating publish provenance from William Woodruff.
- Triaging reports to the PSRT.