Software Bill Of Materials (SBOM) Explained: Why SBOMs are essential for cybersecurity

SBOMs are a valuable asset for:

• Regulatory compliance

• Compatibility between old software packages and OSS updates

• Customer protection in software supply chain cyberattacks

• Security protections in mergers that involve software and licensing

Difference between SBOM and CBOM

The 2018 Cybersecurity Bill of Materials (CBOM) covers both software and hardware within one Executive Order. SBOM only documents the software components within the code, as well as its history of versions, patches, licenses, updates and changes.

Why are SBOMs important for cybersecurity?

Cyberattacks targeting the software supply chain are increasing. More than half of these attacks come from established advanced persistent threat (APT) cybercrime groups. Their goal is to take advantage of user and supplier trust in their systems.

What makes the supply chain susceptible is the lack of transparency surrounding cyber incidents. In some cases, developers aren’t aware of possible vulnerabilities, and in turn, users could be vulnerable as well. Open source libraries are dependent on other software components. Cases like the Log4Shell vulnerability are an example of a component (in this case, a logging library) that many developers never bother to check because it isn’t a direct software dependency, but rather a transitive one that is depended upon by other components.

While development teams already recognize the need for application security, SBOMs are bringing additional visibility into software supply chains and potential vulnerabilities. When users know where vulnerabilities could be hidden within a software product — and know the components of the software, especially if theyare open source — they are better equipped to deploy security tools to detect and address potential attacks.

If a cyberattack occurs, the SBOM can be used to identify which software has vulnerable components and the type of risk that is involved. This allows users to work with developers to come up with a patch or other mitigation solution.

SBOMs Executive Order 14028

Before Log4Shell, other cyber incidents like the SolarWinds supply chain attack and the Equifax incident related to Apache Struts showed just how vulnerable government agencies, as well as large enterprises and businesses, are across the critical infrastructure. It also showed how dependent all organizations are on the software supply chain, and that one exploited vulnerability can have a widely cascading effect.

Executive Order 14028 requires government agencies, including National Institute of Standards and Technology (NIST), National Security Agency (NSA), Office of Management and Budget (OMB), Cybersecurity & Infrastructure Security Agency (CISA), and the Director of National Intelligence (DNI) to develop standards and best practices to improve security in the software supply chain. The guidelines include:

• Criteria to evaluate software security 

• Criteria to evaluate the security practices of the developers and suppliers themselves

• Innovative tools or methods to demonstrate conformance with secure practices

By February 2022, NIST and the other agencies will release guidelines for software supply chain best practices, in the meantime check out our list of supply chain security best practices you can implement today.

When should you use a Software Bill of Materials?

For each new release of a software component, a new SBOM should be created. Likewise, for every change to a component, the SBOM should be updated to match the changes.

The NTIA baseline for an SBOM requires the following information:

• author name

• supplier name

• component name

• component hash

• version string

• identifier

• relationship

To meet the baseline requirements, SBOM standards were developed to offer a common format that can be used across multiple tools. These standards are:

• SPDX: Software Product Data Exchange is an open standard for communicating the components, licenses, and security information in software packages. SPDX standardizes multiple services, each with its own SBOM.

• SWID: Software Identification Tags are standards that define a lifecycle. The tags are added to the endpoint as part of the software installation process. There are four tags: Corpus tags used in the pre-installation phase; primary tags that provide the product name and is considered a global unique identifier; patch tags that describe any patch applied to the software; and supplemental tags for any additional information.

• OWASP Cyclone DX: A lightweight SBOM standard used for supply chain component analysis and application security.

• VEX: Vulnerability Exploitability Exchange offers additional information about the product, specifically identifying vulnerabilities found in components and recommending actions for remediation.

SBOMs and the integrity of the software

SBOMs are structured to determine the integrity of the software supply chain and allow for risk assessments based on the information gathered. As a high-level assessment, SBOMs are for inventory of software components within the supply chain. But as the standards are applied, SBOMs meet the compliance standards of OSS. For example, the SPDX standard identifies the licenses of those components and is used to ensure license compliance.

Supply Chain Levels for Software Artifacts (SLSA) is a set of standards and controls that aims to help maintain the integrity of open source software artifacts within the supply chain. Launched by Google, it meets NIST recommendations for supply chain security. SLSA complements SBOM in its efforts to protect the large swath of open source software used across the development process.

Using SBOMs to find dependencies and vulnerabilities

The main security purpose behind SBOMs is to identify vulnerabilities and risks throughout the software supply chain. Data surrounding vulnerabilities changes constantly as components are added or changed, introducing potential new exploits. SBOMs are basically static, so the data used to create SBOMs is constantly shifting and evolving.

An SBOM is a tool for software customers who want to perform a vulnerability analysis and see if developers are updating dependencies to decrease risk. But not all vulnerabilities present the same level of risk — some pose no risk at all. To address this issue NTIA offers two steps:

• On the development/supply side, there must be a determination of the vulnerability’s impact, specifically, whether or not it will affect specific areas of the software.

• Information about the vulnerability must be well communicated through SBOM data, with verification that the vulnerability does not add risk.

SBOMs for supply chain security

SBOMs add security to the software supply chain in the following ways:

• Greater visibility across the software product, including system relationships

• Information sharing about vulnerabilities

• Better communication across the supply chain, from developer to user, making it easier to identify security risks

• In-depth records of compliance standards and audits

The SBOM is an evolving security tool to provide greater protection and risk detection across the software supply chain. With more accurate and detailed information about each component in the software, the SBOM offers opportunities for vulnerability discovery early in the software production lifecycle, and in turn, allows for mitigation before any damage is done.

Snyk can automate the process of building an SBOM, enabling organizations to more easily track the open source components and dependencies they use. Snyk can also scan these individual components to find potential vulnerabilities and offer actionable recommendations to remediate them.