Generating a Software Bill of Materials Is Becoming Essential

Modern applications often comprise many different components that come together to provide a complete service.

In recent years, to help provide transparency to users, there has been an increasing emphasis on what all those different components are. Having visibility into different components can also be helpful for security purposes, in case they have an underlying risk associated with them. Many industries have a bill of materials, and now it's an idea whose time has come to the IT industry with the software bill of materials (SBOM).

The need for an SBOM has been further accelerated by the U.S. government. On May 12, President Biden issued an executive order that requires, for cybersecurity purposes, software vendors that sell to the federal government to provide a software bill of materials for the applications and services they offer.

What Exactly Is a Software Bill of Materials?

According to Moran Ashkenazi, chief information security officer at DevOps firm JFrog, an SBOM is more than simply a list of components.

"In reality, we need to be looking at not only the components, but where those components came from, their function, how they were assembled and the development environment in which they were assembled," Ashkenazi told ITPro Today. "With visibility into all of this data, throughout the end-to-end lifecycle of development, companies can make data-driven business decisions, such as automatically stopping development when a bug or vulnerability is discovered."

Kate Stewart, vice president at the Linux Foundation, which has multiple ongoing efforts to help with SBOMs, including SPDX and OpenChain, sees a number of ways that a software bill of materials can intersect with DevOps efforts. There could be an SBOM of the software sources, an SBOM created during a development build or an SBOM produced from forensic analysis of an executable images, she said.

"Most products today are built from open-source projects," Stewart told ITPro Today. "Being able to generate a full SBOM for a product that includes open-source component dependencies can be hard to summarize the further down the dependency tree gets traversed."

While an SBOM provides visibility into what an application is made from, sharing that information does not expose a company's intellectual property. Shiri Arad Ivtsan, director of product management at WhiteSource, said there is a big difference between knowing the third-party ingredients and knowing the ultimate recipe or execution.

Another concern some people might have is that generating the SBOM requires source code disclosure, which is not the case, she said.

"Your proprietary source code remains yours to share or to keep confidential," Ivtsan told ITPro Today. "The libraries you share in the SBOM are third-party and open-source libraries."

Challenges with Assembling an SBOM

With the complexity of modern DevOps, developers often use many different sources across distributed teams, bringing multiple challenges to assembling an SBOM.

JFrog's Ashkenazi noted that a key challenge lies in achieving complete visibility and shared governance over a company’s entire portfolio of software. In Ashkenazi's view, organizations need to have an enterprise view of their systems, and that cannot be achieved without an end-to-end solution, integrating security and central repository management in a global way.

Getting a handle on all the components used in an application can be particularly challenging with open-source components. Most organizations don’t make decisions centrally, but instead allow individual developers to bring in new components on their own in a distributed way, according to Donald Fischer, CEO and co-founder of Tidelift.

For WhiteSource's Ivtsan, a big challenge is finding a tool that will generate an SBOM that is capable of properly including all the various software languages and technology stacks an organization is using.

"If you want to generate an SBOM, make sure the tool you choose supports all the software languages, both source file and packaged-based, and also new technologies like containers and serverless," Ivtsan said.

Software Bill of Materials Best Practices

There are a number of ways that DevOps teams and IT organizations can implement processes and technologies to help create a software bill of materials.

The Linux Foundation's Stewart suggests that as a bare minimum, organizations work with one of the standards that the National Telecommunications and Information Administration (NTIA) has recognized as being able to satisfy the minimum elements for SBOMs. 

NTIA is working on guidance to help organizations comply with the Biden administration's executive order that requires vendors to have an SBOM. On June 2, the NTIA published an initial list of minimum requirements, which include open-source tools as well as proprietary commercial offerings. Stewart noted that one such open-source data standard is the Software Package Data Exchange (SPDX), which enables libraries to support generation and consumption of SBOM files.

While it's important to have a data format to share what's in a software build, it's also a best practice for organizations to have an inventory of what software components are available for developer teams to build from in the first place.

A key best practice for creating an accurate and continuously up-to-date software bill of materials is to maintain a centralized catalog of known-good, proactively maintained open-source components, Tidelift's Fischer said. With an approved catalog in place, management should ensure that developers across the organization are pulling from it or are making requests to add new components when they need them.

Ashkenazi echoed the idea of having an inventory of available components in place from which to build out an SBOM.

"Organizations and developers will be best positioned to implement a software bill of materials if they start with a complete inventory of their software components and usage in the company—a single source of truth," Ashkenazi said. "In addition, as organizations need to attest to the security of every step in the pipeline build process, it’s essential they provide immutable, signed and validated SBOM releases to ensure the integrity of software packages."