SBOM from the security perspective

1. Introduction
2. The current situation with SBOMs
   • Types of SBOMs
   • Spotting weak dependencies
   • SBOM and CRA
3. Generating SBOMs: Different tools for different situations
   • Manual SBOM generation
   • GitHub SBOM Generator
   • SBOM for Docker
   • SBOM Benchmarks
   • Inconsistencies in SBOM generation tools
4. SBOMs in security context
   • SBOMs are not accurate
   • SBOMs can include vulnerabilities
   • SBOMs can be signed
   • SBOMs can include hash sums
5. SBOMs’ hindered commercial adoption
   • Data format compatibility issues
   • Privacy concerns
   • General problems of SBOM files
6. Conclusion

Introduction #

The Software Bill of Materials (SBOM) is a promising approach for keeping an eye on the key elements of a software application, including libraries, dependencies, and frameworks. Many organisations, including NTIA, NIST, CISA, OpenSSF, and GitHub promote the use of SBOMs to enhance software supply chain transparency, improve vulnerability management, and strengthen overall cybersecurity practices in software development and deployment.

In this article we will brief you on the current situation with SBOMs, focusing on security and frequently occurring problems. We’ll discuss the pros and cons of relying on SBOMs to enhance software supply chain security, along with different perspectives and specific requirements for industries where SBOMs are required or common.

The current situation with SBOMs #

SBOM is a comprehensive list that describes all the software components, dependencies, and libraries necessary for building an application. This is where you can get information on the software elements for transparency, accountability, and vulnerability management.

SBOMs aim to track the origins of software components, ensure compatibility, and simplify licensing. At the same time, their complexity, inconsistent formatting, potential vulnerability exposure, and privacy concerns make it difficult to achieve the required software transparency.

The regulatory pressure will definitely drive SBOM adoption across industries. As SBOMs become more widespread, they’ll help quickly identify and patch vulnerabilities, especially in complex industrial software.

Types of SBOMs #

According to CISA’s “Types of Software Bill of Material (SBOM) Documents”, there are different types of SBOMs:

• Design SBOM: A blueprint of your planned software project.
• Source SBOM: Contains all the dependencies your software project uses.
• Build SBOM: Lists information about specific artefacts (like binary files) and dependencies used to build a specific version of your software.
• Analysed SBOM: Provides information about the analysis (testing) of built software artefacts.
• Deployed SBOM: Contains information about the deployed environment, such as container info, OS version, installed additional applications. It may be a concatenation of SBOMs from different applications installed in the system.
• Runtime SBOM: Includes information about the system’s runtime state (loaded shared libraries, artefacts, applications, etc.).

SBOMs include the following information about a software project:

• name
• version
• licence
• dependencies
• project artefacts: files and their checksums (optional)
• links to the source code (optional)
• known vulnerabilities for specific dependencies (optional)

SBOMs typically do not include information about the dependencies’ configuration, environment, development pipelines, or the data they use (except for container filesystems, where SBOMs can include information about used files).

Spotting weak dependencies #

SBOM is expected to reveal the dependencies actively used in the market.

One of the goals is to identify and support struggling or declining open-source ecosystems that are critical for commercial projects. There are different possible approaches to help those projects. The EU and other countries might directly assist struggling projects, or require commercial companies relying on these dependencies to support and maintain them.

SBOM and CRA #

In case you are getting nervous about potential CRA changes—no need to worry (yet)!

Currently, the European Commission specifies that SBOMs should include only the bare minimum of direct dependencies in the project. So if anyone asks you to provide the SBOM file of your project as of October 2024, you can simply generate a Source SBOM for Software projects or a Deployed SBOM for docker containers. Use any available tool in one of two existing live formats, SPDX or CycloneDX, and provide this file to the party who requested it.

Generating SBOMs: Different tools for different situations #

Manual SBOM generation #

The Cyber Resilience Act (CRA) allows developers to create SBOMs manually (Section ‘How to prepare a Software Bill of Material (SBOM) for the Cyber Resilience Act?’). This approach involves analysing product source code, installation files, and documentation. This is a pretty dangerous practice since developers may mistakenly or intentionally overlook a dependency, leaving a critical vulnerability hiding in plain sight.

We don’t recommend generating SBOMs manually: there are tools for that.

GitHub SBOM Generator #

If you’re using GitHub and want the simplest option, here’s a URL to generate SBOM:

