Skip to Main Content
March 30, 2023

What You Need to Know About SBOM

Written by Charles Yost

What is an SBOM?

A Software Bill of Materials (SBOM) is a hierarchical, itemized list of all dependencies, their version numbers and provenance for a given piece of software. It may also include other data, such as the license type or details about which database to query for vulnerability disclosure. SBOMs are not restricted to applications and can be created for many things, such as a Docker image, an operating system, or even hardware components.

What is an SBOM Used For?

While highly dependent on your goals, SBOMs can have many uses. Having all the relevant data at hand can lead to faster outcomes during incident response, better policy decisions backed by facts, and a greater awareness of your software security at large. SBOMs are valuable during the entire lifetime of a security program and are in some cases pivotal in customer acquisition.

When should you begin collecting, creating, and using SBOMs? Now. Or right after you read through this blog. SBOMs are the sort of resource you want to invest in before you are impacted by an incident that they could help solve.

How do SBOMs Look?

Example SBOM Entry

Here is an example of what an entry may look like in practice:

{
  <strong>"id"</strong>: "6374b5ebf62f54ea",
  <strong>"name"</strong>: "@types/node",
  <strong>"version"</strong>: "17.0.21",
  <strong>"type"</strong>: "npm",
  <strong>"foundBy"</strong>: "javascript-package-cataloger",
  <strong>"locations"</strong>: [
    {
      <strong>"path"</strong>: "/usr/local/lib/python3.8/dist-packages/playwright/driver/package/node_modules/@types/node/package.json",
      <strong>"layerID"</strong>: "sha256:062e37f31d9f5b9bcdcdac59e1138ac60b2a4997aeb916f1d140f5b55c6c7144"
    }
  ],
  <strong>"licenses"</strong>: [
    "MIT"
  ],
  <strong>"language"</strong>: "javascript",
  <strong>"cpes"</strong>: [
    "cpe:2.3:a:\\@types\\/node:\\@types\\/node:17.0.21:*:*:*:*:*:*:*",
    "cpe:2.3:a:*:\\@types\\/node:17.0.21:*:*:*:*:*:*:*"
  ],
  <strong>"purl"</strong>: "pkg:npm/%40types/[email protected]",
  <strong>"metadataType"</strong>: "NpmPackageJsonMetadata",
  <strong>"metadata"</strong>: {
    <strong>"name"</strong>: "@types/node",
    <strong>"version"</strong>: "17.0.21",
    <strong>"author"</strong>: "",
    <strong>"licenses"</strong>: [
      "MIT"
    ],
    <strong>"homepage"</strong>: "https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node",
    <strong>"description"</strong>: "",
    <strong>"url"</strong>: "https://github.com/DefinitelyTyped/DefinitelyTyped.git",
    <strong>"private"</strong>: <strong>false</strong>
  }
}

Here we can see that many aspects are recorded: the license, version number, package URL, and even where the package is installed.

This SBOM is in a format from the tool syft. Some other formats for SBOMs include CycloneDX and SPDX. You may find controversy online over which format to use, but having an SBOM in any format is better than not having one while trying to decide which is best for your usecase. (Also, syft can convert between formats.)

Formats

CycloneDX

CycloneDX was created by the Open Web Application Security Project (OWASP). From this, we can deduce that it was created with cybersecurity in mind. This is reinforced by the fact that CycloneDX format SBOMs may include vulnerability information or link to a separate VEX (Vulnerability Exploitability eXchange) CycloneDx meets NTIA minimum requirements for SBOM.

SPDX

SPDX (Software Package Data Exchange) was developed by the Linux Foundation. It was initially focused on documentation of licenses used in components of software, but it also supports security information. The SPDX specification is an international open standard (ISO/IEC 5962:2021), and meets the NTIA minimum requirements for SBOM.

Others

There are other specifications (new and old) not mentioned here. For now, CycloneDX and SPDX are the primary formats to consider when working with SBOMs.

Sources

SBOMs may be generated for different layers relating to software. Here are some examples:

  • Hardware
  • Operating System
  • Compiler
  • Transitive and direct dependencies
  • Packager
  • Application

