Understanding Software Bill of Materials (SBOM): Enhancing Transparency and Security in Software Supply Chains

What is SBOM? What does it have to do with the Executive Order on Improving the Nation’s Cybersecurity (Executive Order 14028)? Is my software supply chain compliant? How do I make sure my organization remains compliant in the future?

This article answers all those questions and more.

We will explore the background of SBOM and SLSA compliance by reviewing the executive order. Then, we will explain what an SBOM is, what must go into it, and how it benefits your app security. Finally, we’ll discuss ways to implement SBOMs into your pipeline and gain SLSA compliance—all without your developers needing to leave their development environment.

1. Executive Order on Improving the Nation’s Cybersecurity

In May 2021, the White House released Executive Order 14028, Executive Order on Improving the Nation’s Cybersecurity. This partially came as a response to a significant security breaches organizations like SolarWinds and CodeCov, and partially as a response to the growing number of malicious cyber actors (MCAs) targeting developers.

The order tasked several groups to begin developing a new set of software security standards, tools, and best practices. It included a yet-to-be-defined category known as “critical software”. It also got rid of some barriers between government agencies to share cybersecurity threat information. Beyond improving the cybersecurity of the federal government’s systems, it also tasked private businesses and academia to begin enhancing software supply chain security to follow best practices as set out by NIST, the National Institute of Standards and Technology. Additionally, a review board was set up to review and assess cybersecurity incidents, and a playbook was created to dictate the federal government’s response to incidents.

Most significant for the field of software development may be a requirement for federal agencies to implement “zero trust” architectures, accelerating migrations to secure cloud and adopting other data protection capabilities—plus related endpoint detection, response, and logging—to mitigate continuing supply chain risk.

Most important to businesses were the promise of new best practices and standards for software supply chains. At the time of the order, it became clear that new compliance standards were coming, though it was not yet clear which shape they would end up taking.

What ended up occurring, was the maturation of a relatively new concept known as the Software Bill of Materials (SBOM), a requirement to participate in vulnerability disclosure programs, and a requirement to demonstrate conformance with the best security practices.

2. What is an SBOM?

While the idea of a Bill of Materials (BOM) that conveys the components and their provenance within a product is by no means novel, what was new was the idea of developing a standard to apply to software and software supply chains throughout the nation.

Many manufacturing companies are already required to provide a BOM that details every part of a product along with its original manufacturers if it came from a third party. A common instance that BOMs help the consumers is in the case of a vehicle recall. If a car is shipped with a faulty part, the makers can quickly know which part it is, where it came from, and how to fix or replace it. The same concept applies to SBOMs.

As the National Telecommunications and Information Administration (NTIA) states, “an SBOM is a formal record containing the details and supply chain relationships of various components used in building software.” It provides a detailed inventory of all the parts contained within the software, including open-source libraries, third-party components, and proprietary code. This transparency helps organizations manage their supply chain, identify vulnerabilities in a preventative manner, and response to security incidents faster.

The promise of SBOMs are that an up-to-date and comprehensive Bill of Materials ensures high-quality code, compliance with regulations, and security from attack.

3. Minimum Components of an SBOM

Because of the fast-moving and evolving nature of both the situation and the technology, the minimum requirements of an SBOM were originally kept simple and flexible by the NTIA.

• Data Fields: SBOMs must include the baseline information about each component. This includes a data field for each component including supplier name, component name, version, dependencies, author of the SBOM data itself, and timestamp. This information sets components apart from one another and makes them easier to track.

• Automation Support: Due to the nature of CI/CD pipelines, SBOMs should support automation. Thus, SBOMs can be read and generated by machines and scale across one’s ecosystem. This led to a standardization of their formats as well, with the three acceptable formats being Software Package Data eXchange (SPDX), ClycloneDX, and Software Identification (SWID) Tags.

• Practices and Processes: Lastly, the NTIA has a list of practices and processes for organizations to follow. They include a standard that a new SBOM must be created whenever a software component is updated in a new build or release, that they should be distributed and delivered in a timely fashion, and that they must be access-controlled.

4. Main Benefits of SBOMs

Here are the primary ways that SBOMs help an enterprise-level organization:

1. Enhanced Software Security: Since SBOMs provide a comprehensive inventory of all software components used in an application, organizations can quickly identify and address security vulnerabilities. By tracking known vulnerabilities and applying patches, organizations can improve the overall security posture of their software.
2. Risk Mitigation in the Supply Chain: With SBOMs, organizations gain visibility into their software components. This assists in assessing risks in the supply chain and making informed decisions about hardening and patching. Essentially, having an SBOM streamlines the process of identifying which components need security patches and updates.
3. Regulatory Compliance: SBOMs help organizations be compliant with current and future guidelines when it comes to cybersecurity.
4. Improved License Management: SBOMs help organizations understand the licensing requirements associated with each component. This aids in ensuring compliance with open-source licenses and other licensing obligations, thus preventing legal issues related to software licensing.
5. Transparency and Trust: SBOMs allow for transparency in software development practices, fostering trust among customers, partners, and stakeholders. Demonstrating a commitment to security and accountability can be a competitive advantage for enterprise-level organizations, especially when cybersecurity incidents are common.
6. Incident Response: If a security incident or breach does occur, having an SBOM allows organizations to quickly assess the potential impact and take appropriate remediation measures.

5. SLSA Compliance

Related to the federal government’s executive order on cybersecurity, other organizations like have been hard at work determining best practices for software supply chain security. One prominent development has been SLSA 1.0, which stands for Supply-chain Levels for Software Artifacts, originally created by Google’s security team and developed by OpenSSF. SLSA works with the security efforts being made throughout the industry to secure the software supply chain using SBOMs.

Think of it this way: SBOM and SLSA are two complementary tools that can be used to improve the security of software supply chains. They should be used together to provide a comprehensive view of the security of a software supply chain. SBOM can be used to identify potential vulnerabilities, and SLSA can be used to ensure that those vulnerabilities are mitigated.

At the highest SLSA level, organizations are required to provide an SBOM that includes information about all the dependencies of their software artifacts. This information can be used to track the provenance of software components and to identify potential security vulnerabilities.

This framework aims to not only help organizations achieve and maintain compliance with security regulations, but also standardize improved security above and beyond the minimum requirements. Many large-scale organizations are beginning to adopt SLSA 1.0 so they can rest assured in the security of their software supply chain.

6. Implementing SBOMs

Because of the minimum requirements for SBOMs, solutions must support automation, include certain data fields, and follow a set of best practices.

Ideally, implementing SBOMs would look like finding an organization that could:

1. Scan your software composition to determine data and dependencies.
2. Automatically generate SBOMs that adhere to all current requirements in addition to current best practices for software supply chain security.
3. Continuously monitor your CI/CD pipeline for vulnerabilities and unauthorized access.
4. Offer end-to-end application security including hardcoded secrets detection, source code protection, data orchestration, and code-to-cloud coverage so that in addition to meeting compliance standards, your application is fully protected.

At Cycode, we have such a solution. Find out more here.

Summing Up

Due to the rapidly evolving technology and regulation landscape, businesses can best respond to the executive order by learning everything they can about SBOM, staying up-to-date on NTIA and NIST guidelines, and embracing the latest cybersecurity solutions.

With Cycode, enterprises can generate SBOMs automatically and gain access to a wealth of other protective features. We’re the application security platform that puts security-first while remaining developer-friendly, a commitment we demonstrate with our runtime solutions. Learn more here or book a demo!