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.
Importing third-party SBOMs
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.
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.
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.
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.
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. To see how Black Duck is continually innovating to lead the pack in each of those areas, and help teams manage all software supply chain risks, see our blog about the release of our new Supply Chain Edition.
-This blog was fact checked by Patrick Carey.
Continue Reading
?ts=1712670360042&$responsive$)
Securing the software supply chain with Black Duck Supply Chain Edition
What is the Xz Utils Backdoor : Everything you need to know about the supply chain attack
