Software Bill of Materials, or SBOMs, have finally been recognized as an essential tool for cybersecurity. SBOMs and cybersecurity go hand in hand. In this article, we will review what an SBOM is and why they are required for a strong cybersecurity strategy.
Defining Software Bill of Materials
What are SBOMs?
Software Bill of Materials (SBOMs) are used to document the source code, library and package dependencies, and the licenses consumed by the compiler or packager used to create a distributable artifact. The SBOMs are JSON or YAML files that live side-by-side with the built artifact.
Software Bill of Material is required to take the next step in supply chain security, the vulnerability scan. To know your vulnerabilities, you need to know what code, library, and package dependencies to scan. So SBOMs become the first level of defense required for all downstream reporting.
Why are SBOMs Important for Cybersecurity?
SBOMs are the first level of defense against cybersecurity threats. Specifically, SBOMs expose software libraries that your developers consume from open-source and third-party packages like compilers and languages. You cannot defend yourself against source code hacks if you don't know all of the packages that your software consumes. This level of insight into your application dependencies is why SBOMs are an absolute must for preventing cyber security attacks coming from external code your teams use.
Adding SBOMs to Your Cybersecurity Strategy
Here are 3 reasons for adding SBOMs to your cybersecurity strategy:
- An SBOM is the only way to get a list of all the package dependencies used to create your artifact. This level of SBOM shows source-to-artifact dependencies exposing what open-source and third-party libraries you consume.
- The list of dependencies can become the foundation for zero-trust policies. The SBOM will show if a package you are using has been signed. If not, you may not want to use it.
- Signing confirms the creator’s identity and how it was created – provenance/attestation.
- The signature is used to determine if the package was tampered with. By comparing the signature with the creator’s identity, you can confirm they match.
- The creator’s information to report an issue.
- SBOMs expose the license information and prevent you from agreeing to something you will regret by using it.
And finally, if you are in a highly regulated industry that services the US government, SBOMs are now a requirement for every release. In May 2021, President Biden issued the Executive Order on Improving the Nation’s Cybersecurity and directed the Department of Commerce (in coordination with the NTIA) to publish the minimum elements for a Software Bill of Materials (SBOM). The Executive Order states: “An SBOM advances transparency in the software supply chain, similar to a ‘list of ingredients.’ NTIA is directed to publish a list of ‘minimum elements for an SBOM.’”
This order served as an advisory for federal software suppliers and has created a ripple effect for both enterprise software providers and users.
SBOM Formats Examples (SPDX and CycloneDX)
With the complexities of software, the adoption of SBOMs (software bill of materials) is on the rise. Despite the rise of use, many organizations are still unfamiliar with the current SBOM formats.
What Are SBOM Formats?
SBOM formats are standards that define a unified structure for generating SBOM and sharing them with end users. These formats describe the composition of software in a common format that other tools can understand.
Common Formats
CycloneDX and SPDX are the two popular formats for Software Bill of Materials.
- CycloneDX has a viewpoint of SBOMs from the OWASP world.
- SPDX has a viewpoint originating from a license consumption model.
In terms of SBOM formats, CycloneDX and SPDX achieve the same result. These formats document what is used to create an artifact by digging into obfuscated transient open-source dependencies.
CycloneDX
CycloneDX is a modern standard for SBOM with a viewpoint of SBOMs from the OWASP world. It is a lightweight Software Bill of Materials (SBOM) standard for application security contexts and supply chain component analysis.
Using CycloneDX, supplier, manufacturer, and target component, tools used to create the BOM, license information for the BOM.
SPDX
SPDX is another SBOM format with a viewpoint originating from a license consumption model. It is an open standard for communicating SBOM information. This information includes components, licenses, copyrights, and security references. It is designed to streamline work and improve compliance by providing a common format to share data.
Differences Between CycloneDX vs. SPDX
How do these two formats stack up? Understanding the difference between these common SBOM formats is important. Here is a breakdown of each format and how they are different.
| CycloneDX | SPDX | |
| Description | CycloneDX is a lightweight SBOM standard for application security contexts and supply chain component analysis. | SPDX is formed with the intent of creating a common data exchange format for information related to software packages for sharing and collection. |
| Terminology used | package | component |
| Supported formats | CycloneDX supports XML, JSON, and protocol buffers and get source code on GitHub. | SPDX supports RDFa, .xlsx, .spdx and expands into other formats such as .xml, .json, and .yaml. There’s an online tool and GitHub repository. |
| Support | supports referencing components, services, and vulnerabilities in other systems and BOMs as well | |
| What it is | BOM Metadata, Components, Coordinates (group, name, version), Package URL, Common Platform Enumeration (CPE), SWID (ISO/IEC 19770-2:2015), Cryptographic hash functions (SHA-1, SHA-2, SHA-3, BLAKE2b, BLAKE3) Extensions: extension points to support future use cases and functionality | SPDX Document Creation Information, package Information, file Information, snippet Information, other licensing information detected, relationships Between SPDX Elements, Annotations |
| Features | CycloneDX can only be used to track the software components in a project. | SPDX tracks the software components in a product and shares information about the software components with other developers, buyers, and sellers. |
Between CycloneDX and SPDX formats, you will recognize an overlap in terminology with a different overall structure in the file formats. See https://cyclonedx.org/specification/overview/ and https://spdx.dev/specifications/
These schema definitions equate to a series of tables and relationships between the tables in the RDBM world. The CycloneDX JSON structure and documentation are easier to understand and follow. SPDX goes into much more detail, but the examples are XML snippets. With SPDX, there is no single view of the whole spec represented as a single YAML or JSON file.
SBOM Key Concepts
SBOM Management
SBOM management is the process of tracking Software Bill of Material reports as they are generated across the DevOps pipeline.
SBOM Automation
SBOM automation automatically generates a list of all software components, libraries, and dependencies that make up a software application as part of your DevOps Pipeline and then consuming the data.
Federated SBOMs
View an SBOM with Federated data from multiple components, making up a ‘logical’ application.
SBOM Consumption
SBOM consumption is the process of analyzing and utilizing the data contained within an SBOM document.
Challenges with SBOMs and Cybersecurity
While Software Bill of Materials is critical to our overall cybersecurity practices, they are not perfect. Here are the top challenges with SBOMs and Cybersecurity.
- SBOM data is not consumed or federated.
- Vulnerabilities of tools
- Lack of signing of the SBOM
- Immutability
- Tracking
1. SBOM Data is Not Consumed or Federated
SBOMs are not useful if the data they generate is not consumed or aggregated up to the organizational level.SBOMs and cybersecurity become more complex in modern architecture, where hundreds of components are used to create a single application. In this case, an SBOM is generated for each unique component. For this reason, there is no easy way to show a ‘federated SBOM‘ of all components used in a single application.
2. Vulnerabilities of Tools
Another issue is the tools to generate SBOMs have vulnerabilities themselves. The vulnerability resides when the tools run, post-build or post-packaging. SBOM generators use files that the compiler or package program creates, such as Rust’s cargo.lock, NPM’s package-lock.json, or an apt-cache. The gap between the build and SBOM creation provides a hacking opportunity where the SBOM report can be manipulated, resulting in untrue SBOMs.
3. Lack of Signing of the SBOM
Other challenges include the lack of signing of the SBOM, so we know the provenance in the SBOM report. The signing process is critical for SBOMs and cybersecurity.
4. Immutability
The biggest challenge is the mutability of the SBOM files. With SBOMs and cybersecurity, it is important to show history over time without the ability for someone to manually update an SBOM. Software Bill of Materials files can be edited without any trace, allowing the data to be manipulated. For example, hackers can easily update an NPM package-lock.json prior to your NPM SBOM generation. By doing so, they can disguise any hack in the SBOM. Immutability becomes an issue at all levels of SBOM generation.
5. Tracking
What was the SBOM generated for, a microservice or an entire application? In traditional development, an SBOM is created at the point in time when the application version’s artifacts are created, giving us an SBOM based on that application version. In microservices, each service is built and deployed independently. An application is a logical collection of microservices. Application versions are created when an underlying microservice version is updated. So how do we track application-level SBOMs when the application is only a logical representation and never built as a complete unit?
Download the whitepaper to learn more about managing SBOMs in a Microservices Architecture.
Get the Whitepaper
Understanding the Different Levels of SBOMs
Multiple Software Bill of Materials are produced at different levels of the software stack. The following levels are needed to have a complete audit trail of the entire supply chain used to create a single artifact (microservice, binary, library, etc.):
Complete Software Bill of Materials Stack
Hardware SBOM
At the lowest level, the supply chain starts at the underlying hardware used, for example, the processor type (amd64 vs arm64). Yes, this level of the stack can also have vulnerabilities. However, this information is not currently gathered by default, even though the SBOM schema can store it. In CycloneDX this data is stored as Components.
Knowing the hardware used by your build is essential in recreating an artifact. For example, tools in the future may use a ‘consensus build networks’ where all machines must be identical, starting at the lowest level. The hardware SBOM is the way to confirm this level of parity. Check out JFrogs Pyrsia open source project for a consensus build network.
Operating System SBOM
The next level of the supply chain is the OS. We need to know the underlying operating system packages installed on the build machine. These operating systems packages affect how the compiler and packagers produce their artifacts and impact the ability to reproduce a build. It could also introduce vulnerabilities from old OS packages still being consumed. OS SBOMs are not currently gathered by default, even though the SBOM schema can store them. In CycloneDX format, this data is stored as Components.
Compilers SBOM
The software compile translates source code into objects. To create a source-to-object parity, we must know what the compiler consumed for input and produced as output. Unfortunately, Software Bill of Materials at this level do not exist outside of commercial build tools such as OpenMake Meister and IBM Rational ClearCase (ClearMake).
Most build scripts that produce a ‘build audit’ report on the files found in the ‘local’ build directory and not based on what the compiler used. These files are pulled from a source repository (git directory) and listed as the source SBOM. However, the ‘local’ build directory is not the only place where the compiler will find files. If we are to be accurate in our SBOMs we cannot miss files. Software Bill of Material must include all files, even when managed outside your versioning tool. In other words, it must be done at compile/link time to be accurate.
In the future, compilers must be updated to produce SBOMs as standard output with the ability to control the inputs and outputs carefully. OpenMake Meister achieved this control using of a Search Path and generated Build Control Files. Another approach is to monitor the file system for reads and writes by the compiler, like ClearMake. The concepts of the GnuMake VPATH, with a ‘first found’ reference is as relevant today as it was 30 years ago.
Transitive Dependencies SBOM
Transitive dependencies happen when A depends upon B and B depends upon C. C is a transitive dependency to A. SBOM tools will rely on the compiler or packager to output the transitive dependencies, or they will be determined using a recursive lookup. Most Software Bill of Material at this level is accurate and represents where most teams have focused their attention. Transitive Dependency SBOMs are critical as they expose open-source packages.
Packagers SBOM
Packagers, such as NPM, docker build, and dpkg-deb, pull together files and artifacts into an installable package based on a scripted configuration file. They produce two outputs, the package, and the package dependency file. A package dependency file, like package-lock.json or cargo.lock, are example outputs of the packager.
Some Package SBOMs at this level may contain source code dependencies based on the programming language, packager, and SBOM tools used. Like the compiler SBOMS, the package SBOM may only reference files from the ‘local’ build directory, ignoring all other file locations.
Application SBOM
Application SBOMs aggregate together all of the lower Software Bill of Materials into a single view. Tools such as DeployHub and Ortelius snapshot all available SBOMs for each artifact in the supply chain. When consumed by an application, the Software Bill of Materials data is aggregated to the logical application level, creating an Application SBOM.
Without this aggregation ability, we lose the application level SBOM.
Tooling to Make Software Bill of Materials Accessible
Tooling makes Software Bill of Materials accessible. While your team may be doing a great job of generating the different levels of SBOMs for each build, we are far from finished. We need the ability to see the information so that it can be used and acted upon by multiple team members. And the SBOM information must have immediate relevance. After all, what good is a microservice’s SBOM if we have no insight into which applications are using the service?
Maturing in the use of SBOMs will drive the need to aggregate the data and display the information in a way that is easy to read and useful to all. The first step is finding an easy way to associate the generated SBOMs based on the artifact in a simple dashboard view. Unfortunately, we cannot expect everyone to know where the last build was executed and where the SBOM data lies.
Secondly, in a microservice architecture, we need a method of aggregating SBOM data up to the ‘logical’ application level. This aggregation requires tooling that can define a ‘logical’ application and build relationships between the microservices (or any component) and each ‘logical’ application version.
Federating all SBOM Data with DeployHub
In a cloud-native microservices architecture, your SBOMs are generated and managed at the microservice level. Microservices are pushed across your continuous delivery pipeline independently and frequently. Every time a new microservice is updated, all of the consuming ‘logical applications’ have a new version with a new SBOM and CVE report. Developers, DevOps Engineers, and Security teams struggle to keep up with the changes and cannot easily provide SBOM and CVE reporting for all impacted applications. The result is the absence of governance, or a historical audit trail of the changes pushed to end users.
DeployHub’s SBOM automation tool solves this problem by centralizing the ‘evidence store’ data and continuously aggregating the information to the critical level, the ‘logical application.’ DeployHub provides you with a working federated SBOM report every time a new application ‘release candidate’ is created. DeployHub provides the insights needed to harden the security of the software your end users consume.
Aggregated Application SBOM and CVE
DeployHub is based on the Ortelius open-source project incubating at the Continuous Delivery Foundation.
Conclusion: SBOMs and Cybersecurity
As you can see, there are many places where hackers can manipulate artifacts and Software Bill of Materials. OpenSSF is working to secure this process by implementing signature tools like Sigstore and Notary v2 for signed artifacts, packages, and SBOMs. JFrog is working on an open-source solution called Pyrsia for implementing consensus-based build networks that minimize hacked build machines.
DeployHub is working on Ortelius, a unified governance catalog for tracking microservice SBOM data based on versions and aggregating all of the SBOMs based on a logical application. It will be the task of all to begin building this level of audit control into our DevOps pipelines and acting on the DevOps intelligence continuously. In other words, much investment is now going into solving the security problem.
For additional information on SBOM’s read the report from National Telecommunications and Information Administration (NTIA).
Further Reading on Supply Chain Security:
- Application Security Best Practices for Your DevOps Pipeline
- Software Supply Chain Risk Management
- Microservice Catalog Tool
- Consolidated Software Composition Analysis