The Python Software Foundation submitted a response to the US Government RFI on "Open-Source Software Security: Areas of Long-Term Focus and Prioritization" with the help of the Security Developer-in-Residence and other staff. The full RFI response can be downloaded here.
Seth primarily authored the sections on memory safety, build provenance and reproducibility, and non-technical solutions to supply chain challenges.
When the Python Software Foundation became a CVE Numbering Authority there wasn't much already published support answering the questions we had about becoming a CNA as an Open Source foundation and project. Organizations like the PSF aren't structured like typical businesses and instead are made of very few staff and many volunteer maintainers. This unique situation led to us wanting to learn more and to not have what we learned be redone for other Open Source projects looking to become CNAs themselves.
Towards preserving that knowledge I drafted a guide alongside contributions from the OpenSSF Vulnerability Disclosures working group and multiple CVE working groups. This guide was published this month alongside an announcement blog post to the OpenSSF blog coauthored with Art Manion of the CVE Board.
Continuing to make improvements to the CPython release process, I've put together a proposal for Software Bill of Materials being shipped with CPython releases. CPython uses many different dependencies and those dependencies can vary depending on which artifact is being used (source, Windows installer, macOS installer, etc). The proposal has been positively received by core developers so far.
I've submitted the initial PR for keeping a SBOM up-to-date for vendored dependencies in the CPython source code and will be submitted more PRs for other dependencies and then bringing them all together during the CPython release and exposing the files for download.
To avoid putting more stress on CPython core developers and release managers after SBOMs begin to be published (thus making subcomponents and their vulnerabilities more visible) I've also started investigating how VEX can be used with SBOM tooling like Grype in order to automatically take VEX statements into account during SBOM scanning. This process would mean that CVEs which CPython isn't affected by wouldn't show up as false-positives within a consumers scanning results.
- Authored weekly reports and shared on social media:
- Security Developer-in-Residence role and all of my historical work was covered in an article by The New Stack.
- Received a shoutout from Carol Willing during her keynote at PyCon Sweden.
- I became a Python triager thanks to the recommendation by Hugo van Kemenade in order to be on the
CODEOWNERSlist for CPython SBOM tooling and resources. - Submitted PR to move CPython's source and documentation builds to GitHub Actions.
- Submitted multiple PRs to CPython to pin the
cpython_autoconfcontainer to its SHA256 manifest. This container is used to ensureautoconfis consistent across all contributors. I plan to usemake regen-configureas a part of the CPython release process. - Discussed "affectedness" based on modules and functions for the PyPA Advisory database. Having this information would allow vulnerability scanning tools like pip-audit to only associate a vulnerability with a project if the affected module or function is used by the project. In theory this information will reduce the amount of false-positives when a vulnerability only affects a single feature rather than the entire project.