A component list contains package names and versions. An analysis tool links this data to known security advisories. There is a crucial step in between: Do the component’s identity and the assignment of the finding match? Anyone who uses an SBOM in vulnerability management needs verifiable answers to these technical questions.
Our experts and presenters, Ruben Brick and Yvette Teiken, will illustrate this work in their presentation using Dependency-Track. This presentation focuses on working with the inventory and the analysis results: identifying components, reviewing messages, supplementing the product context, and reevaluating new information.
SBOM in Vulnerability Management: From Inventory to Findings
In the demo, the components of the sample project and their versions are visible. Among other things, Dependency-Track displays outdated packages and associated vulnerabilities. Next, a finding classified as “Critical” for NuGet.Packaging 6.8.0 is opened. The view includes an advisory description and a CVSS vector.
This is a specific benefit of the SBOM: A security advisory can be linked to a component in the project. The classification shown pertains to the demo version at that time; no current conclusions about another product can be drawn from it.
The information displayed also addresses different issues. An outdated version indicates that a newer package is available. An associated security finding points to a known vulnerability. Both should be examined individually, rather than treating every update automatically as a security fix.
First, check the component assignments
To ensure reliable results, it must be clear which package was examined. A name alone may be ambiguous. Therefore, check the version, package ecosystem, and available identifiers such as the Package URL (PURL). Compare this information with the package that is actually used in the build in question.
Next comes the security advisory: Which version range is specified? What prerequisites does the advisory describe? Does the mapping match the included component? Any missing information or inconsistencies should be documented. A formally valid SBOM does not relieve the team of the need to perform this check.
The relationships between components are particularly helpful. If an affected package is included only indirectly, the dependency graph shows which direct dependency brings it into the project. This can help determine where an update needs to be checked.
Examine exploitability in the context of the product
Once a vulnerability has been classified, the next step is to examine its use in a specific product. Is the affected function called? Can an attacker manipulate the required inputs? What configuration and protective measures are relevant? A severity rating describes the vulnerability; this additional context is needed for your own prioritization.
As long as crucial information is missing, the assessment remains open. A “all clear” determination should be based on verifiable facts and apply to the specific product version under review. If the usage or configuration changes, a new review may be necessary.
As a complementary concept, VEX (Vulnerability Exploitability eXchange) can express statements regarding the applicability or exploitability of a vulnerability in a product context in a machine-readable format. The CycloneDX documentation on VEX explains this addition to the software inventory. This approach complements the component and vulnerability analysis presented in the talk.
Documenting a technical finding in a reproducible manner
For further processing, we recommend referencing the product version, build ID, and the SBOM used together. In addition, include the component ID, the advisory or CVE identifier, the information source used, and the date of the assessment. Also document the prerequisites examined and the rationale for the decision.
This allows another person to understand the basis for the evaluation. It also makes it easier to review the evaluation later: Has the component changed, has the advisory received new information, or has the product configuration changed?
Our article “Cybersecurity Isn’t Just for Tech Giants—SMEs Must Act Now” explains the role played by patch status and the mapping to customer installations. In addition to the release SBOM, this mapping requires an overview of the product versions actually in use.
Combine ongoing analysis with external reports
Even if the software inventory remains unchanged, new security advisories may be issued. Saved SBOMs should therefore be regularly updated with the latest information. A one-time scan at the time of release does not address vulnerabilities that become known later. Dependency-Track describes this ongoing analysis in its documentation on CI/CD usage.
At the same time, reports may come in from external sources . Our article “CVD: How to Handle Security Vulnerabilities Professionally” explains how to receive such reports, follow up with the person who submitted them, and, if necessary, coordinate their public disclosure . The SBOM can support this process when mapping components and products. Coordinating with external discoverers remains an additional task.
To get started from a technical perspective, it’s worth trying a simple test: Select a specific finding, check its component assignment, and document the requirements in your own product. You can then apply this process to other findings and product versions.
Sources and Further Information
- Presentation and live demo, specifically 36:00–37:57 and the final slide around the 41-minute mark.
- Dependency-Track: official project page.
- CycloneDX: Vulnerability Exploitability eXchange.
