Unique Product Identifier

[tschmidtb51]

As a follow up to #1 :

3. Defining the productId
   The productId should ideally be globally unique to ensure consistency and avoid confusion across different documents or systems. The assignment of productIds can be managed by a central authority, similar to the supplierID, or follow a standardized naming convention established by the industry. By ensuring a globally unique productId, it becomes easier to track and manage EOL and EOS information for products across various sources and platforms. Getting consensus of this central authority will be one of the most challenging parts of all this. However, we can start the conversation with other industry leaders, CISA, and other participants.

Originally posted by @santosomar in #1 (comment)

Creating this issue to track this.

[tschmidtb51]

There is a panel discussion regarding the topic upcoming at the FIRST conference.

[tschmidtb51]

If you have a SBOM and you provide it for download and the URL is stable, you can use that URL to uniquely identify a single version of a product.

[elear]

I would encourage this schema to either make product identification information optional, or simply not to include it at all, and to let the objects serialized by this schema be subordinate to other objects.

[tschmidtb51]

I like the idea and it also reflects the Unix philosophy: "Do One Thing And Do It Well."

The embedding might help to find broader acceptance...

[StefanSchroeder]

I suggest to adopt the CPE name as an optional field to fulfill this need.
It's well established, well defined, well standardized, used by NVD and proven in use.

CPE Standard, CPE Dictionary

CPE would also solve the "supplierID" #6, because CPE contains the field "vendor", meaning the same.
If you made the CPE name mandatory, the supplierID field would become redundant.

I guess that @tschmidtb51 would be more inclined to favor SPDX, given the list of their own repositories... But I don't really see CPE and SPDX as competing.

The CPE would have the additional benefit that it'd become trivial to map CVEs to products in the OpenEoX database.

[tschmidtb51]

I would even go one step further and split the schema into two separate things:

1. a definition schema that gives the different options (comparable to CVSS schemas) and can be imported by other schemas, e.g., CSAF
2. an API schema that adds the product information (what exactly that should be is tbd)

[captn3m0]

We use both PURLs and CPEs in our schema at endoflife.date and have found both lacking.

In particular: PURLs do not work well with anything that's not distributed as a package. This includes things like operating systems or devices, but also software that might be distributed outside of a package manager.

CPEs do not consider distribution mechanisms so you get the same issues that CVE scanners.

We have also considered SWIDs, to account for gaps in PURLs.

I like the idea of providing an embedable schema, which could be used by other specifications. A simple usecase would be adoption by package managers so the package metadata could embed this specification and provide EoL information.

[StefanSchroeder]

There had been a suggestion in Debian to adopt CPE, see https://wiki.debian.org/CPEtagPackagesDep.
But the proposal is stale, it's ten years old...

[santosomar]

Hi everyone!

This is a great discussion!

FYI only: Now that OpenEoX is an official OASIS technical committee (TC), we are moving the discussion to the repository. I have added this for active discussion and work under oasis-tcs/openeox#2