Hi, it’s Jeffrey. I’ve been in IT and Cybersecurity for three decades (dang, I’m getting old) and in my career I have seen a lot of acronyms come and go; I’ve seen challenges, issues, and solutions go from being ‘world ending vulnerability’ to ‘why did we worry about this in the first place?’ in the blink of an eye.

The latest ‘most important thing ever’ is SBOM, but don’t expect this one to go away any time soon.

A Software Bill of Materials (SBOM) is a formal, structured, machine readable record that enumerates the elements of a software application and their relationships up and down the software stack. SBOMs list ALL the packages, libraries, objects, and other components that went into the software and how all those components work together.

An SBOM is a digital version of a traditional Bill of Materials with the added overlay of showing layout and connections – have you ever shopped at IKEA? Or seen the ‘exploded’ view of a complicated piece of technology? SBOMs helps developers and users understand what goes into a software product and its source.

SBOMs have gotten increased focus due to a few high-profile software vulnerabilities – most notably Solar Winds, and Log4J, but this is not a new problem. Applications get more complicated and increasingly are pulling in lots of smaller pieces of code. We also see a lot of stacking, where a SaaS application sits on top of multiple layers of PaaS, ultimately living on a base of IaaS. Unfortunately, it’s Turtles All the Way Down.

The concept of component risk analysis tells us that applications are as secure as the security of the constituent components, and most of the time, no one person understands the security posture of the components. In many cases, people don’t even know WHAT components of the application stack are. This is where SBOMs come into play; SBOMs provide a comprehensive record of the components used in a software product and can help security teams narrow down what vulnerabilities may impact their applications. For example, if you are running object XyZr v.133.1, you don’t care if there is a zero day vuln in v.129.9.

SBOMs can also help with OSS licensing and help prevent violations of licensing agreements of myriad software residing in a multitude of software packages.

As a direct result of the SolarWinds issue, on 12 May 2021 (not coincidentally, this happens to be my mom’s birthday) the US White House issued the Executive Order on Improving the Nation’s Cybersecurity, which among other requirements has a section on Enhancing Software Supply Chain Security. This requires SBOMs for software to be provided to US Federal government clients. The use of SBOMs is not limited to government agencies. Many commercial entities and private companies have started implementing SBOMs to improve their own software supply chain security.

SBOMs are still fairly nascent and organizations are working on the who, what, how, where, and when of SBOMs.

That said, here are a few tidbits and recommendations.

SBOM formats

While the data in an SBOM is crucial, the real value in using SBOMs comes from automation. Which in turn requires standard formats – unfortunately, there are three standards in use right now. Thankfully, most of the tools can handle at least one of them.

  1. Software Package Data Exchange (SPDX)
  2. CycloneDX
  3. Software Identification (SWID) Tags

SBOM use cases

SBOMs also have three different use cases.

  1. Developers use SBOMs to assist in the building and maintenance of their software
  2. Buyers use SBOMs to inform assurance, negotiate discounts, and plan for implementation.
  3. Users use SBOMs to inform asset management, drive threat and vulnerability management, manage licensing and compliance, and to identify software and component dependencies in your supply chain.

Desired capabilities of SBOM tools

  • Create SBOMs during application build process
  • Analyze source code and binaries; generate SBOMs for those artifacts
  • Edit SBOMs
  • Export SBOMs in a human-readable format to enable validation
  • Translate SBOM contents from one format to another
  • Support use of SBOM data in other tools via APIs and connectors

Short Term Recommendations for SBOM

  • Improve your ability to address software issues quickly by adopting SBOMs as part of  your software development and procurement strategy
  • Protect the integrity of the software supply chain by creating a strong software vulnerability management strategy supported by SBOM data
  • Demand upstream software providers support your (as the buyer) software supply chain risk management efforts by using one or more of the standard formats above.
  • Recognize that demands for SBOM will change and get more standardized over time – look ahead and don’t wait for the standards to come to you
  • While I rarely suggest tactics before strategy, in this case, you will likely have to mark SBOM investments as tactical; it is likely that the market will change dramatically over the next two-three years

Stay Safe, Stay Healthy, Stay Secure.

Wheatman Out!