According to Gartner’s prediction, 45% of enterprises worldwide will have faced an attack on their software supply chain by 2025. In most cases, hackers target unpatched vulnerabilities, which can be plentiful, considering that an ordinary enterprise project usually uses hundreds of dependencies.
A software bill of materials (SBOM) is your first line of defense in this scenario. It doesn’t substitute other security mechanisms but enables you to inspect every nook and cranny of your IT infrastructure most conveniently.
This article examines what an SBOM is and what risks you run without it. It also delves into SBOM contents and formats so you clearly understand the data you need to provide or require from your suppliers.
Table of Contents
What is an SBOM?
In short, a software bill of materials is an inventory of all dependencies used to build a software product, which is similar to a traditional bill of materials listing all raw materials, assemblies, and components utilized for product manufacture. A more detailed definition by the National Telecommunications and Information Administration (NTIA) states
“A software bill of materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e., compile and link) a given piece of software and the supply chain relationships between them.”
Note that this list includes open-source and proprietary software regardless of whether it is freely available or has restricted access to customers only. However, an SBOM doesn’t imply disclosure of source code: the code may remain confidential at the vendor’s discretion. To continue the comparison with a BOM: giving a list of materials doesn’t mean revealing the manufacturing processes.
Software suppliers or developers generate an SBOM for their software product and update it with every release. If a vulnerability is found in a component, an SBOM allows for prompt identification of affected software and remediation.
Why do organizations need an SBOM?
The purpose of an SBOM depends on your role. The developers can control the integrity of dependencies in their project, the purchasers can make an informed decision about the product, and software operators can monitor vulnerabilities and react promptly. But in any scenario, an SBOM helps you to face the following challenges of the modern digitalized world:
- Prevent hidden vulnerabilities. About 90% of companies utilize open-source software, and according to Snyk, an average project contains about 49 vulnerabilities in direct and indirect dependencies. Don’t take it as if the issue concerned only OSS, though. Closed-source software also has vulnerabilities, but the data is not made public (which doesn’t prevent hackers from exploiting them). An SBOM increases software transparency — the whole project structure is laid open to you, and developers can immediately see if there are components with vulnerabilities. As a result, the developers can promptly assess the risks and update the software version or take other mitigating actions to protect the system from attacks until the patch is ready.
- Minimize licensing risks. Any third-party code we use in development is licensed. Developers often pull dependencies from public repositories without reading the licensing conditions, which may lead to lawsuits or other unpleasant consequences. For instance, using a GPL-licensed code without the CPE will force you to open your project’s source code, even if it is meant to be proprietary. An SBOM contains information about component licensing, enabling developers to avoid legal risks and protect intellectual property.
- Gain perspective on the state of software components. An enterprise project sometimes makes it hard to keep track of all component versions. As a result, a project may contain outdated components or even libraries that are insufficiently supported or even abandoned. Consequently, security and maintainability risks increase because fixes and patches are late or don’t come at all. An SBOM provides data about component versions, so you can determine whether you use a fresh or outdated dependency.
- Promote vendor accountability. Suppliers of open-source and proprietary software must provide an SBOM with their product, which proves that they ensure the security, licensing integrity, and dependency health of their product. Therefore, if you are a software vendor, an SBOM will give you a competitive edge over those who don’t bother with it. If you are a consumer/purchaser, imagine that software without SBOM is like a food product without a list of ingredients.
- Ensure legislative compliance. The U.S. President’s Executive Order No. 14028 on Improving the Nation’s Cybersecurity dictates that U.S. state agencies must use only software supplied with a software bill of materials. Judging by the growing global concern about cyber threats, this requirement will likely be extended to a broader range of enterprises.
What data an SBOM contains
So what kind of information must an SBOM include? According to the NTIA’s Minimum Elements For a Software Bill of Materials pursuant to the EO 14028, an SBOM must contain the following:
- Data fields include basic information about software components that allows for identification of these components across the software supply chain and mapping to other data sources such as vulnerability databases:
- Supplier name,
- Component name,
- Component version,
- Other unique identifiers (used to identify a component or serve as a look-up key for databases),
- Dependency relationship (reflects the transitivity between software and a component or a sub-component),
- Author of SBOM data,
- Timestamp (date and time of SBOM generation).
- Automation support implies that an SBOM is generated in a commonly used and machine-readable format, which enables companies to integrate SBOMs into their vulnerability management practices, perform auditing, or take advantage of SBOM data in any other way.
- Practices and processes imply that an SBOM is not just a data set generated once and for the product lifecycle. For smooth integration of an SBOM into the corporate SDL (secure development lifecycle) processes, certain elements must be addressed in an agreement to provide an SBOM:
- Frequency: a new SBOM must be created with every software release or update.
- Depth: an SBOM must contain all primary components with transitive dependencies. A customer can specify the depth of transitive steps.
- Known unknowns: if an SBOM doesn’t contain the whole dependency graph, a supplier must specify “known unknowns,” when the presence of dependencies for a component is unknown and incomplete.
- Distribution and delivery: an SBOM must be delivered in a timely manner and have all relevant access permissions and roles.
- Access control: the software supplier and customer should determine through contracts, licensing, or other legal mechanisms whether an SBOM can be made public or should remain confidential.
- Accommodation of mistakes: as the mechanisms of software supply chain security are still evolving, the occasional errors in SBOM implementation should be tolerated, which will facilitate the continuous improvement of the tool.
As the document name suggests, these data elements represent a required minimum and may be extended with time as the cybersecurity standards progress. In addition, enterprises may demand additional information as deemed necessary.
How to generate an SBOM
It is possible to create an SBOM manually, but it is a time-consuming and meticulous task. Fortunately, numerous tools are present;y available to aid developers in generating the document automatically, whether during or post development: FOSSA, Codenotary, Anchor, to name a few. Some solutions scan the open-source dependencies, and others can also analyze proprietary libraries. In addition, you can use a software composition analysis (SCA) tool such as JFrog, Snyk, Spectral, etc., which identifies and gathers information about open-source components that can be further used for building an SBOM.
Another question is — how to draw it up correctly? As mentioned above, SBOMs must be in a commonly accepted, universal form for smooth integration into corporate security processes. As such, the SBOM must be generated in one of these standard industry formats:
- Software Package Data eXchange (SPDX) by the Linux Foundation,
- CycloneDX by the Open Worldwide Application Security Project (OWASP) Foundation,
- Software Identification (SWID) tags defined by the ISO/IEC 19770-2:2015 standard.
Let’s dig deeper into one of these specifications, CycloneDX.
Overview of the CycloneDX format
CycloneDX can be used for a wide variety of use cases, including but not limited to software bill of materials, operations bill of materials, vulnerability exploitability exchange, SBOM for low code application platforms, and so on.
CycloneDX files can be generated in JSON, XML, or Protocol Buffers (protobuf). Every file has a unique serial number conforming to RFC-4122, and the version is incremented by ‘1’ each time a new file is generated. The file contents include eight root-level elements summarized in the table below.
|
CycloneDX element |
Contents |
|
Metadata |
Supplier, manufacturer, tools used for SBOM creation or authors in case of manual generation, target component, licensing information for SBOM itself |
|
Components |
Complete inventory of first- and third-party components: manufacturer, licensing, pedigree, provenance, etc. |
|
Services |
External APIs that may be called, with endpoints, trust zone, and data flow |
|
Dependencies |
Dependency graph with both direct and transitive dependencies |
|
Compositions |
Constituent parts and their completeness |
|
Vulnerabilities |
Known and previously unknown vulnerabilities with exploitability, risk ratings, advisories, etc. |
|
Formulation |
Description of manufacture and deployment processes: formulas, tasks, workflows and so on |
|
Annotations |
Additional textual information in the form of comments, notes, etc. |
Multiple extension points are also available for prototyping new functionality and supporting special use cases.
To generate a CycloneDX file, you can use one of the tools supporting the format. If you utilize Cloud Native Buildpacks for containerization, the platform enables you to generate CycloneDX-based SBOMs for application images. And Maven offers a plugin for drawing up SBOMs in CycloneDX with information about direct and transitive project dependencies.
A software bill of materials is not a luxury, but a must!
We hope we have persuaded you that a software bill of materials is indispensable for securing a software supply chain. As a developer, you must be sure of your project’s integrity. As a customer, you have the right to demand an SBOM from your software vendor.
Some regulations already demand that software vendors provide a software bill of materials. We will discuss the topic in detail in our second article dedicated to SBOMs.
BellSoft will supply its customers with software BOMs for its products so enterprises have a transparent and secure Java development environment. Contact us to learn more about the service.
