Assigning many CPEs per CycloneDX component

[henrirosten]

Does Dependency Track support some way of providing more than one CPE for a comopnent in CycloneDX SBOM?
The use case would be to provide more than one alternative CPEs for applications that are associated to many CPEs for DT to better match vulnerabilities.

Perhaps something like providing alternative CPEs via the CycloneDX component properties: https://cyclonedx.org/docs/1.4/json/#components_items_properties.

[stevespringett]

A component should only ever have a single CPE identity. In reality, the NVD has a ton of data issues. The CycloneDX spec does not try to provide workaround for human problems at the NVD that lead to data inconsistencies between component identity.

One approach that DT could take is to support an alias list where we predefine all the alias CPE vendors and product names and take that list into consideration when performing a vulnerability scan. This would require a ton of research and community feedback, but it is possible.

[henrirosten]

Thanks for the quick reply @stevespringett !
I see this discussion anchore/syft#819 (comment) mentions using properties for this same problem. What's unclear to me is that does DT currently support some way of providing alternative identifiers, or if this is still under discussion.

If it's not possible with CycloneDX, would providing alternative identifiers be possible with other SBOM formats, such as SPDX?

[stevespringett]

DT supports SWID, CPE, and PURL for identifiers and every component should only have a maximum of 1 of each. This aligns to the CycloneDX model as well. SPDX does support multiple identifiers but at the expense of not being able to assert component identity. See https://spdx.github.io/spdx-spec/v2.3/package-information/#7211-description. Pay attention to "believed to be relevant to the Package". SPDX is a belief system without the ability to assert what the identity of a component is, or without the ability to specify the confidence of those beliefs or where the evidence came from that influenced the SBOM author's beliefs. This approach does not align to the DT model and is not supported. It's one of the reasons why SPDX was removed from prior versions of DT.

Supporting this in DT would require the ability to triage and correct component identity by evaluating all available evidence of each component. These are features that do not exist in DT presently as its a highly manual use case. DT is focused on automation.