SBOMs - Anywhere?

[Richard Purdie]

On Sat, 2023-02-25 at 15:56 +0000, Anthony Harrison wrote:
> 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)?

The tools sound like something the ecosystem could benefit from so I'm 
happy to see those being worked on.

You make a good point about older releases. We have a "no new features"
rule for our LTS releases but the point you have here about improving
existing software is an interesting one. There is a case for us adding
this to our LTS with that reasoning.

For my part I've helped ensure SBoM generation is a first class citizen
within the Yocto Project and we've also worked hard to ensure our core
is entirely reproducible and we have tools to let others check their
own layers which add to the core.

Cheers,

Richard