This list is not exhaustive. Other layers may exist for which SBOMs can be generated. Some of these layers might be beyond your visibility. For example, if you are a software application consumer, you will need to receive SBOMs from the software publisher for layers such as the compiler, and possibly for transitive dependencies.

Why SBOMs Matter

While specifics vary across use cases, here is why SBOMs matter, in general.

  1. U.S. Government agencies will begin requiring SBOMs from their software vendors (see my Timeline for the United States Executive Order on Improving the Nation’s Cybersecurity for details).
  2. SBOMs can help improve your security posture, by providing visibility into the depths of your installed software, and the security of your vendors software supply chain. This allows you to proactively harden soft spots or develop detections in areas unable to be hardened.
  3. When a vulnerability is made public, SBOMs can provide visibility into your potential risk of exploitation, particularly if the vulnerability is in a library rather than the primary software (e.g., Apache Log4j). This can significantly shorten the time of risk identification, allowing resolution or remediation efforts to begin sooner.

How to Generate an SBOM

First off, hopefully your software vendors will provide SBOMs for layers info which are beyond your visibility. For example, it is not always possible to generate an SBOM from a resulting binary for the compiler used to create it.

Also, it is important to invest in automation. Software is a moving target. When it is updated or new packages are installed, SBOMs need to be gathered, created, or regenerated to maintain awareness of the inventory as a whole. Automating this process, especially during software development will reduce adoption pains caused by additional overhead.

Tools

The following tools may be used to generate SBOMs for software you create or artifacts you receive (such as Docker images).

My favorite among these is syft for its versatility and compatibility, but others from this list may be useful for specific reasons, such as better integration into your environment. This list is not exhaustive; there are many other tools in this space. Also, these tools are specific to creating SBOMs. There are many others that are more of a toolkit for software security in general.

Example

In this example, an SBOM in the syft JSON format is being created from a Docker image (mcr.microsoft.com/playwright/python:focal). The output is then viewed in jless. (For more information on working with data in JSON format, read this blog I wrote on the topic.)

Figure 1 - Creating an SBOM via syft From a Docker Image

The process for creating an SBOM for a directory is very similar. The command looks like this:

syft packages dir:path/to/walk

Need an SBOM for infrastructure such as the operating system of a virtual appliance? Point syft at the root of the drive:

syft packages dir:/

How to Utilize SBOMs

One-Off Scanning

There are times when you want to analyze a single SBOM for vulnerabilities. For example, it can be helpful to analyze individual SBOMs during your software procurement process. Or if you are a developer, you may want to analyze the state of your software after updating dependencies. For those times, here are a couple of suggestions:

grype

Anchore, the creator of syft, has another useful tool named grype. Like syft, it is very versatile and in fact, it uses syft for SBOM-related operations under the hood. With grype, you can analyze a directory, a container image (in several formats), or an SBOM (in syft, SPDX, or CycloneDX format). It builds a vulnerability database on-disk from a variety of publicly available vulnerability data sources. The output from grype is very utilitarian. It is perfect for automated tooling, providing output in a variety of machine-readable formats.

bomber

bomber can read all three SBOM formats mentioned in this blog (CycloneDX, SPDX, syft). It requires an SBOM to perform its scan, so pairing it with something like syft works well for images or directories. While it only queries a single vulnerability database (OSV) by default, it also supports Sonatype OSS Index (with a free sonatype account) or snyk Vulnerability DB (with a paid snyk account). The standard output of bomber is very elegant. And even better, it will output an HTML file that may then be shared, for example as an email attachment.

Aggregation

As you may have guessed, SBOMs can pile up quickly. From those for software packages, to those for all of their libraries, not to mention those for the infrastructure you install them on. A plan needs to be created to corral SBOMS, leverage them, and monitor them against the ever-changing threat landscape. Here are two excellent tools to help you do just that:

GUAC

GUAC is able to ingest many types of artifacts. These currently include SBOM (in CycloneDX or SPDX format), SLSA (Supply-chain Levels for Software Artifacts), In-toto ITE6, OpenSSF Scorecard, and Dead Simple Signing Envelope. These are composed to create a graph that can be queried for any aspect of the related documents. A good example of how to combine the graph with the OSV Certifier to then be able to query for Log4j vulnerabilities is in the Setup + Demo document. GUAC is in early stages, so they are looking for contributors. It can be a useful data exploration tool, but it has a long way to go before a good interface is created and wrapped around it.

