Missing Vulnerabilities from CycloneDX BOM upload

[alfredodeza]

Current Behavior:

Uploaded a CycloneDX BOM to a new project and none of the vulnerabilities reported in the BOM made it into the audit. I searched the open/closed issues and found that #744 explained something similar.

The suggestion was to follow the FAQ which mentions specifically this:

I expect to see vulnerable components but I don’t:
Most common reason: You have yet to enable the Sonatype OSS Index Analyzer. It is not enabled by default but is necessary to scan dependencies represented by Package URLs.

There are a couple of issues here:

1. The FAQ implies that Package URLs are a hard requirement, but the CycloneDX spec mentions that:

If PURL is not an option or not all components represented in the BOM contain a PURL, then UUID is recommended

2. We are uploading a BOM with the vulnerability extension. Specifically, the example XML from CycloneDX used here: https://cyclonedx.org/ext/vulnerability/ which has PURLs and vulnerabilities

3. It is not clear from reading the documentation or after uploading a BOM with vulnerabilities, that:

• PURLs are absolutely required
• Vulnerabilities are (seemingly) not supported

Steps to Reproduce:

Upload any of the examples in https://cyclonedx.org/ext/vulnerability/

Additional Details:

I think this is more of a documentation enhancement rather than a bug. There are a few places that should highlight the strict requirements (e.g. PURLs) and that there is no support for the vulnerability extension in CycloneDX.

From searching the docs, these are some places where I think might make sense, perhaps there are other good spots as well:

• https://docs.dependencytrack.org/best-practices/
• https://docs.dependencytrack.org/FAQ/
• https://docs.dependencytrack.org/analysis-types/outdated-components/
• https://docs.dependencytrack.org/datasources/repositories/

In places where it is noted that DependencyTrack uses PURLs, there should be an emphasis on the requirement. For example, this line with "relies":

Dependency-Track relies on Package URL (PURL) to identify the ecosystem

Could be changed to "requires" :

Dependency-Track requires Package URL (PURL) to identify the ecosystem

[stevespringett]

The FAQ implies that Package URLs are a hard requirement, but the CycloneDX spec mentions that:
If PURL is not an option or not all components represented in the BOM contain a PURL, then UUID is recommended

I think there's a misunderstanding between the purl element and using purl as an identifier in a components bom-ref. The spec states:

bom-ref attribute of a component element

An optional identifier which can be used to reference the component elsewhere in the BOM. Uniqueness is enforced within all elements and children of the root-level bom element.

purl element of a component

Specifies the package-url (PURL). The purl, if specified, must be valid and conform to the specification defined at: https://github.com/package-url/purl-spec

Dependency-Track uses the purl element for vulnerability and repo use cases. If a component is a package (library, framework, os package, etc), then PURL is a requirement. If the component is not a package but rather an application, operating system, or hardware device, then PURL is not required (or even possible). For these components, CPE is required. The CycloneDX website has a table of component types and the recommendations for each type for use in security use cases. https://cyclonedx.org/use-cases/#known-vulnerabilities

Dependency Track does not support the CycloneDX vulnerability extension. There are plans to add the vulnerability extension as an option when outputting CycloneDX for Dependency Track projects, but there are no current plans on importing vulnerabilities defined in the CycloneDX vulnerability extension. If this is a requirement, pull requests are highly encouraged 😉 The primary purpose for this extension is to provide GRC and related risk management systems, the ability to import that data along with all the risk scores from each vulnerability. But I also see your point in possibly having that capability in Dependency Track in the future as well.

[alfredodeza]

@stevespringett thank you so much for your thorough feedback. Confirming that there is no support for the vulnerability extension is very useful to us at this point.

I think that the most important thing is emphasizing further that there is no support for vulnerabilities (yet) and that PURLs are a hard requirement for packages. In particular these two statements:

Dependency-Track uses the purl element for vulnerability and repo use cases. If a component is a package (library, framework, os package, etc), then PURL is a requirement.

And:

Dependency Track does not support the CycloneDX vulnerability extension

I'm happy to produce doc updates, but wasn't entirely sure where those should go. If you could point me in the right way, I can start getting that worked out.

[stevespringett]

Doc improvements are always welcome. It's good to have a fresh set of eyes on things, especially as software changes over time. Docs are here: https://github.com/DependencyTrack/dependency-track/tree/master/docs/_docs and will next be published when Dependency-Track 4.0 is released.

[w2n1ck]

I used https://github.com/cyclonedx/cyclonedx-python to generate bom.xml For Python. After the XML is uploaded through the "Upload BOM" Function, there is no vulnerability detection result

[stevespringett]

@w2n1ck ensure OSS Index is enabled. Refer to https://docs.dependencytrack.org/FAQ/

[swarkentin]

We were running into something similar. OSS Sonatype Index does not always contain CVEs that are present in NIST NVD.

I put together a PR that attempts to augment the python bill of materials with CPEs, where possible, to match NVD. One specific example where this works is webargs.

PR is open for comment:

CycloneDX/cyclonedx-python#157

[stevespringett]

If OSS Index is missing vulnerabilities, please let them know so they can correct the issue. Once corrected, DT will identify the vulnerable components upon next analysis.

https://github.com/OSSIndex/vulns