CPE components -> ecosystem/package name mapping about gsd-tools

[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.

<title xml:lang="en-US">@thi.ng/egf Project @thi.ng/egf 0.1.0 for Node.js</title> Advisory Version <cpe-23:cpe23-item name="cpe:2.3🅰️@thi.ng/egf_project:@thi.ng/egf:0.1.0:::::node.js::"/>

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