Thursday, February 08, 2024

Software Bill-of-Materials documents are now available for CPython

Our Security Developer-in-Residence, Seth Larson, has been working to improve the management of vulnerabilities for Python users. Seth has championed progress on this goal in a variety of areas:

With the release of CPython 3.12.2, the next step of the Python Software Foundation’s vulnerability management strategy is now available in the form of Software Bill-of-Materials (SBOM) documents for CPython source releases. The documents are available for download in their own column labeled “SBOM” in the “Files” table on the release page. User documentation and a getting started guide for CPython SBOMs is available on

These documents are relatively new but have been tested with multiple tools that accept SPDX SBOM documents. Please report any feedback on the SBOM to the CPython issue tracker.

What is a Software Bill-of-Materials (SBOM)?

Software Bill-of-Materials are machine-readable documents using an ecosystem-independent format like SPDX or CycloneDX to describe what a piece of software is made of and how each component within the software relates to other components. There are multiple use-cases for SBOMs, but for CPython we primarily focused on software supply chain and vulnerability management.

Many vulnerability scanning tools support passing an SBOM document as input to provide a comprehensive scan for software vulnerabilities without needing to rely on fallible software discovery. This means there’s less chances for vulnerabilities to be missed by scanners.

There are existing tools for automatically creating SBOMs for software, but SBOMs which aren’t accurate are sometimes more dangerous than having no SBOM due to causing a false sense of security. This is especially true for complex pieces of software or projects which exist outside of package ecosystems, both of which apply to CPython and make generating an SBOM difficult. For this reason the content of CPython SBOMs is curated by hand on first pass to ensure accuracy and completeness and then automated to track updates as the software changes.

SBOM documents are becoming a requirement for compliance in multiple areas and industries. In order to meet those requirements we are providing a comprehensive and accurate SBOM for CPython that will provide assurance for Python users.

What is included in CPython SBOMs?

CPython SBOMs use the SPDX SBOM standard. SBOM documents include a description of the contained software, including all of its dependencies. Information in CPython SBOMs includes:

  • Names and versions of all software components
  • Software identifiers (like CPE and Package URLs)
  • Download URLs for source code with checksums
  • File names and content checksums
  • Dependency relationships between each component

CPython SBOMs satisfy the requirements listed in the NTIA Minimum Elements for a Software Bill of Materials. Software identifiers can be used for correlating software in use to vulnerability databases like the CVE database and Open Source Vulnerability database, typically done automatically using vulnerability scanning tools.

What isn’t included in CPython SBOMs?

Keep in mind that software libraries that you supply yourself to compile CPython, such as OpenSSL and zlib, are not included in the SBOMs for source artifacts.

This is due to these libraries not being included in source artifacts, so CPython users have a choice of which version and sources to use for these third-party libraries. Folks who are compiling CPython from source are responsible for tracking their own dependencies either in a separate SBOM document or by appending new entries to your local CPython SBOM.

CPython’s SBOMs don’t include licensing information for dependencies. See the CPython licensing page for licensing information.

What is coming next for CPython SBOMs?

This is only the beginning for CPython SBOMs, as mentioned above there are only SBOM documents published for source releases today. The CPython release managers also publish binary installers for Windows and macOS on a variety of distribution channels. These artifacts will need their own SBOM documents as they are compiled with software that’s typically not available on those platforms (e.g. OpenSSL).

There’s also more infrastructure needed to reduce noise and churn for Python users and Python Security Response Team members alike. Vulnerability EXchange (VEX) statements are a set of standards which allows software producers to signal to user tooling whether a piece of software in use is affected by a vulnerability, even for vulnerabilities affecting dependencies. This is an area of active development and is being explored alongside the OpenSSF Security Tooling Working Group.

The Security Developer-in-Residence role and this work is funded by a substantial investment from the OpenSSF Alpha-Omega Project. Thanks to Alpha-Omega for their support in improving the security posture of the entire Python ecosystem.The OpenSSF is a non-profit cross-industry collaboration that unifies security initiatives and brings together leaders to improve the security of open source software by building a broader community, targeted initiatives, and best practices.

Wednesday, February 07, 2024

Introducing PSF Grants Program Office Hours

In October 2023, we acknowledged the situation surrounding DjangoCon Africa and noted our intent to make ongoing improvements to the Grants Program. We also recognize that we are in a new world of hybrid programming since the onset of the pandemic which comes with different funding and cost challenges. One step we are taking to refresh the Grants Program (we’ll be reporting on other steps soon) is to establish PSF Grants Program Office Hours.

The office hours will be hosted on the Python Software Foundation Discord once a month at 2-3PM UTC (9AM Eastern) on the third Tuesday of the month. (Check what time that is for you.) We invite the Python community to join in to receive support for Grant-related questions and inquiries! If you have urgent or immediate questions related to the Grants Program, please email

Direct line of communication

