How can an SBOM be used in practice? Our two experts and speakers, Ruben Brick and Yvette Teiken, will address this question in their presentation titled “CRA – SBOM – How Software Bill of Materials Are Actually Implemented in Development and Operations.” They will combine the technical fundamentals of SBOMs with questions regarding how to handle vulnerabilities in development and operations.
The live demo illustrates the steps in detail: For a .NET application, a CycloneDX SBOM is generated and opened as a JSON file. Dependency-Track then displays the components it contains and the associated security findings. This makes it clear how information for further analysis is derived from the structured data.
This review builds on two existing articles: “Cybersecurity Isn’t Just for Tech Giants—SMEs Must Act Now” addresses responsibility and organizational structures within companies. “CVD: How to Handle Security Vulnerabilities Professionally” explains the coordinated handling of external reports. The presentation complements these perspectives with practical work using SBOMs.
This interplay yields five insights for teams that want to use SBOMs in development and operations.
1. An SBOM also tracks transitive dependencies
The first insight concerns the software inventory itself. An application consists of more than just the packages directly integrated into it. These packages, in turn, depend on other components. The presentation illustrates such transitive dependencies using a multi-level dependency tree.
An SBOM makes this composition traceable. This provides a development team with a shared information foundation: Which components are included, in which versions, and how are they related? This transparency supports the investigation of security alerts as well as incident response and license verification.
This is particularly relevant when a report concerns a library that no one has intentionally included as a direct dependency. In such cases, the actual composition of the software under investigation is crucial. The SBOM helps to verify this composition in a targeted manner, rather than having to painstakingly reconstruct it only after an incident occurs.
2. SBOMs are an integral part of the development process
The live demo provides a hands-on introduction: cdxgen generates a CycloneDX file for the .NET project, detects 16 components, and reports that validation was successful. The result is visible and can then be processed further.
However, a one-time local call is not sufficient for long-term use. The composition of the software can change with every relevant modification. The CI/CD slide presented in the talk therefore integrates the application, Azure DevOps, and Dependency Track into a end-to-end process model.
The practical implication: The creation, verification, and mapping of the SBOM should be performed regularly and in a reproducible manner. It must remain clear—especially for released versions—which SBOM corresponds to which version. This allows even older product versions to be reviewed if new security information becomes available later.
3. Standards and tools make SBOM data practical to use
The generated SBOM is available in the demo as a JSON file. It contains structured information about components, versions, and dependencies. While this information can be read manually, understanding the relationships between them in large-scale projects is tedious and time-consuming.
This is where standards and tools work together. SPDX and CycloneDX define how SBOM information is structured and described. An analysis tool can import a supported format and process the data in a targeted manner. In the demo, a CycloneDX SBOM with a dependency track is analyzed for this purpose. The components appear there with their versions in a clear, easy-to-navigate interface.
The practical advantage lies in the ability to search through the software inventory more quickly and analyze relationships. Accurate data remains a prerequisite: names, versions, and identifiers such as PURL or CPE help map the components. A clear presentation cannot compensate for missing or incorrect information in the SBOM.
4. SBOMs support the analysis of specific vulnerabilities
In the live demo, the .NET sample project is opened in Dependency-Track. There, you can see the tracked components along with their versions, warnings about deprecated packages, and associated vulnerabilities. Next, a finding classified as “Critical” for NuGet.Packaging 6.8.0 is opened. The details view shows the description of the vulnerability and the CVSS vector.
This illustrates the role of an SBOM in vulnerability management. An inventory can be combined with security information and helps determine which components require further investigation. This allows a general security alert to be tied to a specific project.
However, the findings do not constitute a final decision. The severity of a vulnerability and its specific impact on your own product must be considered together. Analysis tools provide insights; the development and security teams must use these to arrive at a well-reasoned assessment.
5. SBOM data must be linked to product operations
The concluding slide organizes the remaining work into four categories: Impact, Patch Status, Threat Model, and Communication. This highlights the limitations of the technical demo: Identifying a component alone does not answer the questions of which customer installations are affected or whether a patched version is already running there.
Therefore, to implement this, release information, product versions in use, and the assessment of the findings must be consolidated. The SBOM provides the inventory. The operational framework for patch status and customer communication is discussed in greater detail in the linked SME article; coordination regarding external reports is covered in the CVD article.
The fifth insight lies in this connection: Good data must reach the relevant authorities and be incorporated into concrete decisions. The tools presented here provide a technical starting point for this.
SBOM in Practice: From Software Inventory to Decision-Making
The presentation illustrates how the individual steps work together: cdxgen generates the SBOM, Dependency-Track assigns security findings to the components it contains, and the subsequent assessment takes into account the components’ use in the specific product. Each step builds on the information from the previous one.
For development teams, the benefit lies in being able to investigate security issues based on a transparent software inventory. What dependencies does an affected package introduce? Which product version does it contain? And which requirements in the advisory apply to their own application? A well-maintained SBOM provides the data foundation for this analysis and helps justify decisions to operations and customers.
The full recording shows how our experts, Ruben Brick and Yvette Teiken, illustrate these topics using a live .NET demo. In upcoming blog posts, we’ll delve deeper into the individual steps: creating an SBOM, integrating it into the development process, and using it in vulnerability management.
