CPE components -> ecosystem/package name mapping

[westonsteimel]

As much as I'm sure we'd all like to see CPE's go away, it seems unlikely at this point and I think it'd be useful to help with mapping existing CPE-based data to something more useful.

Should we have some sort of CSA maintained mapping of CPE components -> ecosystem/packagename (here or as a separate repo)?

As an example I started https://github.com/westonsteimel/package-metadata to help with some of my personal stuff where I was trying to map CPE's to Package URL, but I think it'd be great to have this kind of information somewhere that is more likely to actually be useful to others.

I'm fairly certain I saw a list of CPE-> Debian package name mappings in the Debian repos somewhere as well, and I'm sure there are many other sources. I think it'd be great to have everything gathered in a central place

[westonsteimel]

Ah, here's the Debian one: https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/CPE/list

[joshbressers]

This is a great idea!

I would love to see something like cpe->PURL mapping, but almost anything would be better than what we have today :)

[kurtseifried]

So I've looked around a lot and it basically boils down to:

CPE Purl Manual names (e.g. Vendorname/productname/version) Manual URLs (e.g. https://notepad-plus-plus.org/downloads/v8.2.1/)

The (good?) news is an official CPE dictionary is available: https://nvd.nist.gov/products/cpe

and include references, e.g.

Advisory Version

The bad news: it's incomplete.

The worse news is it's not compatible with some vendors. Literally the first example I tried is bad:

Red Hat repository to CPE mapping:

https://access.redhat.com/security/data/metrics/repository-to-cpe.json

the first entry:

"cpes": ["cpe:/a:redhat:3scale_amp:2.11::el8", "cpe:/a:redhat:3scale_amp:2.12::el8",

and nope, it's not in the official dictionary, NVD official has:

So we'll also need a CPE to CPE mapping dictionary (e.g. Red Hat to NVD).

[westonsteimel]

Yeah, I didn't bother with using the official CPE dictionary at all when I did my stuff, I just allowed multiple CPEs to map to a package (or sometimes multiple packages) within an ecosystem because I never cared about going back the other way to CPE, but you're right that we'd need CPE -> CPE for accomplishing that.

[westonsteimel]

Of course even if we did there's no guarantee NVD is using what they say is the official entry on new entries. I've found several cases in the past where they use an old one or make up something new entirely. I'm sure you already know that though.

[kurtseifried]

NVD made a typo of "zabbiz" at some point (should be zabbix), if there's one error there's more. CPE should be structured data, and thus validated and tested to ensure it's correct. At a minimum, we should ensure each CPE we use exists in a CPE dictionary and is correct (spelling/etc.).

[kurtseifried]

Stupid question: why aren't we talking about using SPDX?

[westonsteimel]

I guess ultimately I would really like to have something that is flexible and contains enough information to map between multiple formats.

[kurtseifried]

Can I suggest we start capturing ideas like this that are project scale on their own somewhere? Also it appears one or two other entities may also be working on a similar problem/solution.

[kurtseifried]

Does the https://github.com/CVEProject/cve-schema/blob/master/schema/v5.0/CVE_JSON_5.0_schema.json help at all here, we also have the OSV format https://github.com/ossf/osv-schema

[captn3m0]

For newer projects that are PURL-native (we're trying to be at endoflife.date), it would be nice to have a reverse-mapping as well, to be able to "work in PURL", but provide compatibility data that CPE-tooling can use.

[westonsteimel]

I haven't had a chance to review this yet, but this may be what I was looking to do: https://github.com/scanoss/purl2cpe