How I Learned to Stop Worrying and Love the SBOM

The presentation discusses the need for a Software Bill of Materials (SBoM) to improve cybersecurity and DevOps practices. The working group model is proposed to create a consensus on the SBoM standards and formats.

• The SBoM is a list of dependencies in software that needs to be automated and machine-readable to be useful.
• The working group model is proposed to create a consensus on the SBoM standards and formats.
• The working groups will focus on taxonomy, state of practice, standards and formats, and healthcare proof of concept.
• Proposed standards for SBoM include Software ID Tags and SPDX.
• The SBoM will improve cybersecurity and DevOps practices by providing transparency and accountability in the software supply chain.

The speaker mentions that the Linux Foundation is concerned about whether a software is under the GPL license when building a project. This highlights the need for a shared format and standard for SBoM to ensure that proprietary and open-source software can be included in the list of dependencies. The SBoM will provide a comprehensive list of ingredients in software, allowing users to track down potential vulnerabilities and improve cybersecurity practices.

Despite its simplicity, the "software bill of materials" (SBOM) has been met with apathy and hostility, especially in policy circles. Why has this common industrial concept been so unpopular when translated into the information security context, and how can it potentially revolutionize our industry? This talk will shed light onto the policy context of this discussion, and lay out a vision of how members of the security community can win over the naysayers to foster greater transparency. The US Department of Commerce recently announced a new 'multistakeholder initiative' on software bill of materials. The goal is for software and IoT vendors to share details on the underlying components, libraries, and dependencies with enterprise customers. This transparency can catalyze a more efficient market for security by allowing vendors to signal quality and giving enterprise customers key knowledge—you can't defend what you don't know about. This transparency creates a new paradigm of shared security responsibilities, where an enterprise customer can have greater insight into what is running on their network. This, in turn, complicates existing relationships between vendor and customer. With this transparency, how can vendors offer assurances that a discovered vulnerability doesn't affect a particular product? How can vendors safeguard trade secrets with an incomplete SBOM, along the lines of "natural and artificial flavorings" on an ingredient list? And lastly, how will this inform the emerging debate over end-of-life in the IoT space, particularly for medical devices and automobiles that have a physical life space beyond their software support model? None of these hurdles are insurmountable, but solutions will require finding common ground. A world where SBOMs are more common can be a more secure world, but we'll need to tackle the newly raised policy issues as well.