Thursday, February 29, 2024

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.

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