Building a software Bill of Materials with Black Duck

Before we can discuss exporting SBOMs, we must first acknowledge that a complete and accurate SBOM includes all application dependencies. This means that third-party and custom components should be included, as well as open source libraries included by your development teams. While open source does make up the vast majority of the modern application, many development teams still rely heavily on vendor-supplied components, like libraries, SKDs, drivers, and so on. If these components are not accounted for in the SBOM shipped with the finished application, complete visibility of supply chain risk has not been obtained. The good news is, most vendors can be reasonably expected to provide SBOMs for these components. But, as the consumer of this software, you need the tools and processes for effectively leveraging the information provided by these SBOMs, and making sure it is perpetuated into the SBOMs that you generate. 

Black Duck SCA enables teams to import third-party SBOMs so that the included components can be added to relevant projects, continuously analyzed for risk, and added to any reports or SBOMs generated as part of the application lifecycle. Additionally, for custom components that don’t already exist in the open source KnowledgeBase, Black Duck will automatically create an associated component, and identify it in any future scans. With Black Duck, development and security teams can establish complete visibility of their supply chains, so that they can effectively manage risk and communicate application composition to their own consumers.  

When users scan a project or application with Black Duck, they’re provided with a dashboard displaying all the software components identified. Included in this list is information about each component’s license and relationships, among other details. Since an SBOM, in the simplest terms, is a list of ingredients for a piece of software, this dashboard is the most intuitive spot for generating such list. Users simply navigate to the “Reports” tab, choose the option to create an SBOM, and pick the desired format. Within seconds, an SBOM for the project is created and ready to be downloaded.

The screenshots below show how we created an SBOM for a sample application in five easy clicks.

The components dashboard is for our demo application, Insecure Bank. You can see information about which dependencies were identified, how they were introduced into the application, and which license is associated with them. Looks like we’ve discovered some problematic Log4j versions as well!

Any generated reports or SBOMs are saved in the Reports tab. This helps provide a single source of truth, and makes it easier to track any deltas in these SBOMs over time.

Any generated reports or SBOMs are saved in the Reports tab. This helps provide a single source of truth, and makes it easier to track any deltas in these SBOMs over time.

You’ve created or received an SBOM, so what do you do with it? This is a question that can be answered by looking back at our example with the problematic Log4j components. Although most of us have heard of the Log4j zero-day vulnerability disclosed last December, let’s pretend we haven’t. By looking at the screenshot of the SBOM, you see that we have Apache Log4j 2.17.0, but what you don’t see is any information about associated risk.

One of the key considerations when choosing an SBOM generation tool and assembling a software supply chain risk management strategy is how you will put that SBOM to work. SBOMs themselves are crucial aspects of obtaining visibility and mitigating risk, but they do not communicate risk. Even with the increased adoption of supplemental information, like Vulnerability Exploitability eXchange (VEX), the only way to truly connect the dots between an SBOM and associated risk is with a SCA solution.