OWASP dependency track

OWASP dependency track is a common dashboard to continually track and analyze SBOMs for a variety of uses. It is an excellent place to aggregate all your SBOMs. Even better, it has good notification support and integrates with all the top chat applications as well as email. Continuous Integration support for your software pipeline (where SBOMs should be generated for any software you create) is provided by a couple of available CI/CD system plugins, or by a very robust API. Once uploaded, vulnerabilities can be triaged to create an overall perspective of your current software security landscape.

Utilization

Having your SBOMs available can help answer a multitude of questions more quickly than manual effort. They can provide deeper insight into corners that vulnerability scanners cannot access. And having SBOMs continually checked against newly discovered and released vulnerabilities can shorten your mean time to remediate (MTTR) considerably.

Thought Exercise One

As a thought exercise, let us imagine (or, for some, remember) a situation like Log4j, which is a good example for this first exercise because it was a vulnerability in a library used by applications. Without SBOMs, the questions must be posed to the developers of the application. There is inherent lead time in those application developers reading the questions and responding. Furthermore, using different versions of the application could cause the questions to multiply. In the case of a vulnerable application, this also splits the developers' attention away from updating the application to address the vulnerability. All this manual work and communication lag creates unfortunate overhead and lead time.

Now, let us imagine the same situation, but the application has been shipped with SBOMs. You are able to query the SBOMs and compare them to the vulnerability disclosure to determine if the application was vulnerable, without needing to ask the application developers or go spelunking for files to compare against versions. Even better, if you have continuous monitoring of vulnerabilities being compared against your available SBOMs, you would likely be notified automatically.

Continuously monitoring your collection of SBOMs shortens the time to remediation more than anything else you can do because you'll know if you are vulnerable without even asking.

Thought Exercise Two

Let's do another thought exercise. For this one, we will reduce the scope a bit. Let's think of a situation like the Sunburst backdoor in the SolarWinds Orion Platform. The scope is smaller because there is a known version range susceptible to exploit, so we do not need to go all the way to the application developers for answers. The vulnerability check is much more straightforward. Are you running a vulnerable version of the software? Even a half decent software inventory solution will be able to answer that. But the more important question (especially during incident response) is: How long were we vulnerable? This question creates the window for your remediation efforts and pivotally shapes the size of the effort required to ensure business continuity.

So, the manual work begins. You must decide if you are going to launch a full investigation of all of the indicators of compromise across your entire environment. Or you can first attempt to identify when and where the software existed over time and focus your efforts there.

The situation looks much different if SBOMs are available and have been aggregated. You can quickly identify the versions and where they are deployed. In fact, if the SBOMs are continuously monitored, the answer may already be in your inbox. Again, the time to remediation is drastically shortened.

Thought Exercise Three

How about this? You are new to an organization and are in change of shoring up security. Your first task, obviously, is to survey the landscape. You need to know what you have. Then you need to calculate your vulnerability exposure so that you can prioritize your time and effort to ensure the biggest positive impact.

Without SBOMs, you must do this with other tools that aren't quite fit for the job. Or even worse, you must do it manually.

You can drop SBOMs into something like OWASP dependency track and know within the first hour where to find the greatest weaknesses in the system.

Thought Exercise Four

Or maybe you are in charge of software procurement for an organization. How would you size up the security of a new piece of software considered for purchase? There are many good ways to do this, and an analysis of a provided SBOM only increases your visibility. Using a tool to scan a provided SBOM can let you know what you are getting into and can even help guide questions relating to how the vendor secures their software supply chain during the procurement process.

Closing Thoughts

SBOMs are not going away—they become more integral to a successful information security program with every degree of separation from software creation. If you haven't already, there is no better time than now to begin collecting (or creating) SBOMs for your environment. And remember, SBOMs are not static, so they are worth the time investment for automation. That automation and forethought can save you valuable time when the next tsunami of software exploitation hits.

Thanks

This blog would not have been possible without the following people:

Reference

References not directly linked in the blog: