SECURITY 101
What is a Software Bill of Materials (SBOM)?
March 22, 2023
This article will provide an introductory overview of what software bill of materials (SBOM) is, why they've risen to prominence, and how you can use them to improve your supply chain security.
Software supply chain security is a developing field that focuses on protecting the development ecosystem. One critical component of your software supply chain is the third-party dependencies your project relies on.
Using third-party code accelerates development, but it can also introduce security risks. This is because such dependencies often contain vulnerabilities that can lead to your code being exploited. These risks aren’t always acknowledged when packages are installed; developers typically view third party software as a time-saving shortcut and may be unaware of the threats that these dependencies can introduce.
Dependency exploits have facilitated some of the most impactful attack campaigns in recent history, including SolarWinds, Kaseya, and Log4j. Organizations were put at risk because these third-party packages contained exploitable vulnerabilities. Typosquatting campaigns have also been used to deliver malicious code to projects, without developers necessarily realizing it.
With third-party dependency exploits increasing in frequency and severity, establishing an effective security baseline is critical. At a minimum, this should provide detailed visibility into the third-party dependencies you're using and the vulnerabilities they contain.
SBOM is an acronym for “software bill of materials.” The term “bill of materials," or BOM, is borrowed from the manufacturing industry where it lists the raw materials, pre-built components, and assembly processes required to build a new unit of a product. SBOMs have a similar function for the software industry.
An SBOM enumerates the assets in your software supply chain. It details all your dependencies, including their name, version, and the source they’re installed from. In addition to providing an overview of your product, this also provides an index of potential threats you face.
Without an SBOM, it's often hard to get a handle on modern software supply chains. A 2023 report from Synopsys looked at 1,700 commercial codebases and found an average of 595 open-source components in each one (up from 528 in 2022 and 445 in 2020). An overwhelming 91% of those codebases used at least one outdated component, while 88% contained components with no activity in the last 2 years.
Discovering these vulnerabilities is challenging when there are so many dependencies to audit across different projects and package managers. An SBOM provides a cohesive, central starting point for analyzing your supply chain and its potentially weak links.
Awareness of software supply chain risks has increased in recent years due to high-profile attacks where compromised supply chain components have resulted in the exposure of internal systems and end users for many companies overnight. SBOM helps bring awareness to the software supply chain components & dependencies themselves.
The 2021 discovery of an easily exploitable flaw in the ubiquitous Java logging library Log4j caused disruption throughout the industry as development teams rushed to check if they were affected. In many cases, their own code did not leverage Log4j, but nested dependencies did.
There have also been several cases of malicious software being published to widely used public repositories under the guise of performing legitimate activity, sometimes doing both to remain covert. In other instances, attackers have uploaded a package using a name that’s similar to popular projects, such as “umbrellaks” instead of “umbrellajs” — also known as typosquatting. In both cases, bad actors are getting creative as to how they attempt to introduce vulnerabilities in source code dependencies.
An SBOM helps to identify the risks in these scenarios so they can be actively mitigated. SBOMs list all your dependencies, making it easier to spot when vulnerable, malicious, or low-quality packages are added. When zero-day vulnerabilities are announced, you can assess your exposure by simply searching your SBOM.
SBOMs aren’t strictly reserved for internal use. In much the same way that food packaging comes labeled with ingredients, SBOMs document your product's composition in a way that's useful to customers as well. Consulting an SBOM lets end users of your product better understand the risks associated with it. It also allows them to assess whether your software is compatible with their own supply chain standard.
The value of SBOMs is being recognized both inside and outside the software industry. As awareness grows, you can expect customers, clients, and users to start requesting you provide SBOMs with your product.
SBOMs provide a detailed description of your software's dependency tree. They list all the packages in your software supply chain and provide essential information about each one:
When generating SBOMs, you should use one of the industry standards to ensure the output is interoperable with established tools. There are currently two prominent ones: SPDX and CycloneDX:
Both standards can be expressed in several different formats such as JSON, YAML, and XML. They differ mainly in how they distinguish types of assets within the supply chain. CycloneDX retains a stronger emphasis on security and compliance, whereas SPDX is purpose-designed to document supply chains.
New SBOM tools are emerging to automate the generation of SPDX- and CycloneDX-compatible SBOMs. Running one of these solutions in your project will generate an SBOM that you can issue to your customers:
After you’ve created an SBOM, you should distribute it with your other release assets. This permits you and your customers to easily discern your software's composition and security posture.
Even small revisions should include an SBOM, regardless of whether you've added or removed dependencies. This ensures there's an accurate historical artifact for each release. Ideally, your SBOM tool should perform automatic scans at a regular cadence to guarantee maximum coverage.
Internally, SBOMs can also be generated for work-in-progress feature branches. Using SBOMs for development work allows you to check whether unsafe dependencies have been added—before they get merged into your main branch. While you would not share this externally as a product overview as it includes development branches, finding and fixing zero-day vulnerabilities within your development sprint prevents exploitable code from being deployed.
SBOMs are difficult to consume as is. The artifact you produce or receive from a vendor will be verbose JSON, XML, or other structured data. Searching the plain text can be laborious.
Fortunately, the software ecosystem is steadily building solutions that make analyzing SBOMs more convenient. Docker now has an integrated SBOM view for container images, for example, and CI/CD provider GitLab is working on a method for automatically parsing and presenting SBOMs generated within your pipelines.
You should verify SBOMs are genuine before you refer to them – a practice known as “attestation.” Each SBOM should have a verifiable signature so you can check it hasn't been tampered with. An attacker that uploads a manipulated SBOM creates a risk similar to an actual supply chain attack, as they could have edited the SBOM to conceal a malicious package.
While customer demanded SBOMs are becoming more commonplace, SBOMs are not strictly mandatory (yet). A September 2022 memorandum from the U.S. Biden administration confirmed that SBOMs "may be required" by federal agencies that leverage third-party software. This follows up on the May 2021 executive order to “improve the nation’s cybersecurity,” which discusses supply chain security at length. The momentum seems to be toward mandatory SBOM.
As is indicated by the recent executive orders, SBOMs may be mandated in the future for security-critical settings such as government agencies.
Moreover, the executive orders suggest that agencies should "consider reciprocity" of SBOMs and produce them in a “usable format” for their intended audience, as SBOMs only add value if the recipient possesses the skills and technical resources to efficiently consume them. Although government guidance goes beyond SBOMs, it’s clear SBOM is becoming a pillar of application security.
These requirements are likely to trickle down from government to enterprise software, as was the case with FIPS, the U.S. government's Federal Information Processing Standards (FIPS). FIPS compliance is mandatory for agencies that need to adhere to the Federal Information Security Modernization Act (FISMA), but it has also been widely adopted in the broader software industry as the basis for effective security audits.
Although SBOMs provide visibility into your dependencies, they're only one part of supply chain security. In fact, it should be clear by now that the SBOM itself does not provide any security; it provides visibility and informs remediation actions that improve source code security. Your overall position is also affected by software that’s not covered by an SBOM. This includes the operating systems you use, as well as any external services such as managed database providers.
For example, an SBOM would tell you whether Log4j is directly embedded in your project, but it won't reveal whether the package exists in neighboring software on your server. Information in SBOMs can be inaccurate too, either because the SBOM itself is outdated or because it's been produced using incorrect information. For instance, package manager lockfile inconsistencies could cause an SBOM to list the wrong version of a package.
Supply chain security also links to other aspects of software hygiene. You need to consider the security concerns of the entire development lifecycle, including developer access management, CI/CD security, and leaked secrets detection, and hardcoded secret detection as a weakness in any one of these areas could allow attackers to manipulate your software supply chain.
Third-party software dependencies are part of your software supply chain and can contain security threats. Because modern software often relies on hundreds or even thousands of dependencies, it's difficult for software developers and consumers to check if vulnerabilities exist.
SBOMs help to solve this problem by providing a standardized index of the components in your project. They let you uncover outdated, unused, and insecure dependencies that could be exploited to compromise your product.
Arnica allows you to generate SBOMs and identify supply chain risks for free. With Arnica, you can produce downloadable SBOM artifacts that provide clear visibility into your dependencies to serve as one aspect of your software supply chain security posture.
