SBOMs - Anywhere?

[Anthony Harrison]

This post follows on a chat with Chris Lamb and he felt it was worthy of a
wider readership and debate.

As I am sure everyone is aware, there is a growing interest in Software
Bills of Materials (SBOMs) as a way of improving software security and
resilience. In the last two years, the US through the Exec Order, the EU
through the proposed Cyber Resilience Act (CRA) and this month the UK has
issued a consultation paper looking at software security and SBOMs appear
very prominently in each publication. There are various initiatives
ongoing related to increasing the adoption of SBOMs, including the SBOM
Everywhere initiative which is run by the OpenSSF - this is where I 'met'
Chris. I am also involved in a number of other groups looking at
vulnerability management and SBOMs as well as looking at the wider use of
SBOMs (primarily in the US).

What is very clear is that SBOMs are starting to be produced but as I found
out at FOSDEM, they are only really being used internally within
development teams (which is a great start) rather than being used by end
user organisations. The two use cases are license management and some
limited use for identifying vulnerabilities in. build. It is also very
clear from work I have been doing over the past few months, is that whilst
there are some tools starting to appear, they are very variable in quality
or are very focused on particular use cases (e.g. SBOMs for a container
image).

To try and fill the gap, I have created a number of tools in Python to help
generate and consume SBOMs. All are available on PyPI. Based on the
discussions at FOSDEM, I am going to update a number of them to add some
new features. All of my tools work with SPDX (TagValue, JSON, YAML) and
CycloneDX (JSON) formats - the SBOM world is going to have two competing
standards for the foreseeable future. My tools include:

   - *SBOM4PYTHON* - produces an SBOM for an INSTALLED Python module.. It
   identifies all of the dependent modules including those which are indirect.
   - *SBOM4FILES* - produces an SBOM for files in a directory. It attempts
   to determine the type of file, the licence information and copyright
   information
   - *SBOM4RUST* - produces an SBOM from a Cargo.lock file showing the
   relationships between the components
   - *SBOMDIFF* - compares two SBOMs and reports the differences. Currently
   just looks at changes to a component version, licence and identifies any
   new/deleted components
   - *SBOM2DOC* - produces some human readable output of the content of an
   SBOM. Can produce PDF and Markdown formatted documents as well as to the
   console.
   - *SBOM-MANAGER *- a repository for storing and interrogating SBOMs

More tools are in the pipeline, including one to generate an SBOM from an
installed platform distribution or package (currently works for Debian
systems, work in progress for RPM based systems) and an audit tool. I hope
to publish these in the next couple of weeks.

As SBOMS are starting to be produced, I can already start to see some
interesting characteristics which aren't immediately obvious without an
SBOM. So I believe SBOMs can form a valuable addition to the development
lifecycle

So should Reproducible Builds start creating and using SBOMs (and
delivering them with builds)?

Regards

Anthony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230225/d0571465/attachment.htm>