White House recommends use of memory-safe languages like Python

Earlier this week the White House published a report recommending the use of memory-safe programming languages to eliminate an entire class of vulnerabilities affecting software. The report quotes claims from large software producers like Google and Microsoft which estimate that 70% of vulnerabilities affecting software are due to memory-safety issues.

Back in December of 2023, the Cybersecurity and Infrastructure Security Agency (CISA) published a report that included a list of memory-safe programming languages, among them was the Python programming language.

The Python Software Foundation’s response to the US Government's Request for Information noted Python's memory-safety and ability to wrap code written in C, C++, and Rust among other systems languages. Part of Python’s popularity stems from the large number of community-maintained packages using this feature for performance, wrapping existing libraries, and low-level API access.

Cryptography is one of the most depended on Python libraries for cryptographic primitives, installed nearly 10 million times per day. Cryptography started migrating from using C to Rust for security reasons in 2020 and made the first release with Rust binary extensions in 2021. You can listen to maintainers Paul Kehrer and Alex Gaynor discuss this non-trivial migration in their PyCon 2022 talk.

The migration of the cryptography library included tools like PyO3 and setuptools-rust that enable easier adoption of Rust binary extensions. There’s already plenty of buzz for using Rust and Python together, the adoption of Rust in Python packages is steadily increasing from the single digits in 2020 to today with hundreds of packages using Rust.

There are many opportunities to learn about writing Python binary extensions using Rust, for example, at PyCon US 2024 there will be a tutorial about getting started with PyO3 and a talk on PyO3 and maturin, a PEP 517 build backend for Rust by a maintainer of the PyO3 project.

Historically Python binary extensions were built mostly using C and C++ meaning there are many projects which, for reasons like backwards compatibility or lack of resources and time, cannot or do not want to migrate to Rust. For these projects, the use of compiler options can harden binaries against some memory safety issues. The OpenSSF Best Practices working group has published a list of compiler options to consider adopting in order to harden builds of C and C++ code.

There is still much work to be done to secure the Python ecosystem and it can’t be done without our amazing community of contributors and maintainers. We look forward to more investment in this area as part of the industries’ adoption of memory-safe programming languages. If you are interested in being part of conversations around improving security in Python, we invite you to open a thread on discuss.python.org.

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:

• Authorizing the Python Software Foundation as a CVE Numbering Authority (CNA) to publish CVE IDs and records
• Revitalizing the security advisory mailing list (security-announce@python.org)
• Migrating all historical vulnerabilities to the Open Source Vulnerability format (OSV) and having the records indexed into the global OSV database

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 python.org.

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.

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 1-2PM 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 grants@pyfound.org.

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 1-2PM 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 grants@pyfound.org.

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!