# SBOMs for Python packages project **URL:** \ **Category:** Packaging\ **Created:** [November 5, 2024, 6:02pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261 "2024-11-05T18:02:08Z")\ **Posts on this page:** 17\ **Page:** 2
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [November 14, 2024, 3:08pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/21 "2024-11-14T15:08:27Z")
> [@sethmlarson](#): > > Maybe I am misunderstanding your question, please correct me if I am. I wasn’t anticipating asking any tool to change its behavior, instead working around existing behavior and having tools (where possible) note down when they use or pull in a third-party dependency into the final artifact. Is there something about `.a` files that I’m missing? Well, maybe I am misunderstanding the README you linked to, but it seems you are looking for `.a` files in binary wheels in your SELECT query? I would not expect binary wheels to ship `.a` files of dependencies, is there any situation where it occurs? ---
**Author:** ![sethmlarson](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sethmlarson/32/1644_2.png) [@sethmlarson](https://discuss.python.org/u/sethmlarson)\ **Post date:** [November 14, 2024, 3:48pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/22 "2024-11-14T15:48:01Z")
> [@pitrou](#): > > > [@sethmlarson](#): > > > > Maybe I am misunderstanding your question, please correct me if I am. I wasn’t anticipating asking any tool to change its behavior, instead working around existing behavior and having tools (where possible) note down when they use or pull in a third-party dependency into the final artifact. Is there something about `.a` files that I’m missing? > > Well, maybe I am misunderstanding the README you linked to, but it seems you are looking for `.a` files in binary wheels in your SELECT query? I would not expect binary wheels to ship `.a` files of dependencies, is there any situation where it occurs? Ahhh you’re talking about the blog post, yeah to create the data table I added `.a` as a query candidate too just to get a complete sample and to avoid making assumptions about what Python projects do. I wasn’t expecting wheels to contain them in abundance (and iirc: there weren’t many `.a` files in Python packages). ---
**Author:** ![pombredanne](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pombredanne/32/1283_2.png) [@pombredanne](https://discuss.python.org/u/pombredanne)\ **Post date:** [November 14, 2024, 5:01pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/23 "2024-11-14T17:01:47Z")
> [@pitrou](#): > > I would not expect binary wheels to ship `.a` files of dependencies, is there any situation where it occurs? The numpy wheels contain at least one .a `numpy/_core/lib/libnpymath.a` ---
**Author:** ![pombredanne](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pombredanne/32/1283_2.png) [@pombredanne](https://discuss.python.org/u/pombredanne)\ **Post date:** [November 14, 2024, 5:04pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/24 "2024-11-14T17:04:11Z")
> [@pitrou](#): > > But the “seller” will have a hard time generating a correct SBOM if the upstream project doesn’t provide one, right? The [PyArrow](https://pypi.org/project/pyarrow/) wheels for example bundle of bunch of third-party C++ libraries that the entity downloading the wheel doesn’t know about. @sethmlarson another example with numpy, where bundled native code deps may not be up to date [ENH: Streamline and improve the origin and license documentation of third party bundled in wheels · Issue #27764 · numpy/numpy · GitHub](https://github.com/numpy/numpy/issues/27764) ---
**Author:** ![sethmlarson](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sethmlarson/32/1644_2.png) [@sethmlarson](https://discuss.python.org/u/sethmlarson)\ **Post date:** [November 14, 2024, 7:58pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/25 "2024-11-14T19:58:09Z")
I’ve published the results of some validation work for how useful embedded SBOMs are to today’s tooling. Syft, a popular open source SCA tool, is able to use embedded SBOMs inside of wheels. I forked auditwheel and added some [rudimentary SBOM record-keeping](https://github.com/sethmlarson/auditwheel/commit/68c3522fbd8f3377356d260e4e6d7ba4237de212) of bundled shared libraries and Syft was able to use the result end-to-end. Check out the full details, I’ve made all the work public: > **[Early promising results with SBOMs and Python packages](https://sethmlarson.dev/early-promising-results-with-sboms-and-python-packages)** > > This critical role would not be possible without funding from the Alpha-Omega project. > Massive thank-you to Alpha-Omega for investing in the security of the Python ecosystem! > > > > I've ... ---
**Author:** ![fungi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fungi/32/5963_2.png) [@fungi](https://discuss.python.org/u/fungi)\ **Post date:** [November 14, 2024, 8:12pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/26 "2024-11-14T20:12:59Z")
I’ve been only lightly following this discussion since the projects I work in almost exclusively publish pure-Python packages with no separate C extensions, but as a security practitioner I’m still somewhat interested… What would the upshot of SBOM inclusion be for the simple case of pure-Python packages? I assume there would at least be some default entry/entries for the project itself? ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [November 14, 2024, 8:37pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/27 "2024-11-14T20:37:50Z")
> [@sethmlarson](#): > > I’ve published the results of some validation work for how useful embedded SBOMs are to today’s tooling. Syft, a popular open source SCA tool What does “SCA” mean? ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [November 14, 2024, 9:34pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/28 "2024-11-14T21:34:30Z")
> [@pitrou](#): > > What does “SCA” mean? Quoting from the second bullet in the first post: > software composition analysis (SCA) tools ---
**Author:** ![alex\_Gaynor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/alex_gaynor/32/17_2.png) [@alex\_Gaynor](https://discuss.python.org/u/alex_Gaynor)\ **Post date:** [November 14, 2024, 9:39pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/29 "2024-11-14T21:39:30Z")
> [@fungi](#): > > What would the upshot of SBOM inclusion be for the simple case of pure-Python packages? I assume there would at least be some default entry/entries for the project itself? For any project, I assume the default SBOM is empty, but if your Python project vendored anything, you’d enumerate it. ---
**Author:** ![sethmlarson](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sethmlarson/32/1644_2.png) [@sethmlarson](https://discuss.python.org/u/sethmlarson)\ **Post date:** [November 14, 2024, 9:45pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/30 "2024-11-14T21:45:42Z")
> [@alex\_Gaynor](#): > > > [@fungi](#): > > > > What would the upshot of SBOM inclusion be for the simple case of pure-Python packages? I assume there would at least be some default entry/entries for the project itself? > > For any project, I assume the default SBOM is empty, but if your Python project vendored anything, you’d enumerate it. Basically this! If you aren’t vendoring any other projects/code then you wouldn’t need to do anything, SCA tools already handle your project correctly enough to be effective. If you are vendoring projects (even Python ones) you can list them in an SBOM or maybe the tool you’re using to vendor those projects will do that for you in the future. The only use-case I could think of that you might want to use an SBOM even if you’re not vendoring projects is being able to describe your project using SBOM metadata that doesn’t have a Python package metadata equivalent, but I suspect this will be rare. ---
**Author:** ![fungi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fungi/32/5963_2.png) [@fungi](https://discuss.python.org/u/fungi)\ **Post date:** [November 14, 2024, 10:07pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/31 "2024-11-14T22:07:26Z")
> For any project, I assume the default SBOM is empty, but if your Python project vendored anything, you’d enumerate it. Got it, so having an SBOM that just says the package of your project includes the files from your project would be redundant (and perhaps circular). Pure Python projects can presumably just ignore these SBOM discussions for the most part. Oh, though is there potential benefit to including an empty SBOM, as an assertion that your package contains nothing besides the project’s own files? ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [November 14, 2024, 10:11pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/32 "2024-11-14T22:11:19Z")
One thing I notice is that the example with Pillow shows the various libraries as type “rpm”. Surely that’s wrong, as the issue is precisely that these are _not_ versions that are managed as RPMs, but instead are vendored into the wheel and have a very different support model than normal RPMs? Is that just a quirk of the syft tool that people using that tool won’t have a problem with, or is it something that needs further work to distinguish between “dependencies satisfied by linking to the system library” and “dependencies bundled with the software”? ---
**Author:** ![sethmlarson](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sethmlarson/32/1644_2.png) [@sethmlarson](https://discuss.python.org/u/sethmlarson)\ **Post date:** [November 14, 2024, 10:14pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/33 "2024-11-14T22:14:11Z")
> [@pf\_moore](#): > > One thing I notice is that the example with Pillow shows the various libraries as type “rpm”. Surely that’s wrong, as the issue is precisely that these are _not_ versions that are managed as RPMs, but instead are vendored into the wheel and have a very different support model than normal RPMs? That’s a result of the software identifier being used which is a “package URL”, this is how a tool like Syft or Grype can make links between software in use and a vulnerability database. The SBOM included in the Pillow wheel had package URLs that look like this, because AlmaLinux uses RPMs: ```python pkg:rpm/almalinux/libXau@1.0.9-3.el8?distro=almalinux-8 ``` You can see the full SBOM file that gets generated at this GitHub Gist: [Example CycloneDX SBOM file generated by auditwheel · GitHub](https://gist.github.com/sethmlarson/9b87245c99147815e8e18901f4a10444) ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [November 14, 2024, 10:16pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/34 "2024-11-14T22:16:21Z")
So “something that people using the tool won’t have a problem with”. Cool. Sorry for the noise. ---
**Author:** ![sethmlarson](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sethmlarson/32/1644_2.png) [@sethmlarson](https://discuss.python.org/u/sethmlarson)\ **Post date:** [November 14, 2024, 10:18pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/35 "2024-11-14T22:18:26Z")
@pf_moore No worries! I am not an expert on the PEP delegate process for packaging PEPs but wanted to confirm you are okay with @brettcannon being PEP delegate. Brett volunteered to be delegate here: [SBOMs for Python packages project - #13 by brettcannon](https://discuss.python.org/t/sboms-for-python-packages-project/70261/13) ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [November 14, 2024, 10:22pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/36 "2024-11-14T22:22:29Z")
Yep, that’s fine with me. The actual process is documented [here](https://www.pypa.io/en/latest/specifications/#proposing-new-specifications). Technically you need approval from “the other PyPA core reviewers, the lead PyPI maintainer and the default PEP-Delegate for package distribution metadata PEPs” (of which I’m the last of the 3), but we tend to be pretty informal about the details and as long as no-one objects and you have my OK, we should be fine. ---
**Author:** ![sethmlarson](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sethmlarson/32/1644_2.png) [@sethmlarson](https://discuss.python.org/u/sethmlarson)\ **Post date:** [November 22, 2024, 3:32pm UTC](https://discuss.python.org/t/sboms-for-python-packages-project/70261/37 "2024-11-22T15:32:32Z")
I’m still working on the PEP draft currently, as a part of that I’ve [created an annotated end-to-end visualization](https://sethmlarson.dev/visualizing-the-python-package-sbom-data-flow) for how SBOM data will “flow” through a Python package and intermediate tools. Hoping that I can share the PEP draft sooner rather than later for more feedback 🙂 ![Python package SBOM data flow visualization](https://us1.discourse-cdn.com/flex002/uploads/python1/original/3X/1/8/187cd49a3c96ee09c3b32345f8ce8875cc068ce2.png) [Previous page](https://discuss.python.org/t/sboms-for-python-packages-project/70261.md?page=1)