idea: maintaining an SBOM for cve-bin-tool

[terriko]

We currently maintain two .csv files for scanning components needed or included by cve-bin-tool. Now that we have sbom support, we might want to consider providing an actual SBOM both for that scanning and as information for others intending to use the tool.

I have a minor preference for SPDX format but could be convinced something else is better.

We'd want to have some CI mechanics in place to ensure any SBOM created stays up to date.

[anthonyharrison]

@terriko I have looked at the CycloneDX Python tool using the requirements.txt file. It doesn't do what I believe is needed as this report shows:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Some of your dependencies do not have pinned version !!
!! numbers in your requirements.txt !!
!! !!
!! -> rich !!
!! -> plotly !!
!! -> beautifulsoup4 !!
!! -> toml !!
!! -> pytest !!
!! -> pytest-xdist !!
!! -> pytest-cov !!
!! -> pytest-asyncio !!
!! -> pytest-mock !!
!! -> zstandard !!
!! -> distro !!
!! -> defusedxml !!
!! -> xmlschema !!
!! -> importlib_metadata !!
!! -> requests !!
!! !!
!! The above will NOT be included in the generated !!
!! CycloneDX as version is a mandatory field. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Running it with a Python virtualenv does produce a SBOM but it also includes the dependencies for the CycloneDX SBOM tool as well.
cve3.txt

[stevespringett]

Version is an optional field in CycloneDX v1.4

https://cyclonedx.org/docs/1.4/json/#components_items_version

[anthonyharrison]

Version is an optional field in CycloneDX v1.4

https://cyclonedx.org/docs/1.4/json/#components_items_version

Thanks @stevespringett but we need the version string with the package name to allow us to query the vulnerability database. Whilst the version isn't explicity specified in the requirements.txt file, I was expecting that the requirements.txt file would be used to find the version for the specififed python packages (as installed) and their dependencies.

[anthonyharrison]

cve.txt. The SBOM contains all the direct dependencies (specified in the requirements.txt file) together with the implicit dependencies from the included files.

There is no consistency between licence names (there are multiple ways of specifying an Apache 2.0 licence!). The file reports (as a comment, the licence file as detected; noting that there are multiple packages with no licence reported. Think it would be good if PyPi enforced SPDX Licence names as it would make life so much easier :-) and consistent.

There is probably more that should be added to the SBOM e.g. relationship with the version(s) of Python supported and also the development dependencies.

[terriko]

Hm, I wonder if we should work on a PEP or tooling suggesting the license name thing. Having the pypi packaging tools spit out a warning might be helpful and probably wouldn't be too hard to write. I'll try to find time to look at it.

[terriko]

A friend pointed me at https://peps.python.org/pep-0639/ -- I haven't read through the details yet but we might want to read through that and throw our support behind it explicitly if it does what we need. I know many peps don't get much in the way of comments, so going and commenting on the discourse thread may be very impactful: https://discuss.python.org/t/pep-639-round-2-improving-license-clarity-with-better-package-metadata/12622

[anthonyharrison]

@terriko Do you want to try sbom4python ? It seems to work when I have tested it on cve-bin-tool.

[terriko]

@anthonyharrison ooh, that's a good idea. Do you just want me to run it and make sure you and I get the same results and then we can check in a file (or maybe two so we have multiple formats), or did you have something else in mind? It would be pretty handy if we could run it in CI and have github actions keep it up to date for us too.

[anthonyharrison]

Here are the results when I run the generated SBOM for cve-bin-tool through cve-bin-tool