https://github.com/<ORG_NAME>/<PROJECT_NAME>/dependency-graph/sbom

Replace the organisation and project names with yours to get a high-quality and simple SBOM for your project. Keep in mind that the GitHub SBOM generator is highly dependent on the programming language of the project, refer to GitHub docs to learn more.

For example, for Go or Python, the GitHub SBOM generator will find almost all the dependencies that were enumerated in lock files, while with C language it might be more complicated. C/C++ lacks a central dependency repository like Java’s Maven or Python’s PyPI. This causes a few headaches:

1. Developers might just add dependency files directly to their project. This approach often hides important information about the dependency’s identity and version.
2. Developers might not mention dependencies at all, which causes errors during the compile time.

Because of this dependency muddle, GitHub cannot generate a valid SBOM for C/C++.

Real-life SBOM example:

The image above shows the SBOM for Acra—an open-source data security suite designed to protect sensitive and personal data. Acra is written on Go, so the GitHub SBOM generator has found and listed all dependencies.

SBOM for Docker #

There are many different SBOM generators for containers, but the standard docker scout is one of the best options. For example, docker scout analyses not just the file system and binaries in the container, but also the other Docker containers used to build it. This tool can pinpoint exactly when specific packages and vulnerabilities might have snuck into your container build process. No more chasing ghosts.

Nevertheless, some tricks could be used to deceive Docker Scout into creating malicious SBOM files that show zero known vulnerabilities.

SBOM Benchmarks #

On the SBOM Benchmark website, you can find different SBOM creation tools and their ratings. Please remember that there is no universal tool for every software.

For example, syft is the tool with the highest ratings on the SBOM Benchmark. It generates SBOM from Docker containers, filesystems and archives, and supports CycloneDX and SPDX specifications. Check syft info on the SBOM Benchmark page.

Although syft has the highest score on the SBOM benchmark, a closer look reveals problems with ‘sharing’ and ‘semantic’ options as represented in the rating.

On the SBOM Benchmark, you can also find real SBOMs of popular open-source projects, generated by different SBOM creation tools, and see the difference between them.

Inconsistencies in SBOM generation tools #

Various SBOM generation tools can produce differing results for identical projects.

While the core dependency list usually remains constant, additional details may vary. Some tools might exclude vital information like licences, suppliers’ names or checksum values. You can find a clear illustration of this issue in the SBOM benchmark examples.

Take the httpd 2.4.62-alpine package as a case in point: The same SBOM standard file (JSON SPDX in this instance) was generated for the same package using different tools, getting different information in some options:

• Httpd Alpine (Syft SBOM);
• Httpd Alpine (Trivy SBOM).

In this example, Trivy omitted the information about suppliers’ names of software dependencies. Syft excluded the checksum values of the image.

SBOMs in security context #

SBOM is a list of all the software components, dependencies, and metadata used in a software application, acting as a complete inventory of its building blocks. It aims to help you better understand, manage, and secure your applications. Currently, SBOMs are merely debug files with no solid backing.

SBOMs are not accurate #

The current tools mostly use secondary sources like package managers and manifest files for SBOM generation. These sources might contain information not present in the actual code: keep an eye on those dependencies!

The following practices can result in inaccurate SBOMs:

• Changing a dependency version in a manifest file, while the code uses a different version.
• Some dependencies might be missing from the manifest file.
• Accidentally including unused dependencies.

That’s why double-checking everything, including the output from SBOM tools, is always a good idea.

SBOMs can include vulnerabilities #

Both SPDX and CycloneDX support the categorisation of vulnerabilities. An SBOM can list software vulnerabilities in its components, but it is not obligatory by the standard. Since this field is optional, many tools (especially the old ones) that generate or process SBOMs may choose to ignore or omit it. When vulnerabilities are included, they can contain descriptions and additional metrics, such as CVSS scores or exploitability details.

Developers should not rely on SBOM as proof that dependencies are free from vulnerabilities, as new vulnerabilities can be discovered after SBOM is generated. An SBOM created on date X may no longer be accurate on date Y, given that the number of known vulnerabilities evolves over time.

SBOMs can be signed #

SBOMs can be digitally signed. This helps to verify their authenticity and integrity, but it’s not always straightforward. Many SBOMs are created by third-party tools, so using signatures for verification depends on your specific setup and implementation.

