{"id":71210,"date":"2021-11-15T10:44:27","date_gmt":"2021-11-15T15:44:27","guid":{"rendered":"https:\/\/staging.checkmarx.com\/?p=71210"},"modified":"2026-04-13T22:23:59","modified_gmt":"2026-04-13T20:23:59","slug":"sbom-how-to-create-one-using-checkmarx-sca","status":"publish","type":"post","link":"https:\/\/checkmarx.com\/blog\/sbom-how-to-create-one-using-checkmarx-sca\/","title":{"rendered":"SBOM: How to Create One Using Checkmarx SCA"},"content":{"rendered":"

In the first post in this SBOM series, we discussed what an SBOM is<\/a> and why you should care. As previously mentioned, generating an SBOM report may sound relatively simple, but in most cases, it\u2019s 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. <\/p>\n\n\n\n

Another Caveat<\/h2>\n\n\n\n

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\u2019s 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.<\/p>\n\n\n\n

\n<\/a>SBOM Methodology That Actually Enhances Security<\/h2>\n\n\n\n

The first and most fundamental task in generating an SBOM<\/a> is analyzing the software dependencies, which is a natural undertaking for software composition analysis<\/a> (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.<\/em> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u201cproperty\u201d 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.<\/p>\n\n\n\n

How to Generate an SBOM from Checkmarx SCA<\/h2>\n\n\n\n

Using the Checkmarx SCA User Interface<\/h3>\n\n\n\n