As we sat down to address the challenges and issues raised around the Grants Program and how to better support the Python community, we came to realize that refreshing the program would not be an easy and quick task. We need a two-way communication channel dedicated to the topic of grants with the PSF Board, the Grants Working Group, the D&I Working Group, the Code of Conduct Working Group, and most importantly, our vibrant and diverse community.

We believe a direct line of communication between the PSF and the worldwide Python community is the best first step. In order to create that direct line, gather your feedback, and collaborate on the future of the program, we are establishing regular PSF Grants Program Office Hours!

What’s the goal?

There are a couple of goals we hope to accomplish with the Grants Program Office Hours. In the short term, we believe recurring time supporting communication between the community and the PSF is key. In other words, a place for folks to come with questions and ideas regarding the Grants Program, with an understanding that we don’t have it perfect yet. If we have the answer, or we can point you to the right resource - amazing! If we don’t, that’s an area we know needs more work and will be added to our “To Do.”

We hope to see the office hours evolve over time as we work through feedback and make updates to our process, documentation, and resources. In the long term, the PSF hopes Grants Program Office Hours will create a place for our community to ask questions about the Grants Program and for us to have (almost) all the answers. We’d like the office hours to continue to be a place where we receive feedback from the community and continuously improve what we can do for Pythonistas around the world.

PSF Grants Program Office Hour Hosts

The PSF Grants Program Office Hours will be hosted by members of the PSF Staff. This will change over time, but for now you can expect to see Laura Graves, Senior Accountant, and Marie Nordin, Community Communications Manager, hosting the sessions. When needed, other PSF staff members will sub in for Laura and Marie.  

This sounds great! How can I join?

The PSF Grants Program Office Hours will be a text-only chat based office hour hosted on the Python Software Foundation Discord at 2-3PM UTC (9AM Eastern) on the third Tuesday of the month. The server is moderated by PSF Staff and is locked in between office hour sessions. If you’re new to Discord, check out some Discord Basics to help you get started. And as always, if you have urgent or immediate questions related to the Grants Program, please email

Come prepared to the Office Hours with questions and shareable links to your Grant applications drafts in progress via Google docs, etherpad, pastebin, etc. We hope to see you there!

Wednesday, January 31, 2024

Kicking off 2024 strong, thanks to our community!

We are starting off the year feeling energized and supported, thanks to each of you who shared or donated to our year-end fundraiser and membership drive. We raised a whopping $43,000 through our PyCharm partnership with JetBrains–that’s more than double last year! With over 150 individual donations, new Supporting Memberships, and JetBrains’ generous partnership, we raised $134,175 total for our work supporting Python and the Python community! All in all, during the period of the fundraiser, we raised close to $200K, which includes donations from our sponsors, donations to our Fiscal Sponsorees, Membership renewals, and proceeds from the special replay of our Humble Bundle, thanks to No Starch Press.

Your generous support means we can confidently start 2024 by investing in our key goals for the year. These goals include:

  • Improving dialogue with the global community
  • Investing in community support
  • Creating more pathways for technical contributions

We rely on community investment–of money, but also time, energy, ideas, and enthusiasm–to reach each of these goals. 

Supporting Membership is a great way for the community to invest in the PSF’s work. It was exciting to see many new Supporting Members made use of our sliding scale rate option to become Members. Welcome aboard, new members, and thank you for joining us! We’re looking forward to having your voice take part in the PSF’s future.

Because the PSF doesn’t buy lists or ads, your help in sharing our fundraiser with your networks makes a big difference, and we really appreciate how many of you took the extra time to help promote it. We’re excited about where 2024 will take us together, and as always, we’d love to hear your ideas and feedback. Looking for how to keep in touch with us? You can find all the ways in our "Where is the PSF?" blog post.

Wishing you all a wonderful & Python-filled new year!
- The PSF Team

Thursday, January 18, 2024

Announcing Python Software Foundation Fellow Members for Q3 2023! 🎉

The PSF is pleased to announce its third batch of PSF Fellows for 2023! Let us welcome the new PSF Fellows for Q3! The following people continue to do amazing things for the Python community:

Dustin Ingram
Marlene Mhangami 
Nikita Sobolev
Raquel Dou

Thank you for your continued contributions. We have added you to our Fellow roster online.

The above members help support the Python ecosystem by being phenomenal leaders, sustaining the growth of the Python scientific community, maintaining virtual Python communities, maintaining Python libraries, creating educational material, organizing Python events and conferences, starting Python communities in local regions, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available online: If you would like to nominate someone to be a PSF Fellow, please send a description of their Python accomplishments and their email address to psf-fellow at Quarter 4 nominations are currently in review. We are accepting nominations for Quarter 1 2024 through February 20, 2024.

Are you a PSF Fellow and want to help the Work Group review nominations? Contact us at psf-fellow at

Announcing the Deputy Developer in Residence and the Supporting Developer in Residence

