May 9, 2023

Last Updated on January 15, 2024

The term “software bill of materials” (SBOM) appears 38 times in President Biden’s Executive Order 14028 on “Improving the Nation’s Cybersecurity.” This document—released shortly after the SolarWinds attacks—put the writing on the wall for US government agencies and their software suppliers about unacceptable security risks in the global software supply chain.

Reliance on open-source and other third-party libraries, APIs, and components begs the burning question that SBOMs help to answer: What are the dependencies in our code, and what security and other business risks do they present?

Tim Mackey, Head of Software Supply Chain Risk Strategy at Synopsys, gives technical and business leaders a thought leadership overview on what SBOMs are all about and how development teams can start creating them alongside their applications.

Join us as we discuss:

  • What exactly is an SBOM and what can it contain?
  • What market drivers are putting SBOMs on the front burner for software developers and their customers?
  • The role of software composition analysis (SCA) in automating SBOM creation and maintenance.

 

What is an SBOM?

“There are lots of people running around saying, ‘I need an SBOM. I want an SBOM,’” Tim notes. “It’s somehow magical because everybody’s talking about it. But what they don’t realize is an SBOM is quite simply a list of the dependencies that a piece of software has on something else.”

The extent to which modern cloud-first software relies on third-party code can be mind-boggling. For example, a simple Python program that downloads a table from a website might require only 50 lines of code. But within those 50 lines are calls to various Python “packages” or libraries that might include hundreds of thousands of lines of code.

“The reality is, from a security perspective, all the design and testing decisions that those libraries [reflect], they’re not the same as what your code has,” Tim relates. “And if they’re bad, your code is going to fall victim to it somehow, some way.”

“There are lots of people running around saying, ‘I need an SBOM. I want an SBOM.’ It’s somehow magical because everybody’s talking about it. But what they don’t realize is an SBOM is quite simply a list of the dependencies that a piece of software has on something else.”—Tim Mackey

 

The NIST SSDF and SBOMs

If you’re looking for guidance around generating SBOMs, one of the best places to start is NIST 800-218, the Secure Software Development Framework (SSDF) v1.1. The SSDF provides comprehensive advice on how a business can start building security into its software development lifecycle (SDLC)—including SBOMs, which are foundational for software security.

“Whether you follow NIST or not, at least here’s a rubric for success,” says Tim. “One element in the SSDF is a SBOM. So, without having an SBOM you can’t claim that you’re performing all the various tasks defined in the SSDF.”

 

“Without having an SBOM you can’t claim that you’re performing all the various tasks defined in the SSDF.”—Tim Mackey

 

Software composition analysis and SBOMs

If you’re looking to create an SBOM for a typical web application, you need the help of automation. A manual approach is too time-consuming and inaccurate to get the job done unless your app is very small.

A wide range of software composition analysis (SCA) solutions are available to help drive the SBOM creation/maintenance process at a DevOps pace. Tim advocates selecting one that follows either the Software Package Data Exchange (SPDX) or OWASP CycloneDX SBOM standard. It’s also important to carefully analyze a tool’s output before making a final decision.

“The first order of business for anyone on this SBOM path is, when you pick your favorite SBOM generation tool, take its output to the respective validator tools that are created by the SPDX or CycloneDX communities and see if it’s a valid SBOM,” Tim advises. “If it isn’t, move on to the next tool. Don’t even bother trying to make a tool work when you should be worrying about how to actually do the analysis of the software to generate a legitimate SBOM.”

“When you pick your favorite SBOM generation tool, take its output to the respective validator tools that are created by the SPDX or CycloneDX communities and see if it’s a valid SBOM. If it isn’t, move on to the next tool.”—Tim Mackey

 

SBOM benefits

A robust SBOM has numerous advantages for vendors, their customers, and other stakeholders.

For software vendors, SBOMs help reduce business risk by identifying three major potential problems in your code:

  • Security vulnerabilities
  • Code quality issues
  • License compliance concerns

For software users, an SBOM is enabling technology that shows what an application looked like at the time of its release, in terms of dependencies and license information. Paired with vulnerability data, an SBOM helps application users answer key questions about how an application was tested for security.

“In terms of how well suited is this application to run in my environment with my context, that’s something you can do really well when you have a robust SBOM that is truly comprehensive and accurate,” explains Tim.

“In terms of how well suited is this application to run in my environment with my context, that’s something you can do really well when you have a robust SBOM that is truly comprehensive and accurate.”—Tim Mackey

 

When do you need to be SBOM-ready?

How long before SBOMs go from buzzword to ubiquitous customer expectation? Tim believes it will happen within the next 18 to 36 months.

“It’s going to come on us very quickly, where most enterprise level organizations—your midsize businesses and higher—will be operating with an SBOM-centric mindset for their application procurement and governance,” Tim relates.

Currently, the biggest driver for SBOM adoption is US government policy. Federal agencies are now mandated to require supplier compliance with increasingly stringent application security and overall cybersecurity capabilities, which will soon impact almost every US software vendor.

“It’s going to come on us very quickly, where most enterprise level organizations will be operating with an SBOM-centric mindset for their application procurement and governance.— Tim Mackey