Verifying the accuracy and authenticity of an SBOM can be challenging. This is where reproducible builds come to the rescue, offering a way to independently verify that the SBOM accurately represents the software it describes.

This approach is already available in Go as described in the Perfectly Reproducible, Verified Go Toolchains article, ensuring that code compiled on different platforms will be identical to the target platform. The Build can be paired with its SBOM to ensure that the project has used the very same dependencies as were declared in the initially generated SBOM list.

This topic remains open for scientific discussion, and using SBOMs as security evidence for binary software is not yet substantiated.

SBOMs can include hash sums #

SBOMs can include hash sums for each file, which is particularly useful for verifying the integrity of software components. This feature is valuable in different contexts, from containers in DevOps to datasets for ML engineers, and even in traditional software development for tracking library versions.

By storing these hashes, SBOMs provide control over the data, ensuring it has not been changed, and that no new files have appeared or been removed. This feature is typical in SBOMs generated from Docker containers, providing an extra layer of security and integrity for the data.

SBOMs’ hindered commercial adoption #

There are no clear guidelines for SBOMs’ correct implementation in a project—that’s the problem. Current standards offer a good balance of security and transparency, but mostly in theory. Developers of SBOM generation tools are still working out the best ways to present Software Bills of Materials.

The dual nature of the standards (either SPDX or CycloneDX) may confuse many developers as they don’t know which standard to choose and maintain in their projects.

Standards allow flexibility, with many optional fields, leading to big differences between tools. SBOMs can sometimes mislead users, especially for closed-source projects, creating a false sense of security.

For example, developers can list some dependencies in manifest files but use completely different ones in the project (see SBOMs and Security section above).

There have also been proposals to introduce SBOMs for firmware. Even in this case, SBOMs would serve as debug information only, without providing evidence of the actual presence of specific packages in the code.

Data format compatibility issues #

The absence of a universally accepted SBOM format results in compatibility issues and confusion: Different formats and versions make integration and data exchange difficult. For example, the current official SPDX toolset doesn’t support reading their old tag-value format files.

Privacy concerns #

Some vendors may not be willing to share detailed component information due to concerns about intellectual property or trade secrets. This can result in incomplete or inaccurate SBOMs. Under proposed CRA regulations, proprietary software vendors are not required to make SBOMs publicly accessible. However, they would need to include SBOMs with product documentation and provide them to clients and market surveillance authorities upon request.

Another factor, hindering commercial adoption, is the fear that exposing component details might reveal vulnerabilities. This is primarily a concern for proprietary software vendors, as open-source projects have many other information leakage channels besides SBOMs, including the source code itself. With CRA enforcement, companies would be mandated to disclose any known vulnerabilities and security incidents affecting their projects.

General problems of SBOM files: #

• Many tools fail to properly follow established guidelines. Missing fields like name, SBOM creation tool, and creation timestamp. Lack of other fields with technical information (e.g. SBOM versioning, the tool used to create it, licence information, etc.).
• To generate SBOMs, the current tools mostly rely on secondary sources like package managers and manifest files. However, these sources might contain information not present in the actual code. Moreover, developers might engage in improper dependency practices (e.g., hard coding or dynamic loading), leading to inaccurate SBOMs.
• Hopefully, most dependencies currently use the purl format, allowing vulnerability searches across various databases. But some tools continue listing dependencies without purl links, or some languages simply don’t support purl, or may even lack proper dependency managers (C/C++).
• The diversity of tools and generation methods available for different programming languages makes SBOM generation even more complicated. This is particularly true for languages with multiple package managers, where some open-source tools only offer functionality for a single manager, limiting the coverage.

Conclusion #

SBOMs hold a huge potential to improve software transparency and security, though they face significant challenges in implementation and effectiveness. Potential inaccuracies, the lack of standardisation and best practices for their implementation are slowing the widespread adoption of SBOMs.

While long-term improvements to SBOM generator tools are ongoing, several critical issues require immediate attention. For example, dependencies added directly to the code may not be reflected in SBOMs, limiting their effectiveness in assessing code dependencies. Additionally, there are challenges with build analysis and runtime SBOM generation; these issues will likely remain significant for the foreseeable future.

For SBOMs to become a truly effective approach for software security and transparency, the issues discussed need to be addressed through improved unified standards, more accurate generation methods, and better integration with complex projects.