close search bar

Sorry, not available in this language yet

close language selection
 

Building a software Bill of Materials with Black Duck

Black Duck SBOM export capabilities enable users to comply with standards, establish trust with customers, and build security into their software supply chain.

Black Duck SBOM | Synopsys

A necessary step in securing an application is evaluating the supply chain of each component used to create the application—no matter how many hands were involved in its development. If any links in the supply chain are obscured, it can be difficult to confidently assess the amount of risk that an application is susceptible to. By building a software Bill of Materials (SBOM), a development organization arms itself and consumers with information crucial to better understanding the risk associated with a particular application. From there, they’re better situated to avoid and react to security breaches and policy violations.

Meeting standards and building trust with an SBOM

Black Duck® makes it easier for users to secure the software supply chain by enabling them to quickly build and export SBOMs in formats such as SPDX and CycloneDX. These standardized SBOM formats provide the information necessary to comply with NIST standards, as referenced in Executive Order 14028. This executive order is geared toward providing more transparency between the government and the private sector with respect to software security. One of the steps to achieving this transparency is requiring vendors to provide SBOMs to the purchasers of their products in a standard, machine-readable format.

While the executive order only applies to software being procured and operated by the United States Federal Government, we have every reason to expect certain aspects of it, like the SBOM requirements, will become de facto standards across the entire software development industry. Being prepared to produce the most accurate and compliant SBOM today represents a significant step toward gaining the trust of your consumers.

Exporting an SBOM with Black Duck

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.

components dashboard in Black Duck | Synopsys

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!

create SBOM report in Black Duck | Synopsys

The most difficult part of generating an SBOM in Black Duck is deciding which NTIA-compliant format to use.

SBOM reports saved in dashboard | Synopsys

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.

SBOM.png

Regardless of whether you choose SPDX or CycloneDX, your resulting SBOM will be a JSON file. This helps it maintain standards and machine readability. There are countless JSON viewers available. Here’s a view of our resulting SBOM in Firefox, which kindly formatted it for us. In this snippet, you can see those problematic Log4J components, and additional information like the related license.

What comes after SBOM generation?

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.

log4j.png

Black Duck not only identifies components in an application and builds an SBOM, but it also advises on related areas of security, license, and operation risk, as well as guiding remediation efforts.

Building the best SBOM

Your SBOM is only going to be as trustworthy as the methods used to identify dependencies, the tools used to address associated risk, and the sources leveraged to do so. Check out how Black Duck leads the pack in each of those areas.

Learn more about Black Duck

 
Mike McGuire

Posted by

Mike McGuire

Mike McGuire

Mike McGuire is a product marketing manager at Synopsys where he is focused mainly on the Black Duck software composition analysis tools and audit services. After beginning his career as a software engineer, Mike transitioned into product management and marketing roles, as he enjoyed interfacing with the buyers and users of the products he worked on. Leveraging several years of development experience, Mike enjoys connecting the market’s complex AppSec problems with Synopsys’ comprehensive solutions.


More from Open source and software supply chain risks