A Software Bill of Materials (SBOM) for container images provides a comprehensive inventory of the software components and dependencies included within the container image. An SBOM details the composition of the containerized application and ensures transparency and visibility into the software supply chain.
Table of Contents
What is a Software Bill of Materials (SBOM) for Container Images?
A Software Bill of Materials (SBOM) is a list of all the open-source and third-party components used in a particular software application or system. An SBOM also includes the license information of the software components, the version details of the components used, any known vulnerabilities, and their patch status. This concept of a software Bill of Materials derives from the manufacturing industry, where a Bill of Materials is an inventory detailing all the items included in a given product.
An SBOM helps organizations track all the components in their codebases, and assess potential security risks associated with those components. It provides transparency and visibility into the software supply chain.
What is included in a Software Bill of Materials?
An SBOM is a complete inventory of the application codebase including the open-source and third-party party components, the license and version information for those components, and if there are any known vulnerabilities in those components.
Open-Source Component Identification: A comprehensive SBOM clearly identifies all the open-source software components used in an application, including direct and indirect dependencies. It includes details such as component names, versions, and their sources.
Open-Source Licensing Information: An SBOM includes information about the licensing terms and conditions attached for each open-source software component. As there are hundreds of different types of open-source licenses, it is important for organizations to ensure they are in compliance with the licensing requirements and understand any legal obligations.
Open-Source Vulnerabilities: An SBOM can be used to track known vulnerabilities associated with each open-source software component. By keeping an up-to-date SBOM, organizations can monitor and address security vulnerabilities in their codebase.
Supply Chain Analysis: As SBOM is a complete inventory of a codebase including the open source and third-party components, it provides insights into the software supply chain. This helps organizations assess the security and quality of the components used in their software and make appropriate decisions about risk mitigation when required.
Compliance and Auditing: SBOMs are useful for audit and compliance purposes, such as meeting regulatory requirements or industry standards. These can be shared with auditors or regulators as evidence of software composition and compliance efforts.
Importance of SBOMs generation?
The generation of a Software Bill of Materials (SBOM) is important for a number of reasons:
Transparency and Visibility: An SBOM provides transparency and visibility into the software supply chain. It helps organizations understand the composition of their software applications, including all the components and dependencies used.
Vulnerability Management: SBOMs play a crucial role in vulnerability management by providing a comprehensive view of the software components used in an application, including any known vulnerabilities.
Risk Assessment: SBOMs allow organizations to identify third-party or open-source components with known vulnerabilities, outdated versions, or licensing conflicts. By understanding the risks associated with each component, organizations can prioritize their remediation efforts and take proactive measures to reduce security vulnerabilities and potential compliance issues.
Compliance and Legal Obligations: SBOMs are increasingly becoming a requirement in various industries and regulatory frameworks. They help organizations demonstrate compliance with legal and regulatory obligations related to software security, privacy, and intellectual property.
Supply Chain Security: With the increasing complexity of software supply chains, SBOMs are essential for assessing and managing supply chain security risks. They provide insights into the origins and quality of software components used, helping organizations identify and address potential security weaknesses introduced by third-party or open-source dependencies.
Incident Response and Remediation: In the event of a security incident or vulnerability detection, having an SBOM enables faster and more efficient incident response and remediation. Appropriate mitigation actions can be taken quickly by identifying the affected components and their potential security risks.
Container Images: How to generate a software bill of materials (SBOM)?
A software composition analysis (SCA) tool can be used to generate a comprehensive open-source SBOM. There are several tools available that can help generate software bill of materials (SBOMs) for container images. Some of the popular ones are:
| Trivy | Trivy is a comprehensive and versatile security scanner. Trivy supports most popular programming languages, operating systems, and platforms. Trivy has scanners that look for security issues, and targets where it can find those issues. |
| JFrog Xray | JFrog Xray is a powerful software composition analysis (SCA) tool that can scan container images and generate detailed SBOMs. It can easily integrate with popular container registries and provides insights into the software components and vulnerabilities present in container images. |
| Syft | Syft, is an open-source tool that can analyze container images and generate SBOMs. It provides detailed information about the software components, licenses, and vulnerabilities found in container images. Syft supports various output formats, including SPDX, JSON, and CycloneDX. |
| NIST | The National Institute of Standards and Technology (NIST) SBOM provides guidelines and recommendations for generating SBOMs, including container images. NIST guidance emphasizes the use of standardized formats such as SPDX (Software Package Data Exchange) or CycloneDX. You can use their guidelines to manually create an SBOM or refer to specific tools that support their recommended formats. |
| OSCT | The Open Source Compliance Tooling (OSCT) project is an initiative by the Linux Foundation to provide tools and resources for managing open-source compliance and generating SBOMs. They offer tools like `spdx-tools` and `scancode-toolkit` that can help generate SBOMs for container images using the SPDX format. |
Generating container image SBOM using Trivy
Trivy is an easy-to-use, comprehensive open-source scanner that helps developers gain visibility into the software components used in their applications. Trivy recently added support for generating SBOMs as a top-level command in the CycloneDX format, an industry-wide SBOM standard.
Trivy Installation
Trivy can be easily installed by following the installation guide available on Trivy’s documentation site.
Trivy Usage
To generate Ubuntu image SBOM, run the below command:
trivy -q image --format cyclonedx ubuntu:23.04 | jqAnd we get our SBOM!
Generating container image SBOM using Syft
Syft is a cli tool and a Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems.
Syft Installation
Note: Currently, Syft is built only for Linux, macOS and Windows.
Installation on Linux:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/binSyft Usage
To generate an SBOM for a container image:
syft <image>
The above output includes only software that is visible in the container (i.e., the squashed representation of the image). To include software from all image layers in the SBOM, regardless of its presence in the final image, provide --scope all-layers:
syft <image> --scope all-layersExample sbom for redhat ubi9 image
syft redhat/ubi9:latest --scope all-layers
Syft Output Formats
The output format for Syft is configurable as well using the -o (or --output) option:
syft <image> -o <format>
Where the formats available are:
json: Use this to get as much information out of Syft as possible!text: A row-oriented, human-and-machine-friendly output.cyclonedx-xml: A XML report conforming to the CycloneDX 1.4 specification.cyclonedx-json: A JSON report conforming to the CycloneDX 1.4 specification.spdx-tag-value: A tag-value formatted report conforming to the SPDX 2.3 specification.spdx-tag-value@2.2: A tag-value formatted report conforming to the SPDX 2.2 specification.spdx-json: A JSON report conforming to the SPDX 2.3 JSON Schema.spdx-json@2.2: A JSON report conforming to the SPDX 2.2 JSON Schema.github: A JSON report conforming to GitHub’s dependency snapshot format.table: A columnar summary (default).template: Lets the user specify the output format. See “Using templates” below.
Any Limitations of SBOMs?
No doubt, Software Bill of Materials (SBOMs) provide valuable insights into the composition of software applications, but they also have certain limitations. Here are a few limitations to consider:
The incompleteness of Information: SBOMs rely on the availability and accuracy of information about the software components used in an application. Obtaining complete and up-to-date information about all the components, including third-party and open-source dependencies, can be challenging. Not all software suppliers may provide detailed information about their components, and open-source projects may lack proper documentation.
Lack of Standardization: While efforts have been made to standardize SBOM formats such as SPDX (Software Package Data Exchange) and CycloneDX, there is still a lack of universal adoption and consistency across the industry. Different tools and platforms may generate SBOMs in varying formats, making it challenging to consolidate and compare SBOMs from different sources.
Coverage of Security Vulnerabilities: While SBOMs can identify known vulnerabilities associated with software components, they may not capture newly discovered vulnerabilities or zero-day exploits. Vulnerabilities can emerge after the SBOM is generated, leaving a gap in real-time vulnerability management.
Dynamic Nature of Software: Software applications are constantly evolving, with frequent updates, patches, and new versions of components being released. Keeping the SBOM up-to-date and synchronized with the latest version of each component requires continuous monitoring and maintenance. Failure to update the SBOM in a timely manner can lead to inaccurate and outdated information.
Supply Chain Dependencies: Modern software applications often have complex supply chains, with multiple layers of dependencies and indirect relationships between components. It can be challenging to accurately capture and represent these interdependencies in an SBOM, which may impact the completeness and accuracy of the information provided.
Despite these limitations, SBOMs remain a valuable tool for software security and risk management. They provide a foundation for understanding and addressing software vulnerabilities, managing compliance, and promoting transparency in the software supply chain.
Summary
Generating reliable source package information in the form of SBOMs is an important part of software supply chain security. They help organizations identify and mitigate risks associated with third-party components, improve vulnerability management processes, and enhance overall software security.
In summary, the generation of an SBOM is crucial for enhancing software security, managing vulnerabilities, ensuring compliance, and effectively managing supply chain risks.
FAQ’s
Can an SBOM help with license compliance?
Yes, an SBOM can help with license compliance. As it lists the licenses associated with software components in a container image. Organizations can use this information to ensure compliance with open-source license requirements and make informed decisions about the use and distribution of containerized applications.
Can an SBOM be used for traceability and accountability purposes?
Yes, an SBOM can be used for traceability and accountability purposes. It provides a documented record of the software components used in a container image, which can be useful for auditing, compliance, and demonstrating due diligence in software supply chain management.
How can an SBOM help with vulnerability management?
An SBOM provides a detailed list of software components and their versions in a container image. By using this information against vulnerability databases, security teams can identify known vulnerabilities and take appropriate actions such as applying patches or looking for alternative components.