GH actions example producing SBOM from pyproject.toml?

[laur89]

Could someone provide a starting point for a github actions/workflow example for producing SBOM if dependencies are defined in a pyproject.toml?

[jkowalleck]

What have you tried so far? What is the exact environment? What repo?

[jkowalleck]

out of curiosity, what are you aiming for with this SBOM?

btc does not ship any components, all dependencies are resolved by downstream users. Your SBOM would not reflect the things downstream users would see on their system, right?

[jkowalleck]

# TODO: which of the following?
cyclonedx-py environment --output-format json -o sbom.cdx.json-1
cyclonedx-py requirements --pyproject pyproject.toml --output-format json -o sbom.xdx.json-2

did you read the documentation? https://cyclonedx-bom-tool.readthedocs.io/en/latest/usage.html

---

cyclonedx-py requirements ... - Support for Pip’s requirements file format dependency lists.
You don't have such requirements file handy, do you?

cyclonedx-py environment ... - By analyzing the actually installed packages, this will produce the most accurate and complete CycloneDX BOM. The generated CycloneDX SBOM will include metadata, licenses, dependency graph, and more.
This would produce an SBOM for the exact setup in your github action's environment - nothing any downstream user would see value in, it is purely for documenting your setup in a GitHub workflow.
If this is the thing you want to achieve, then this is the right thing for you.

[laur89]

out of curiosity, what are you aiming for with this SBOM?

Provide a manifest with either pypi pkg or github tag so inevitable supply chain influence can be verified against installed bctl version.

all dependencies are resolved by downstream users. Your SBOM would not reflect the things downstream users would see on their system, right

As it stands, correct. But once bctl starts pegging the dependencies to specific version, then it no longer would be the case.

did you read the documentation?

Yes, but it wasn't clear (to me anyway) how it's to be used with pyproject.toml. Sounds like environment is the way to go.

[jkowalleck]

all dependencies are resolved by downstream users. Your SBOM would not reflect the things downstream users would see on their system, right

As it stands, correct. But once bctl starts pegging the dependencies to specific version, then it no longer would be the case.

even if all dependencies are pinned to exact versions, the dependency resolution is still done downstream. you have NO control what downstream users actually install and where it comes from.

For example, when people used Conda for the ecosystem management, modified dependencis are pulled from condaforge and would still match you runtime-requirements.
Or when your package is vendored by linux distros, the actual dependencies would managed by them and would be not the ones you declare in your SBOM - and still the dependencies would be met on runtime.

out of curiosity, what are you aiming for with this SBOM?

Provide a manifest with either pypi pkg or github tag so inevitable supply chain influence can be verified against installed bctl version.

For a library like bctl, I recommend not building any SBOM that is shipped to downstream users. You just can not clearly tell supply chain influences on a downstream system - that is the design of python packaging - it is done on downstream on user-site.

Side note: If your package would be shipping/vendoring 3rd party components, then PEP 700 would be the target - which is a whole different story, and that SBOM required completely different evidences and quality.

did you read the documentation?

Yes, but it wasn't clear (to me anyway) how it's to be used with pyproject.toml. Sounds like environment is the way to go.

You are right.
If you are just interested in a build-time BOM for documentation purposes, then cyclonedx-py environment is the absolute right thing for you - as the resulting BOM documents your exact build-env.
https://cyclonedx-bom-tool.readthedocs.io/en/latest/usage.html#for-python-virtual-environment

cyclonedx-py environment --pyproject pyproject.toml ....

[jkowalleck]

ah, just in case you wanted a way to generate an SBOM to replace be based on your package manifest, this would be the ticket for it: #1041
Feel free to discuss int he specific ticket

[laur89]

the dependency resolution is still done downstream. you have NO control what downstream users actually install and where it comes from

You're absolutely right. But for my personal needs, I'm happy forced to be content with it. To be quite fair the SBOM is mostly for me. I want to be able to check at a glance what versions of pypi-sourced packages are installed by this given program. While it's not a 100% guarantee as you pointed out, it's still likely to hold true, as pypi doesn't allow replacing packages of same version & architecture. But fair point.

that is the design of python packaging - it is done on downstream on user-site

But if I'm the user I care most about in context of bctl, and I know the dependencies are pulled from pypi when I do pipx install bctl -- there's still some value SBOM provides, no?

Bit of a tangent, but what's the current meta/state-of-the-art for packaging all the dependencies in the wheel so SBOM really does reflect definitive state? Both py & js worlds tend to move so fast I struggle to keep up if not working with them daily.

---

BTW I would remove the word "library" from the ticket, as even this very bctl is not a library, but a python program directly used by an end-user, not by another program; i.e. this is not exclusive to libraries.

Anyway, thanks for the time and challenging my thinking!

[jkowalleck]

I want to be able to check at a glance what versions of pypi-sourced packages are installed by this given program.

ah, i understand. thank you for baring with me, and sorry that it took me so long to understand.

But if I'm the user I care most about in context of bctl, and I know the dependencies are pulled from pypi when I do pipx install bctl -- there's still some value SBOM provides, no?

Sure, then I would go with the following for your own downstream setup in pipx:

cyclonedx-py environment ~/.local/pipx/venvs/meshtastic/

Bit of a tangent, but what's the current meta/state-of-the-art for packaging all the dependencies in the wheel so SBOM really does reflect definitive state? Both py & js worlds tend to move so fast I struggle to keep up if not working with them daily.

For JS, they know bundled dependencies - https://docs.npmjs.com/cli/v11/configuring-npm/package-json#bundledependencies.
this is possible since every package may have their own node_modules folder on runtime.

For Python, I am not quite certain - i think there is still no way to ship bundled dependencies, since they may override existing dependencies - and practically you could utilize .pth injections to load shipped packages. you should ask the people of PyPackaging

• read https://packaging.python.org/en/latest/
• ask in the respective community - https://www.pypa.io/

BTW I would remove the word "library" from the ticket, as even this very bctl is not a library, but a python program directly used by an end-user, not by another program; i.e. this is not exclusive to libraries.

understood. we even have a switch for expressing this: cyclonedx-py ... --mc-type application ...

Anyway, thanks for the time and challenging my thinking!

No worries, I really appreciated the conversation. 👍