Add CPE as a PURL type

[sschuberth]

I continuously am having discussions whether (the classic) CPEs or PURLs should be used now to identify components for which you aim to look up security vulnerabilities (like in VulnerableCode).

To put these discussions to an end, I was wondering whether it would be feasible to simply add CPE as a type to PURL, so we could specify a defined way how to map CPEs to PURLs. Because in the end, CPEs are just "component coordivates" like package-manager-specific coordinates are, even if usually used in a different context than a build system.

What do you think @pombredanne?

[pombredanne]

@sschuberth I have been thinking hard about this and IMHO we would be best served as a mapping: the key difference is that a CPE is a "given name" that cannot be inferred just by looking as a piece of code. A Package URL on the other should be something that can be derived from the code in most cases.

Therefore IMHO:

1. you need to track both for as long as NVD does not track also purls.
2. we should craft and publish a db of all these mappings. There is a script to help with this in https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/management/commands/create_cpe_to_purl_map.py

[pombredanne]

Another argument against trying to squeeze a CPE in a purl is that once I know a CPE , there is not much that I can infer from this, essentially not much beyond existing NVD vulnerabilities. See for instance https://nvd.nist.gov/products/cpe/detail/642?namingFormat=2.3&orderBy=CPEURI&keyword=struts&status=FINAL or https://nvd.nist.gov/products/cpe/detail/402983?namingFormat=2.3&orderBy=CPEURI&keyword=openssl&status=FINAL both being common packages.

[sschuberth]

Yet another simple argument for not "trying to squeeze a CPE in a purl": We need a packaging-independent way to look up vulnerabilities in the source code of e.g. OpenSSL 1.0.1 (which contains the Heartbleed bug no matter whether it's packaged as a DEB or RPM, or built from source). This could be done with a CPE, but not with a PURL, because the PURL's type is unclear when building from source.

So, I agree that a CPE cannot be a PURL type. But could we define a standard query parameter called "cpe" that, if present, contains the CPE?

[dn-scribe]

Did you mean to add the cpe as a qualifier pkg:npm/foobar@12.3.1?cpe=cpe2.3 : a : foobar :::: (added spaces to by pass the 🅰️ icon) Sounds a great idea to me

[sschuberth]

Did you mean to add the cpe as a qualifier

Yes.

(added spaces to by pass the 🅰️ icon)

BTW, you can enclose text in backticks to avoid that.

[andrewpollock]

I found this issue when I was poking around trying to understand if CPE as a qualifier was in any way standardised. I was wondering this because I recently learned that Grype seems to be using it as a de-facto thing, e.g. https://github.com/anchore/grype/blob/dfa540f727454da3172bc0cc5b5bc36a925bbd04/grype/pkg/purl_provider.go#L45

Should the spec be updated to explicitly refer to this use case?