In the first post in this SBOM series, we discussed what an SBOM is and why you should care. As previously mentioned, generating an SBOM report may sound relatively simple, but in most cases, it’s not. As you likely know, modern software projects make use of a long list of third-party open source packages, each of which often calls on many other packages as dependencies. This can create an extensive tree of direct dependencies, dependencies of dependencies, and so on. Simply put, trying to create and manage an SBOM using a spreadsheet is nearly impossible, and if you try to manage your open source usage this way, it will likely get out of hand very quickly.
Another Caveat
The next caveat to consider is that SBOM reports should follow a standard format that includes detailed information about each involved component. At a minimum, it needs to give the component’s name, supplier name, version, hashes and other unique identifiers, dependency relationship, author of SBOM data, and a timestamp. The report also needs to cover every software modification and update to reflect the current status of the project. An SBOM report is best accomplished using an automated process that is integrated into your CI/CD pipeline.
SBOM Methodology That Actually Enhances Security
The first and most fundamental task in generating an SBOM is analyzing the software dependencies, which is a natural undertaking for software composition analysis (SCA) solutions such as Checkmarx SCA. However, the ultimate purpose of an SBOM is not just providing a list of ingredients, but to identify potential risk. A standard SBOM provides a list of ingredients but no simple way to detect and measure risks associated with third-party dependencies. So, what else do you need to enhance software security? Simple: vulnerability and license risk information.
To meet the need for a more comprehensive SBOM, Checkmarx SCA leverages our existing infrastructure for identifying vulnerabilities, in addition to license and supply chain risks, to supplement the standard SBOM info. This creates an SBOM that provides valuable insight into the risks associated with your third-party components instead of just a list of ingredients. This methodology exceeds the requirements for what a simple SBOM contains.
The SBOM reports generated from Checkmarx SCA use the existing CycloneDX SBOM format, and SPDX and SWID formats will be added soon. The reports also provide additional “property” fields showing important risk data that organizations need to know about. The reports can be exported in XML or JSON format, making them easy for organizations to consume, track, and update.
How to Generate an SBOM from Checkmarx SCA
Using the Checkmarx SCA User Interface
- Navigate to the Scan Results screen for the most recent scan of the desired project.
- Click on the “SBOM” button. The SBOM configuration dialog is shown below:
- Select the SBOM standard. Currently, only CycloneDX is available.
- Select the output format: XML or JSON.
- Click “Generate SBOM.”
The SBOM report will be downloaded and can be viewed on any standard XML/JSON viewers.
How to Add CI/CD Integration
Checkmarx SCA provides plugins and CLI tools for various CI/CD pipelines. One method for running Checkmarx SCA scans via CLI commands is the CxSCA Resolver, which is an on-premises utility for resolving and extracting dependencies. The following section describes how to export SBOM reports using the CxSCA Resolver.
How to Generate SBOM Using SCA Resolver
An SBOM report can be exported via the CxSCA Resolver CLI using –report-extension and report-type arguments.
Example:
“./ScaResolver -s /home/jack/src/MyApp -n MyApp -a Checkmarx -u jack -p ‘demo123!’ –report-extension Xml / Json –report-type CycloneDx”
SBOM Content
Below is a view of the SBOM content, which is part of the SBOM Checkmarx SCA generates.
The standard SBOM fields are ID (purl), Component Name, Version, License, and Hashes. All of these are included in every Checkmarx SCA SBOM as required fields.
In addition, we add a Properties section with extended information about the risks associated with each library.
SBOM Component Dependencies
Below is a view of the component dependencies, which is part of the SBOM Checkmarx SCA generates.
Each component contains its dependent components, and each dependency section contains a set of required fields and a Properties section.
Conclusion
Checkmarx is dedicated to helping organizations secure the software they develop, one line of code at a time. In response to the proliferation of open source usage, recent supply chain attacks, and the executive order mentioned in the previous post, you can use Checkmarx SCA to easily create and maintain an SBOM of your own. Plus, you’ll get real-time risk data about the open source found in your codebase to help you manage your own risk better.
In the next blog in this SBOM/Software Supply Chain series, we’ll discuss the top three software supply chain risks you need to know about.
To see an SBOM being created live, don’t hesitate to request a demo.
Download our Ultimate Guide to SCA Here.
