Anyone who wants to create an SBOM needs a clearly defined software composition and a suitable generator. A software project contains multiple libraries and additional dependencies that these libraries bring with them. How can this inventory be captured as a machine-readable SBOM? This article guides you through the process, from selecting the software version under review to running the generator and verifying the resulting file.
An SBOM, short for Software Bill of Materials, lists software components and their dependencies in a structured format. In our presentation “CRA – SBOM – How Software Bills of Materials Are Actually Implemented in Development and Operations,” our experts and speakers Ruben Brick and Yvette Teiken will demonstrate how such data can be generated and utilized in the development and security processes. The live demo takes you from the .NET project to the CycloneDX file and on to analysis in Dependency-Track.
Our article “Cybersecurity Isn’t Just for Tech Giants—SMEs Must Act Now” explains why this transparency is important in day-to-day business operations . Here, we focus on the technical implementation: What input data is required for generation, what does cdxgen provide, and how do you verify the results?
What Information an SBOM Should Contain
A useful inventory does not merely describe the application itself; it also lists its direct and transitive dependencies. The development team explicitly includes direct dependencies. Transitive dependencies are introduced into the project via other packages.
The generated JSON file can be opened in a text editor. However, when there are many components and nested dependencies, manual verification can quickly become time-consuming. Analysis tools process this data in a way that allows for a more targeted examination of components and their relationships.
For subsequent analysis, the names and versions of the components—as well as their relationships—are particularly relevant. Identifiers such as a Package URL (PURL) help assign a package to its ecosystem. License information can support another use case: verifying the software licenses used in the product.
To get started, it’s helpful to make a clear distinction: Does the SBOM describe a source code project, a specific build, or a delivered artifact? This question determines which components are expected. An analysis of the project is not automatically a complete inventory of the resulting container or the entire customer installation.
Creating an SBOM with cdxgen: The .NET Example
The live demo uses cdxgen. This tool supports the generation of CycloneDX SBOMs for various technologies. The following example requires a properly configured cdxgen and a development environment compatible with the .NET project.
A call to action for the demonstration looks like this:
cdxgen -t dotnet --spec-version 1.7 --json-pretty -o sbom.cdx.jsonThe command is executed in the project directory. -t dotnet specifies the project type, --spec-version 1.7 specifies the desired CycloneDX version, and -o specifies the name of the output file. If an executable file is provided locally, the command can begin with ./cdxgen, as shown in the presentation.
The screenshot shows a specific result: cdxgen identifies 16 components, reports a successful validation, and writes the file sbom.cdx.json. This number is specific to the demo project; it is not an expected value for other applications. The official cdxgen documentation describes the requirements and options that apply to your own project.
A valid file does not necessarily constitute a complete SBOM
Once the file has been generated, the quality check begins. Successful schema validation confirms that the file conforms to the specified format. A separate check must also be performed to ensure that all relevant components have been included.
A useful initial test is to compare the data with known project dependencies: Do packages that were intentionally included appear with the expected versions? Are any indirect dependencies apparent? Can the file be assigned to the correct product release? Any noticeable gaps should be investigated before the data is passed on to an analysis tool.
The output format must also be suitable for further processing. The presentation will introduce SPDX and CycloneDX as standards. CycloneDX is used for the processing demonstrated in Dependency-Track. The choice should therefore be based on the entire toolchain and not just on which format a generator outputs by default.
Start with a manageable project
For a first attempt, it’s best to choose an application whose dependencies the team is familiar with. This makes it easier to verify the generated data. Be sure to document the generator used, its configuration, and the software version being tested. This makes it easier to repeat the process and integrate it into the build process later on.
A verified SBOM lays the foundation. The next step is to ensure that SBOMs are generated regularly and reliably. Our article “Integrating SBOMs into the Development Process: From File to CI/CD Workflow” explains how this can become an integral part of the development process .
Sources and Further Information
- Presentation and live demo, specifically 28:31–30:16.
- cdxgen: Official project documentation.
- OWASP CycloneDX: The Authoritative Guide to SBOM.
