In the dynamic landscape of modern software development, transparency, security, and accountability have become paramount. To address these issues, the concept of a Software Bill of Materials (SBOM) has emerged as a critical idea in the software industry. Much like an ingredient list for a recipe, an SBOM is a comprehensive inventory of all the components that make up a piece of software. It goes beyond the visible user interface and delves deep into the software’s underlying structure, listing open-source libraries, third-party dependencies, and proprietary code. This inventory not only provides a clear picture of what’s under the hood but also serves as one of the key points for improving security, managing risks, and enhancing transparency in the rather complex world of software supply chains. In this blog post, I’ll talk about how to consume an SBOM through the OWASP Dependency Tracker.
What is SBOM?
A software bill of materials (SBOM) is a structured list or inventory of all the components and dependencies that make up a software application. Just as a bill of materials in manufacturing lists all the parts required to build a product, an SBOM enumerates the elements within a software package. These components can include open-source libraries, third-party software, proprietary code, and other assets that the software relies on to function.
In the SBOM world, there are three important keywords: create, consume, and transform.
In essence, creating an SBOM involves identifying and documenting all software components, often with the help of automated tools and manual input, while consuming an SBOM provides organizations with valuable information for security assessments, compliance checks, and supply chain transparency, ultimately facilitating better decision-making in software management and procurement.
How to Consume an SBOM?
A produced SBOM example, such as in the link https://github.com/CycloneDX/bom-examples/blob/master/SBOM/juice-shop/v11.1.2/bom.json can be consumed by available tools. The vulnerable application is OWASP Juicy Shop. Consuming a Software Bill of Materials (SBOM) involves using the information contained in the inventory of software components and dependencies to make informed decisions about the software’s security and compliance. Here are the steps to consume an SBOM and some tools that can help:
1. Access the SBOM: First, obtain the SBOM from the software vendor or developer. The SBOM can be in various formats, including SPDX, CycloneDX, or custom formats used by the organization.
2. Analyze Software Components: Review the list of software components and dependencies in the SBOM. Understand the versions, licenses, and other relevant details of each component.
3. Vulnerability Assessment: Use vulnerability scanning tools or services to cross-reference the components in the SBOM with known security vulnerabilities. Common tools for this purpose include the National Vulnerability Database (NVD).
4. License Compliance: Verify the software licenses associated with each component in the SBOM. Ensure that the software complies with the organization’s licensing policies.
5. Dependency Analysis: Understand the relationships between the components in the SBOM. Identify any critical dependencies and potential points of failure.
6. Risk Assessment: Evaluate the overall risk associated with the software, considering the vulnerabilities, licensing issues, and the criticality of the software to your organization.
7. Mitigation and Remediation: If vulnerabilities or compliance issues are found, take steps to mitigate the risks. This might involve updating components, patching vulnerabilities, or seeking alternative components with more favorable licenses.
One of the most popular and well-known tools to consume SBOM is the OWASP Dependency Tracker. I used a Docker installation for my local setup. Once you install the OWASP Dependency Tracker and configure it, this is the dashboard screen.
You can create a new project, give it a name, and then upload the SBOM file in XML or JSON format. In this example, I uploaded JSON format.
In the Components tab, you can analyze all the components that the application has.
By analyzing the Audit Vulnerabilities tab, we can see all the associated vulnerabilities for the given components.
Now that you are aware of the vulnerabilities available in the components, you can prioritize and mitigate them based on the policy of the company.
This work has been supported in part by the Energy Transition Fund of the FPS Economy of Belgium through the CYPRESS project, and in part by the VLAIO COOCK program through the IIoT-SBOM project.
Thanks for reading.
Can Özkan
