To ensure software security in your supply chain, there’s a lot of buzz today about the need for a SBOM (Software Bill of Materials). But what does this really mean for development teams today?
Specifications have been used by organizations for many years; they are a list of raw materials, assemblies, subassemblies, subcomponents, parts, and the quantity of each required to produce the final product.
In today’s software world, this applies to all code included in an application, licensing requirements for third-party components, dependencies on other components, and compliance with any other industry regulations. According to US President Joe Biden’s May 2021 executive order to strengthen cybersecurity, “SBOM is useful to those who develop or produce software, those who select or purchase software, and those who manage software.”
Michael White, CTO and Chief Architect of the Software Integrity Group at Synopsys, said there are a few different ways to look at SBOM — either as a static artifact, as a report, or as a process. “When we add components to our software, or change the version of components, or update components, we have to maintain this SBOM on an ongoing basis,” he said. An ongoing software maintenance process, he noted, saves you from having to scramble to gather all the information about changes. As a continuous process, you build the SBOM piece by piece as you go along.
As for what SBOMs mean for developers, White said it’s the people in the middle of the supply chain, both the producers of the software and the consumers of the software used to build their applications. So they have to worry about two different sets of liabilities, White explained. “They need to take care of doing what is required of them for the end user of our product. But also do we communicate that requirement to the people we use the software from?”
With open source, this can be in the form of generating export information about a particular package; with commercial software, the organization should require an SBOM from the vendor. “That kind of information has to kind of filter down the supply chain so that the information comes back up.”
Modern software has a long tail of dependencies, and studies have shown that up to 90% of modern applications today are not written by a development team as native code, White said. “The SBOM should really include your own components, what you design,” he said, as well as components assembled from other sources.
White said Synopsys is talking more about building trust than just discussing security, because organizations also need to think about security, quality, compliance — and how to make that accessible to developers.
“We’re very interested in the developer experience,” White said. “So getting that information out at the right time, providing meaningful feedback that tells developers something they can understand and act on. Once this is embedded and visible in the process, many other problems will disappear. It makes the security people happy, the market compliance people happy, and the legal and risk team happy.”
With its platform, White said, Synopsys is building a bridge between developers and other application stakeholders to ensure these requirements are met.
Content courtesy of SD Times and Synopsys