To secure the software in your supply chain, there’s a lot of hype today about the need for an SBOM (software bill of materials). But what does that really mean for development teams today?

BOMs have been used for years by organizations; they are a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product. 

In today’s software world, it applies to all the code that goes into an application, license requirements for third-party components, dependencies on other components, and compliance with any other industry-specific regulations. According to a May 2021 executive order from U.S. President Joe Biden aimed at tightening up cybersecurity, “an SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software.”

Michael White, technical director and principal architect at the Software Integrity Group at Synopsys, said there are a couple of different ways to look at SBOMs – either as a static artifact or report, or as a process. “As we add components into our software, or change the version of the components, or update the components, we should be maintaining that SBOM on an ongoing basis,” he said. The continual process of software maintenance, he pointed out, saves you from having to scramble to assemble all the information about changes. As a continual process, you’re building up the SBOM piece by piece as you go along.

As for what SBOMs mean for developers, White said those are the people who are in the middle of the supply chain, as producers of software and consumers of software used to create their applications. As such, they have to worry about two different sets of obligations, White explained. “They have to worry about doing what they’re required to do for the end user of our product. But then also, are we passing that requirement down to the people that we consume software from?” 

With open source, that could be in the form of generating export information about a particular package; with commercial software, an organization should have the requirement that the supplier provide an SBOM. “That kind of information should kind of filter down the supply chain so that the information kind of bubbles up again.”

Today’s modern software comes with a long tail of dependencies, and studies have shown that as much as 90% of a modern application today is not written as first-party code by your development team, White said. “The SBOM does have to include your own components, the things you’re developing,” he said, as well as components assembled from other sources.

White said Synopsys talks more about building trust than simply discussing security, because organizations also have to think about safety, quality, compliance – and how to make that available to developers.

“We’re very much about the developer experience,” White said. “So, surfacing up that information at the right time, providing meaningful feedback that tells developers about something they can understand and act on. Once that is embedded and visible in the process, a lot of other concerns go away. It keeps the security people happy, it keeps the market compliance people happy, and the legal team and risk team happy.”

With its platform, White said, Synopsys is building the bridge between developers and the other stakeholders in an application to ensure those requirements are being met as well.

Content provided by SD Times and Synopsys