OSS Security RFI, Guide to become a CNA, and PEP 639

Published 2023-11-07 by Seth Larson
Reading time: 3 minutes

This critical role would not be possible without funding from the OpenSSF Alpha-Omega Project. Massive thank-you to Alpha-Omega for investing in the security of the Python ecosystem!

The past week has been almost exclusively writing for me! Here's a rundown on what I've been writing about:

Request for Information (RFI) on Open Source Software Security

As many folks in the Open Source security space are aware of, the deadline for the US Government RFI submissions (November 9th, 2023) is fast-approaching! I've been working with my colleagues at the Python Software Foundation to draft a response to the RFI over the past months now. The past few weeks have had a lot of time spent on collaborating and refining our response to the point where I am quite proud of it now.

If this is your first time hearing of the RFI, the Linux Foundation and Tidelift have both covered the RFI, what it is and why it's an exciting development for open source.

The Python Software Foundation's response to the RFI is about capturing what we believe is important regarding the US governments approach to securing open source software. Whatever gets done by the US government is likely to have huge implications for everyone maintaining and consuming open source software, so it's critical that policy and decisions are made with sustainability in mind.

I'm honored to be a part of this and to represent so many Pythonistas in my work both for this RFI and every day as Security Developer-in-Residence. 💜

Becoming a CVE Numbering Authority as an Open Source project

Throughout the process of joining the CVE Numbering Authority program for the Python Software Foundation I noted down all the steps and requirements to become a CNA. I transformed these notes into a digestible document that's specifically written for Open Source projects and organizations. This document has had extensive review from both the OpenSSF Vulnerability Disclosures Working Group and multiple CVE Working Groups.

This guide has recently been published under the OpenSSF Vulnerability Disclosures WG GitHub repository. I'm now in the process of drafting an announcement blog post for the OpenSSF blog.

PEP 639 - Licensing clarity in packaging metadata

I've raised my hand to help PEP 639 make its way to acceptance as this PEP was one that I noted as being important for Software Bill-of-Materials being adoptable for the Python packaging ecosystem. I wanted to also thank Karolina Surma who works on Python packaging at Red Hat for joining as a coauthor of PEP 639 as well and is already making use of the PEP. Thanks so much!

The gist of this PEP is to move package tooling and maintainers to adopt SPDX License IDs and expressions in order to more accurately represent the licenses of Python packages. Previous standards would use an open-ended string License field along with License :: * trove classifiers. This approach isn't able to capture all licensing situations (such as 'MIT OR GPL-2.0-only') and especially struggles with license revisions.

Due to the inability to capture these more complication situations, it often meant that tooling consuming Python packages would need to look at LICENSE, NOTICE, or COPYING files and do their own text detection in order to have an accurate view of the licensing situation. Choosing a license is one of the more important decisions before releasing software into the wild, so ensuring that that choice is unambiguous is very important!

Other Items

That's all for this week! 👋 If you're interested in more you can read next week's report or last week's report.

Thanks for reading! ♡ Did you find this article helpful and want more content like it? Get notified of new posts by subscribing to the RSS feed or the email newsletter.

This work is licensed under CC BY-SA 4.0