Definition
An SBOM is a list of all of the components used to build and run an application. They include an inventory of any modules, libraries, dependencies, ML Models, datasets or other components that developers integrate into an application or require to be present when the application is executed.
Overview
In the world of software development, a Software Bill of Materials (SBOM) can be compared to the ingredients and nutrition label of the side of a can of food.
In a similar fashion, keeping software secure requires knowing which components were used to build the software – which is why development, operations and security teams should insist on creating an SBOM for every software release to identify and remediate security vulnerabilities, as well as document component usage for licensing and regulatory requirements.
Like ingredients 0n a label, SBOMs give a detailed list of all the components associated with a particular software release, including potential vulnerabilities and licensing information.
How do SBOMs work?
In general, SBOMs are typically generated during the build stage of the software development process. This stage involves compiling and assembling the software from source code into executable programs or other components. Generating an SBOM at this point allows for a detailed and accurate listing of all components, libraries, and dependencies that are included in the software. This is crucial for tracking the provenance and ensuring the security of all components used in the software.
The steps below describe the typical process taken in order to generate an SBOM:
- Identification of Components – Developers or automated tools identify all the components used in the software, including libraries, frameworks, modules, and dependencies. This can be done manually or with the help of automated tools that scan the codebase and generate a comprehensive list.
- Versioning and Metadata – Each component in the SBOM is associated with metadata such as version numbers, license information, and dependencies. This metadata is important for tracking vulnerabilities, ensuring compliance with licensing agreements, and managing updates and patches.
- Format and Standards – SBOMs can be represented in various formats such as SPDX (Software Package Data Exchange) or CycloneDX. SPDX is a widely used standard for documenting the contents and licenses of software packages.
- Distribution and Sharing – SBOMs can be shared between different stakeholders in the software supply chain, including developers, vendors, customers, and regulators. This sharing facilitates transparency, collaboration, and accountability in software development, deployment and regulatory compliance.
- Integration with Tooling and Processes – SBOMs can be integrated into various software development and security tools and processes. For example, they can be used by vulnerability scanners to identify known security vulnerabilities in software components and by license compliance tools to ensure adherence to licensing requirements.
- Continuous Monitoring and Updates – Since software is continuously evolving, SBOMs need to be regularly updated to reflect changes in the software composition. This includes adding new components, updating versions, and removing deprecated or vulnerable components
Most SBOMs are organized in a highly structured way using formatting standards like SPDX or CycloneDX to produce nested inventories of the contents of an application’s software supply chain. Here are examples of the structure for a couple of the leading formats:
SPDX
In the current implementation of generating an SPDX report, the following fields are required:
- Package Name
- Package Version
- Detected licenses
- Detected checksums when possible
Here is how it would appear in the report:
PackageName: PyYAML SPDXID: SPDXRef-Package-PyYAML-3.10 PackageVersion: 3.10 PackageDownloadLocation: NOASSERTION FilesAnalyzed: false PackageChecksum: SHA256: 3d8ee7cc23fef4279e6a0a46ea8df14f2bfe09703dd1e67b465bca5d4b500602 PackageHomePage: NOASSERTION PackageLicenseConcluded: MIT PackageLicenseDeclared: NOASSERTION PackageCopyrightText: NOASSERTION
CycloneDX
The CycloneDX implementation provides the general metadata of the report that includes information such as Cyclone DX version, author, and report generation date. It also covers detailed component information for each of the detected components and their vulnerabilities information (VEX).
"type": "application", "name": "ubuntu:bionic:libsqlite3-0", "version": "3.22.0-1ubuntu0.4", "hashes": [
{
"alg": "SHA-256",
"content": "1c0f71e7796c1ddb8527b9b052f9948fc8a2c1e8e9c89b084bcc36100f966714"
}
],
"licenses": [
{
"license": {
"id": "GPL-2.0",
"url": "http://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html"
}
}
]
}
Here is an example of how a sample SBOM can be used in an application:
<?xml version="1.0" encoding="utf-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2"
serialNumber="urn:uuid:d6aa76fa-e488-480d-9ad0-f67765dfd015"
version="1">
<metadata>
<timestamp>2020-08-03T03:19:55.999Z</timestamp>
<tools>
<tool>
<vendor>CycloneDX</vendor>
<name>Node.js module</name>
<version>2.0.0</version>
</tool>
</tools>
<component type="library" bom-ref="pkg:npm/juice-shop@11.1.2">
<name>juice-shop</name>
<version>11.1.2</version>
<description>
<![CDATA[Probably the most modern and sophisticated insecure web application]]>
</description>
<licenses>
<license>
<id>MIT</id>
</license>
</licenses>
<purl>pkg:npm/juice-shop@11.1.2</purl>
<externalReferences>
<reference type="website">
<url>https://owasp-juice.shop</url>
</reference>
<reference type="issue-tracker">
<url>https://github.com/bkimminich/juice-shop/issues</url>
</reference>
<reference type="vcs">
<url>git+https://github.com/bkimminich/juice-shop.git</url>
</reference>
</externalReferences>
</component>
</metadata>
By parsing the XML code, this SBOM provides details not just about which components exist in the application, but also metadata regarding the versions and URLs associated with each component.
Roles of the SBOM
Producing secure quality software at speed and scale requires full cooperation between development, operations and security teams. The SBOM is a versatile tool that serves as a single source of truth throughout the software development lifecycle (SDLC). Here are the different roles that the SBOM plays across different teams and aspects of software development and deployment.
Software Supply Chain
Providing transparency and traceability of software components from development to deployment, helps in identifying the origin of each component, ensuring that only verified and secure components are used. If a vulnerability is exploited, it can be quickly traced and remediated to minimize damage.
Security
A crucial reference for security and DevSecOps, it helps ensure that all software components are secure and compliant before they become part of the code. By listing all components and their versions, it allows teams to identify and mitigate vulnerabilities early in the development process, enabling continuous security monitoring and quick responses to security threats.
DevOps
By enabling automation and monitoring of development processes, it provides detailed information about software components, enabling efficient tracking of updates, dependencies, and potential risks. This information is vital for maintaining the stability and reliability of the software during continuous integration and continuous deployment via CI/CD pipelines.
Cloud Native
In cloud-native environments, an SBOM is used to manage and secure various microservices and containerized applications. It ensures that all components running in the cloud are documented and secure. This is particularly important in dynamic and scalable cloud-native architectures where components can change quite frequently.
Licensing and Compliance
An integral part of managing licensing and ensuring compliance, It offers a detailed inventory of all software components, including libraries and dependencies, complete with their terms of licensing. This level of transparency enables DevOps to verify that each component is used in accordance with its license, avoiding potential legal issues.
They are also essential for compliance with regulatory standards, which may mandate the disclosure of software components for security and privacy reasons. This is particularly vital in regulated industries such as healthcare, finance, and critical infrastructure, where failing to comply with regulations can lead to severe penalties.
| Key Roles of an SBOM in Securing the Software Supply Chain | |
| Role | Description |
| Visibility and Transparency | SBOMs offer complete visibility into the components that make up a software application. This transparency helps security teams understand what is in their software, enabling them to manage risks more effectively. |
| Vulnerability Management | By listing all the components and their versions, SBOMs help identify known vulnerabilities in those components. This allows organizations to quickly address and patch vulnerabilities, reducing the risk of exploitation. |
| Compliance and Regulatory | Many regulatory frameworks and standards such as NIST, ISO, and others, require organizations to maintain an inventory of software components. An SBOM helps meet these compliance requirements by providing a structured way to provide proof of compliance.. |
| Risk Management | Understanding the components of a software application helps in assessing the risk associated with each component. This includes assessing the security posture of third-party libraries and open-source components. |
| Incident Response | In the event of a security incident, an SBOM can speed up the incident response process by quickly identifying which components are affected by a particular vulnerability and which developer is responsible, enabling faster mitigation. |
| Enhanced Security | SBOMs enhance supply chain security by providing visibility into third-party components and managing the security risks associated with software supply chains, including third-party and open-source software. |
| Software Integrity | SBOMs help verify the integrity and provenance of software components. This ensures that the components used are legitimate and have not been tampered with, thereby enhancing the overall security of the application. |
| Improved Maintenance | With a clear inventory of components, it becomes easier to manage software maintenance and updates. SBOMs help ensure that all artifacts are up-to-date and have been scanned for security vulnerabilities, reducing the risk of exploitation due to an outdated version of a specific component. |
Importance of the SBOM
The Software Bill of Materials plays a critical role in software development, serving as a comprehensive inventory that details every software component, library, and dependency along with their licensing information. They also play a vital role in adhering to regulatory standards, helping organizations navigate the complexities of ensuring both legal and operational integrity in regard to their software development operations.
Single source of truth
The faster you can determine whether and how a vulnerability impacts your applications and their operating environment, the lower your risk of facing an actual security breach. This single source of truth makes it possible to identify and remediate supply chain vulnerabilities much faster and more efficiently than alternate methods. In case of a breach, the fast reaction time enabled by an SBOM could save an organization from significant financial damage.
Enhanced security
When security problems with software are discovered by the software’s developers or by independent researchers, information about those flaws is typically reported in public vulnerability databases, like the NIST National Vulnerability Database. Thus, information about known vulnerabilities is available.
In most cases, however, there is no easy way of doing that from within the applications themselves. You can’t simply run a command to ask an app whether it’s using a certain library. While you can scan applications to identify dependencies and other components, scanning can be a time-consuming process which is not easily scalable, so it doesn’t always allow businesses the time to meet release deadlines while also identifying critical security risks before attackers start exploiting them.
SBOMs solve this challenge by providing real-time visibility into the components that exist within an application’s supply chain. With that information, DevOps and security teams can quickly determine whether known vulnerabilities impact any components in their applications.
SBOM Best practices
While SBOMs do much to improve visibility into software supply chains and prevent introduction of potential security vulnerabilities, simply creating an SBOM when you build a new app is not enough to minimize security risks. In addition, the following steps should taken to ensure SBOM effectiveness in all situations:
- Continuous updates – Applications change constantly, and SBOMs should change with them. When you add or remove application components or dependencies – or even if you simply change the version of a component – be sure to update your SBOM accordingly.
- Automatic generation – It’s possible to create SBOMs manually, but doing so is time-consuming, hard to scale and inefficient. It also increases the risk of oversights or mistakes due to human error. To achieve enhanced security, SBOMs should be generated automatically by scanning applications to identify their contents and then automatically produce SBOMs based on the identified components.
- Rich metadata – The more data included in the SBOM regarding versions, sources and vulnerabilities, the more useful SBOMs it will be in crucial situations. In many cases, the context provided by metadata is critical for determining quickly whether a given vulnerability is actually exploitable and how to remediate it.
- Consistency – With multiple approaches to formatting SBOMs, it is worthwhile to explore the pros and cons of each format and decide which one is right for your organization. Once a particular structure is selected, however, it is crucial to maintain consistency regarding the format and data types that are required for effective SBOM generation.
JFrog’s SBOM Solution
Properly managing a Software Bill of Materials, or SBOM, has always been a best practice from a security and compliance point of view. However, it has recently gained special urgency in light of recent announcements by the US government and European Union.
In Oct 2023, the White House issued an Executive Order that suggests AI developers provide detailed information regarding the composition of their applications to the U.S. government before releasing them to the public. Likewise the EU’s Digital Operational Resilience Act (DORA), expected to be enacted into law in 2025, requires financial institutions to provide the contents of their software applications to enhance the operational resilience of digital financial services.
Whether for compliance or security it is important that SBOMs are provided in common standardized format. To this end, JFrog Xray supports SPDX, CycloneDX and other standard formats that result in creation of a machine-readable file listing the inventory of software components and dependencies. The main thing is to understand your SBOM requirements and export to the format that makes the most sense for your application.
When it comes to managing your software applications across the entire software development lifecycle, the JFrog Platform is the universal software supply chain solution for DevOps, DevSecOps, and MLOps. This includes over 50 integrations, covering most of the leading tools in the software development ecosystem, and enabling automated, integrated, extendable, and secure management of the entire software supply chain..
For a deep dive into SBOMs, including how they are created and managed on the JFrog Platform, feel free to schedule a demo or take an online guided tour at your convenience.