We’re very happy to welcome Petr Viktorin as the Deputy Developer in Residence! Better yet, he is joined by Serhiy Storchaka as the Supporting Developer in Residence. This transforms the residency program into a full blown team! We couldn’t be happier.

It’s exciting to be able to begin to realize the full vision of the Developers in Residence program, with special thanks to Bloomberg for making it possible for us to bring Petr on board. The initial idea behind the Developer in Residence was to have three to five people hired directly by the Python Software Foundation to help with developer efficiency at CPython, where most of the contributors are volunteers. Three to five people is a good amount to allow for handling both day-to-day tasks, as well as planning and executing on larger-scale projects.

We were only able to start with a single Developer in Residence, initially sponsored by Google for the initial year, and by Meta for the following two years. We were clear that adding more developers in residence would multiply the impact of the role but, of course, the big question is funding. Fortunately, the success of the initial one-person program allowed for a new sponsor to participate, interested in extending the program with another developer. Thank you, Bloomberg!

We announced the job opening back in July, and the interview process was extensive. The Foundation received close to 100 applications, and it was a very tough decision, as most were excellent candidates. One surprise in particular was that despite the Deputy role being described as targeting programmers of various experience levels, we received many more applications from Python core developers than during the initial Developer in Residence job opening.

Naturally, the core developers bubbled up in the interview process. We were especially impressed by Petr Viktorin’s experience with maintaining Python at Red Hat, his interest in the C API, and his long-term existing contributions to Python. Given the transformative recent developments inside the interpreter in terms of performance and scalability, Petr’s skillset was the perfect match. We’re excited he accepted the offer!

However, there was one more person who we were also ready to hire on the spot: Serhiy Storchaka, a rare example of a core developer generalist, with plenty of C experience and contributions across the entire codebase. Consistently one of the top most prolific contributors to Python, we felt like we needed to secure him as a member for the Residents team. Unexpectedly, a generous anonymous donation allowed us to hire Serhiy as well. Thank you!

We are calling the role the Supporting Developer in Residence to make it clear the funding level here isn’t as high as in the Deputy case. Please contact us if your organization can help sponsor Serhiy to bump him to the Deputy salary. Serhiy sure deserves it!

After an initial meeting with the Steering Council, the Residents team is now ready to take on a more active role in shaping the development of the language. The Council advised that while every team member is expected to prioritize unblocking other contributors and keeping the developer experience smooth, with three people on the team each Resident can now also spend a percentage of their time on feature work aligned with their interests.

There are some exciting times ahead for Python!

Friday, January 12, 2024

EU’s Cyber Resilience Act Passes with Wins for Open Source

Back in April, we wrote to the community about our concerns for the future of the open source ecosystem generally and CPython and PyPI specifically if the European Cyber Resilience Act (CRA) were to pass in the form that had been shared. At the time, we were worried that in the course of providing software for anyone to use, analyze or change that the PSF and/or the Python community might become legally responsible for security issues in the products that are built with the code components that we are providing for free. We asked for increased clarity, specifically:

“Language that specifically exempts public software repositories that are offered as a public good for the purpose of facilitating collaboration would make things much clearer. We'd also like to see our community, especially the hobbyists, individuals and other under-resourced entities who host packages on free public repositories like PyPI be exempt.”

The good news is that CRA text* changed a lot between the time the open source community – including the PSF – started expressing our concerns and the Act’s final text which was cemented on December 1st. That text introduces the idea of an “open source steward.”

“'open-source software steward’ means any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products;” (p. 76)

Furthermore, the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

“More specifically, for the purpose of this Regulation and in relation to the economic operators referred therein, to ensure that there is a clear distinction between the development and the supply phases, the provision of free and open-source software products with digital elements that are not monetised by their manufacturers is not considered a commercial activity.” (p. 10)

So are we totally done paying attention to European legislation? Ah, while it would be nice for the Python community to be able to cross a few things off our to-do list, that’s not quite how it works. Firstly, the concept of an “open source steward” is a brand new idea in European law. So, we will be monitoring the conversation as this new concept is implemented or interacts with other bits of European law to make sure that the understanding continues to reflect the intent and the realities of open source development. Secondly, there are some other pieces of legislation in the works that may also impact the Python ecosystem so we will be watching the Product Liability Directive and keeping up with the discussion around standard-essential patents to make sure that the effects on Python and open source development are intentional (and hopefully benevolent, or at least benign.) 

Thank you to Open Forum Europe (OFE) — especially Ciarán O’Riordan – for bringing the FOSS community together to share our thoughts on how the proposed text would affect open source, thinking about how the goals of the proposed act might be achieved without unintentionally creating a chilling effect for open source and communicating those ideas to legislators. OFE’s work to coordinate our efforts certainly made it easier for the PSF’s concerns to be heard and I’m fairly certain it made it easier for legislators to assess and consider impacts to the open source ecosystem when we were able to speak with one voice. 

*The entire Regulation is published here, if you want to dive into the text more deeply.