Add package's CPE to BOM

[ryden54]

Is your feature request related to a problem? Please describe.

OWASP's Dependency track internal analyser uses only CPE (not PURL) to match components with NVD vulnerabilities.
The current version of this package does not seem to include CPE in the generated BOM file
When uploaded to dependency track, the default analyser fails to match any php dependency to known vulnerabilities.

Describe the solution you'd like

In the generated bom in cyclonedx format, include the CPE of all packages

Describe alternatives you've considered

Dependency track can be configured to user other scanners, which can handle the provided packages PURLs
But it would be better to be able to benefit also from the https://nvd.nist.gov/vuln

Packagist is also integrating nist's NVDs, but having all the information centralised in the dependency track application would be great

Additional context

With the example of https://nvd.nist.gov/vuln/detail/CVE-2021-3603
the expected CPE is cpe:2.3:a:phpmailer_project:phpmailer:*:*:*:*:*:*:*:* ( |<=6.4.1 )

Looking at the composer.json file, there's no mention of phpmailer_project, neither on packagist's page
https://packagist.org/packages/phpmailer/phpmailer#v5.2.26
I don't know how it should be built with the available composer's data...?

[stevespringett]

The data in the CPE dictionary is human created. The vendor, product, and version are all created through the CNA process. So there's no way to know in advance what the CPE is going to be for any given package.

Most sources of vulnerability intelligence have mappings of some kind, which map a component to an associated CPE. This would require a mapping for every component in packagist.org which would not be sustainable for an open source project.

Another issue with CPE is that, in most cases, a CPE is not created until a component has its first CVE published. So it would not be possible (in most circumstances) to proactively monitor components (for vulnerabilities) if those components did not have a previous CVE published.

A more sustainable approach would be to have the NVD to accept other forms of identifiers such as purl, swid, and gs1*. Work is ongoing wrt to this. The SBOM Forum is drafting a paper that speaks to this.

[jkowalleck]

Thanks for the background, @ryden54 and @stevespringett .

The last comment showed, that is feature is not feasible, right?

Will have this Feature Request moved to Discussions,
so it is not lost, but documented for future.