# Create and distribute Software Bill-of-Materials (SBOM) for Python artifacts

**URL:** <https://discuss.python.org/t/create-and-distribute-software-bill-of-materials-sbom-for-python-artifacts/39293>\
**Category:** Core Development\
**Tags:** security\
**Created:** [November 21, 2023, 8:00pm UTC](https://discuss.python.org/t/create-and-distribute-software-bill-of-materials-sbom-for-python-artifacts/39293 "2023-11-21T20:00:05Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![malemburg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/malemburg/32/50_2.png) [@malemburg](https://discuss.python.org/u/malemburg)\
**Post date:** [November 29, 2023, 5:08pm UTC](https://discuss.python.org/t/create-and-distribute-software-bill-of-materials-sbom-for-python-artifacts/39293/10 "2023-11-29T17:08:49Z")

</div>

The manylinux\_2\_28 image is AlmaLinux 8 based, so perhaps their wiki page can help get those SBOMs generated: [Codenotary SBOM integration · AlmaLinux/build-system Wiki · GitHub](https://github.com/AlmaLinux/build-system/wiki/Codenotary-SBOM-integration)

They have a Python tool for generating the SBOMs on, what appears to be, a per package basis. The page also refers to a git based notary service, but I’m deep enough into all this to be able tell, whether we need something like that as well.

One issue I can see with going down this rabbit hole is rather frequent changes to SBOMs of those images (eg. due to security fixes), so I guess there’s a versioning challenge to be solved (possibly using git hashed).

---

_[View the full topic](https://discuss.python.org/t/create-and-distribute-software-bill-of-materials-sbom-for-python-artifacts/39293)._
