<div dir="ltr">This post follows on a chat with Chris Lamb and he felt it was worthy of a wider readership and debate.<div><br></div><div>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). </div><div><br></div><div>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). </div><div><br></div><div><div>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:<br></div><div><div><ul><li style="margin-left:15px"><b>SBOM4PYTHON</b> - produces an SBOM for an INSTALLED Python module.. It identifies all of the dependent modules including those which are indirect.</li><li style="margin-left:15px"><b>SBOM4FILES</b> - produces an SBOM for files in a directory. It attempts to determine the type of file, the licence information and copyright information</li><li style="margin-left:15px"><b>SBOM4RUST</b> - produces an SBOM from a Cargo.lock file showing the relationships between the components</li><li style="margin-left:15px"><b>SBOMDIFF</b> - compares two SBOMs and reports the differences. Currently just looks at changes to a component version, licence and identifies any new/deleted components</li><li style="margin-left:15px"><b>SBOM2DOC</b> - produces some human readable output of the content of an SBOM. Can produce PDF and Markdown formatted documents as well as to the console.</li><li style="margin-left:15px"><b>SBOM-MANAGER </b>- a repository for storing and interrogating SBOMs</li></ul></div><div>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.</div></div></div><div><br></div><div>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</div><div><br></div><div>So should Reproducible Builds start creating and using SBOMs (and delivering them with builds)?</div><div><br></div><div>Regards</div><div><br></div><div>Anthony</div></div>