By Ivana Atanasova, VMware
At the 2023 SBOM Devroom, hosted at FOSDEM 2023 in Brussels, participants discussed various topics related to generating, understanding, managing, and converting Software Bill of Materials (SBOMs). On the heels of that event, it’s a good time to reflect on where we are with SBOMs and where the community may go in the future.
What are SBOMs? SBOMs are a list of ingredients that make up software components. They allow users and developers of software to better understand what dependencies they rely on. This information can be used to ensure they keep their dependencies secure and abide by the licensing requirements of their dependencies. Here are some key updates on the state of the SBOM ecosystem:
Quality Matters
One of my takeaways from FOSDEM is that quality matters: creating a great Software Bill of Materials is essential for ensuring the security and compliance of software products. If SBOMs are not high-quality, they are much less useful to accomplish the goals of understanding the supply chain and dependencies of a system. Creating high-quality SBOMs requires tooling, both to generate and parse automated SBOM file formats.
What makes an SBOM high-quality? At the SBOM Devroom, Adolfo GarcĂa presented 7 key ingredients of a great SBOM. Adolfo’s list includes:
- Syntactic correctness, which means at the very minimum an SBOM should be possible to parse
- Dependency data, including package relationships, version and name
- Licensing information, which is one of the key pillars SBOMs exist for
- Semantic structure, to enable composing, rearranging, and enriching data
- Semantic correctness
- Software identifiers for less false positives and false negatives
- Supplier data to help find the entity responsible for creating, packaging and building software
- Integrity data, using hashes to make sure one is looking at the right content
What else should SBOM contents cover? Arnout Vandecappelle opened a very productive discussion that included topics such as composability, existing tooling and how much it covers the evolving requirements, whether CPEs should be included, how to deal with vendored dependencies, and how to effectively get provenance information. Many of these topics reflect ongoing efforts the SBOM communities are actively investing in.
Finally, at the SBOM Devroom, Thomas Steenbergen pointed to some key problems that need special attention and that the OSS Review Toolkit (ORT) tooling community is focused on. Most build systems are not designed to generate information about what goes into an artifact. This is rather an additional feature for the majority of them. At the end, everything needs to be resolved back to source code, which is a complicated task that isn’t always possible as the package metadata is sometimes incorrect. It requires a long-term effort where keeping the tooling open sourced and based on open standards makes it possible to move forward with a good pace, bringing more universal solutions that are easy to integrate into every CI system.
Advances in SBOM Tooling
A very important part of the SBOM ecosystem is tooling, which allows for both SBOM generation and parsing. The SBOM Devroom showcased a variety of different approaches and advances to SBOM tooling.
Alexios Zavras and Fotios Valasiadis’ Build recorder opens great opportunities for build time SBOM generation, exposing all files opened and changed by a process. And Kouki Hama’s SW360 has pretty good features like tracking components used by a project or product, assessing security vulnerabilities, maintaining license obligations, enforcing policies, and generating legal documents.
Additionally, Jan-Simon Möller shared how to generate SBOMs with the Yocto project for Automotive Grade Linux (AGL). To give some context for those that are not familiar, AGL is an open source Linux platform for different use cases in the car and is built using The Yocto Project. The Meta SPDX Scanner can run against source code and can output the curated data in the SPDX format as well as be paired with SW360. Carlo Piana and Alberto Pianon also demonstrated a complete compliance toolchain for Yocto projects, called Oniro. Adding another valuable case study, Joshua Watt talked about an automated SBOM generation with OpenEmbedded and the Yocto Project.
SBOMs for Legal Compliance
SBOMs are also very important for legal compliance. Gaurav Mishra and Mohammed Shaheem Azmal Madanapalli from Siemens shared how FOSSology works with SPDX for running license, copyright and export control scans from the command line or from web UI. FOSSology is an open source license compliance software system and toolkit. The project has recently improved the reporting by providing users an option to give an SPDX License Identifier. SPDX is an open standard for communicating software bill of materials information. This helps in maintaining the SPDX specified format for the reports in FOSSology. It also supports the DEP5 format, which is predominantly used within the Debian community, and CLIXML report, which is an in-house format that reports about licensing and related information in XML.
Nicolas Toussaint and Camille Moulin showcased the Hermine tool for converting SBOMs into legal obligations in order to ease collaboration inside organizations between lawyers, developers and product owners, and between legal teams of different organizations. Hermine helps validate SBOMs from other tools and list the resulting concrete legal obligations according to the technical and business context of usage of the different FOSS components.
And last but not least, Linus Seh shared what he believed to be the gold standard of communicating licensing and copyright information – the REUSE CLI tool. With simple steps, REUSE makes declaring licensing and copyright information unambiguous, perfectly human, and machine-readable, making life easier for everyone involved in the software supply chain. It integrates seamlessly into development processes and other best practices of indicating Free Software licenses.
Can SBOMs Save Lives?
Yes, SBOMs can save lives! At the SBOM Devroom, Nicole Pappler introduced functional safety (FuSa), which is by definition “the part of safety that depends on a system or equipment operating correctly in response to its inputs”. FuSa efforts are focused on detecting potentially dangerous conditions and literally saving lives and preventing injuries.
The goal is to keep a complete and consistent set of documentation and verify that the evidence is complete and consistent. In SPDX, this can be achieved by creating SPDX Relationships between all documentation artifacts to track all possible system combinations. Those relationship documents should include a safety plan, requirements management plan, coding guidelines and change management processed.
Do you have valuable experience to add to those efforts? Feel more than welcome to attend the Functional Safety community meetings and do some good to the world!
Conclusion
Finally, Bradley M. Kuhn, Alexios Zavras, Anthony Harrison, Julian Coccia and Paul Novarese held a must-see panel discussion which turned into a great conversation with attendees and organizers on the value and caveats of SBOMs. Here’s a short summary:
What should an SBOM be?
- An objective document that has actual information in it and no judgements listed.
- A static document as long as the software it describes is static. Which also means it does not directly include CVEs, since the list of CVEs applicable to software is not static but instead changes over time.
- Not only valid, but also useful. What is a minimum amount of useful information might be different depending on the use-case.
- An SBOM is useful because it’s going to make all the other aspects of supply chain security better. If you have a high quality SBOM it can be a recipe for reproducibility.
- And in the end it all depends on the tooling.
Kuhn also brought up an interesting point: in an ideal world, would we ever need SBOMs, or should our software be developed in a way that already gives us the benefits that SBOM may provide? Do you believe that this is possible?
Regardless of the state of software security in the future, SBOMs and its associated tooling ecosystem will likely continue to play a major role in keeping our software ecosystem secure. If you have thoughts or feedback, share your thoughts with us and join the various community efforts and discussions around SBOMs! A few places to get involved include the SPDX meetings and the OpenSSF SBOM Everywhere Special Interest Group (SIG). You can also keep up with SPDX on Twitter, LinkedIn, or YouTube.
About the Author
Ivana Atanasova is an Open Source Software Engineer in VMware’s Open Source Program Office, where she has contributed to a variety of projects in the supply chain, observability, networking and other domains. She is part of the TUF, SPDX and CISA Service Transparency communities. She is an active speaker and has spoken at various events, including KubeCon, Open Source Summit, OpenFest, and serves as a member of the KubeCon EU and NA Program Committee. When she’s away from her keyboard, Ivana enjoys playing piano, painting, reading, cooking and walking around nature.