A new Python Enhancement Proposal (PEP) is introducing the concept of Software Bill-of-Materials (SBOM) documents for Python packages to improve the transparency and measurability of package dependencies. The proposal, which was released on January 2, highlights the challenges faced by Python developers when managing “phantom dependencies,” or dependencies that aren’t directly visible in the package metadata. These phantom dependencies often include non-Python components necessary for compatibility, ease of installation, or use cases like machine learning, which rely on compiled libraries from languages such as C, C++, Rust, and Fortran.
The core issue addressed by this proposal lies in the fact that many Python packages, particularly those distributed in the wheel format, bundle compiled libraries without a standardized way of encoding metadata about these components. While the wheel format is widely preferred for its ease of installation, it doesn’t offer an effective means of documenting the underlying libraries. As a result, when tools like Software Component Analysis (SCA) scanners inspect a package, they may overlook critical non-Python components, leaving security vulnerabilities or licensing issues unaddressed.
In response, the proposal advocates for the inclusion of an SBOM document alongside Python packages to annotate all included libraries and components. This would enable SCA tools to more reliably identify and assess software components, improving the accuracy of vulnerability scans and compliance checks. It’s a step toward ensuring that even complex Python packages, which may contain a mix of Python and non-Python dependencies, are thoroughly analyzed for potential risks.
SBOMs are already gaining traction in global software development and regulatory frameworks. They serve as a standardized method to describe a software package’s composition, provenance, and history, making them a key asset for software security and license management. The PEP highlights how SBOMs are integral to meeting new regulatory requirements, such as those outlined in the Secure Software Development Framework, and proposes their use in Python packaging as a critical move toward securing the broader ecosystem.