One of my friends messaged me on LinkedIn today and asked “What is this SBOM you keep talking about?”  I realized that he’s right and I should probably explain what an SBOM is.  First, the term refers to a “Software Bill of Materials”.  An SBOM is a complete inventory of all the software and dependencies of an application and is typically delivered in the form of a JSON or XML document.  Why is an SBOM critical?  Well, one reason is that they provide visibility into the software supply chain behind a particular application.  It also helps teams test an application for compliance and identify security risks that an app might have.

Wikipedia defines an SBOM this way:
“A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product.  It is analogous to a list of ingredients on food packaging: where you might consult a label to avoid foods that may cause allergies, SBOMs can help organizations or persons avoid consumption of software that could harm them.”

Why is everybody talking about SBOM now?

The need for something like an SBOM specification has existed for many years but has become more visible in the last two years as several top several high-profile security incidents. In particular, the SolarWinds incident in early 2020 as well as ongoing issues with NPM have made it obvious that there needed to be more governance around the software supply chain than there was.

Applications have become increasingly complex which in turn makes securing and managing those applications more difficult. Cloud-native services and open source make up a growing part of the average modern web application. Software engineering teams don’t necessarily understand how adopting these new technologies or services changes the threat model for their applications. The SBOM is meant, in part, to at least make these components visible to the naked eye so teams can understand the scope and breadth of their applications

The Biden administration passed an executive order in 2021 entitled “The Executive Order on Improving the Nations Cybersecurity”. This executive order requires that any companies wishing to sell to the US government must meet SBOM requirements.

What’s in an SBOM?

At its simplest a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component:

  • Component name
  • Supplier or vendor of component
  • Software license type
  • Component version number
  • Known vulnerabilities for component
  • Transitive dependencies to other software

Defining these core data points about each application composition object means that engineering teams are in a better place to be able to mitigate or remediate issues in these components. Tracking this information over time means that a properly built SBOM will catch and make visible any changes that can adversely affect the application.

 

How do you create a SBOM?

Because there are several different formats for SBOMs organizations will need to make a decision which they will support internally. Or, alternatively, they will need to have the right data in place to create any format they are asked for.

Unfortunately, there is no consensus on what a SBOM should look like or include. There are LOTS of suggestions, and vendors describing their way as the only way to create and handle SBOMs. The reality is that there are at least 3 different formats for SBOMs:

If you like what you see, book a demo!

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!