One of the most important and clear-cut SBOM (software bill of materials) use cases is security. Up-to-date, accurate SBOMs can help software producers understand not only if their applications directly include vulnerable components, but also whether they’re acquiring security risk from third-party software suppliers.

Additionally, SBOMs can be used to communicate whether vulnerabilities are actually exploitable in the real-world product context, and some SBOM tools even provide vulnerability remediation guidance.

In this blog, we’ll discuss five specific ways an SBOM (and certain tools that organizations use to create and manage them) can improve security for your organization.

1. Providing Visibility into Open Source Vulnerabilities

Modern applications are generally built with numerous open source components. Well over 90% of applications use at least some OSS, and the average application depends on hundreds of open source components. Given this volume of open source, it’s important to stay on top of vulnerabilities that may impact your software.

Organizations can use an SBOM to improve visibility into open source vulnerabilities in several ways:

  • By searching for vulnerable components and versions: Although the data fields in an SBOM can vary depending on the organization (and method) used to generate it, most SBOMs will include component name and version. If and when a new vulnerability is discovered, you can search your SBOM(s) to see if you are using the vulnerable version of the component.
  • By leveraging the tool used to create the SBOM: Different SBOM tools work differently, so, for the purposes of this blog, we’ll explain how this works in the FOSSA platform. When you use FOSSA to inventory your software components, our tool will surface open source vulnerabilities in the “Issues” tab of your dashboard. The “Issues” tab also provides important content — CVE number and description, vulnerability severity, dependency depth (i.e. direct dependency vs. transitive dependency), whether a fix is available, and remediation guidance.

2. Improving Software Supply Chain Transparency

SBOMs do more than just help organizations understand their open source and first-party code. They can also provide important visibility into the composition of third-party, closed-source software.

By requesting software suppliers to produce SBOMs along with each product — and having a mechanism for keeping those SBOMs up to date — organizations can understand and take action on software supply chain security issues. Of course, importing and analyzing third-party SBOMs at scale will require automation, so we recommend asking suppliers to provide SBOMs in a machine-readable format like SPDX or CycloneDX. These should contain unique component identifiers such as Package URL (PURL).

Once you receive an SBOM from a third-party supplier, you can begin to analyze it. This can theoretically be done via manual review, but, more commonly and practically, organizations use automated tooling to do it. For example, if you import a third-party SBOM into FOSSA, our tool will scan the SBOM and surface vulnerabilities in the “Issues” tab.

3. Enabling VEX

VEX (Vulnerability Exploitability eXchange) is a set of formats that are intended to help organizations understand whether a vulnerability is actually exploitable in a given product. Although thousands of new vulnerabilities are reported each year, the vast majority of them aren’t attackable. VEX was created to account for this fact and ensure organizations don’t waste precious resources mitigating vulnerabilities that won’t impact them.

There are several scenarios where a vulnerable component may not be exploitable: these include when the vulnerability isn’t accessible to attackers, when a vulnerable module of a multi-module library isn’t included in the product, and when inline mitigations have already been made, among others.

Software suppliers can use VEX to communicate whether the product is “affected” or “not “affected” by a vulnerability — or whether the issue is “under infestation” or “fixed.” Additionally, organizations can use VEX fields to explain why a vulnerability isn’t exploitable, like for one of the reasons mentioned above.

The two most popular human- and machine-readable SBOM formats — CycloneDX and SPDX — support VEX. (In SPDX, you can use an external reference to link to a VEX document. In CycloneDX, you can either directly embed a VEX document into the bill of materials, or you can link to an external VEX document.)

4. Supporting Vulnerability Remediation

As discussed earlier in this post, when you generate or import an SBOM using a modern SCA tool like FOSSA, you’ll see more than a simple list of known vulnerabilities. The tool will also provide remediation guidance.

For example, let’s consider the hypothetical where Version 2.0 of TestPackage is associated with a high-severity vulnerability. And, when you scan your project and generate an SBOM (or import an SBOM from a third-party supplier), you see that you’re using TestPackage 2.0.

FOSSA will provide the following data to help you make a fix:

  • Current Version
  • Partial Fix (if applicable): the version that removes the selected CVE
  • Complete Fix (if applicable): the version that removes all known CVEs

In our example, we see in FOSSA that a complete fix is available for TestPackage 2.0: upgrading to TestPackage 3.0.

Similarly, when you import an SBOM from a third-party software supplier, you’ll also see this type of guidance. The difference is that you likely won’t be able to apply the fix directly, so you’ll instead need to either work with that supplier to address the issue or apply a mitigating security control, such as isolating the supplied software from publicly accessible internet connections.

5. Flagging Components with High Indications of Risk

Although they aren’t necessarily always impacted by vulnerabilities, packages with certain risk indicators can become security issues if not addressed. This “high indication of risk” category includes abandonware (defined as packages that haven’t been updated by their maintainer in two years or more), empty packages (no source files detected in the package), and native binary code (executable code not typically associated with this type of package, which can be used as a vector to cause malicious behavior).

Structured SBOM formats don’t have data fields that specifically deal with these quality issues, although SPDX and CycloneDX support annotations, which, in theory, would allow a software producer to add this context. (But we should note that using annotations to highlight packages with these risk signals is not a common practice.)

However, some SBOM tools (including FOSSA) do flag packages with these potential issues. So, if your organization’s SBOM offers this capability, consider taking advantage of it.

Additional Resources: Using SBOM to Effectively Manage Security

We hope this piece provided an overview of some of the ways an SBOM — and the tools used to create and manage it — can play important roles in an effective software supply chain security program. For more information on using SBOMs in your organization, consider viewing the following on-demand webinars: