CVEProject / cve-schema

This repository is used for the development of the CVE JSON record format. Releases of the CVE JSON record format will also be published here. This repository is managed by the CVE Quality Working Group.
Creative Commons Zero v1.0 Universal
248 stars 138 forks source link

Add support for GS1 (GTIN and GMN) identifiers #194

Closed stevespringett closed 1 year ago

stevespringett commented 2 years ago

Currently hardware devices in the NVD are specified using CPE. The hardware industry does not natively use CPE, but they do use multiple standards from GS1 including GTIN and GMN.

GTIN is an identification standard for all trade items developed by the international non-profit GS1. These identifiers are specifically designed to be unique to individual trade items and provide a simple way to uniquely identify trade items across multiple databases and organizational boundaries.

GMN is a standard from GS1 which allows manufacturers to describe products and product families. The GMN and GTIN share the same Company Prefix (GCP) in the specification. However, a single GMN may have several GTINs. This allows databases to track a model number along with all the variants of each model number, without the need to track individual GTINs. In the European Union, the GMN supports the implementation of the requirements of the Basic UDI-DI under the EU Unique Device Identification (UDI) regulations on medical devices.

By supporting these standards, it would be possible for example, to query using the UPC number on the back of a device to identify if the device has any known vulnerabilities.

Both of these standards are in widespread use and already supported in manufacturing, procurement, and CMDB systems.

chandanbn commented 2 years ago

This can be supported using version and versionType fields as these are meant to accommodate any type of version expressed as a string.

eg., version: 1234556789 versionType: GS1

One problem: the 5.0 schema is currently defined such that versionType is needed only when ranges are defined, and can't be used for single version identifier.

Alternatively this can be encoded for hardware are list of platforms if the hardware also has software versions that are affected.

platforms: [ "PlayStation5", "1234567890" ] versions: [...]

chandanbn commented 2 years ago

QWG discussed this today, for now the recommended field is to use the platforms field to mention any hardware identifiers. The definition does say "hardware models". One difficultly would be with validating/associating the number with the numbering scheme.

If there are other suggestions to encode this, please submit a pull request to the schema.

zmanion commented 1 year ago

One problem: the 5.0 schema is currently defined such that versionType is needed only when ranges are defined, and can't be used for single version identifier.

Any reason not to allow versionType for single (non-range) version identifiers? I guess there are costs to keep track of and validate each versionType.

chandanbn commented 1 year ago

There is no valid reason why it shouldn't be allowed. I guess this was an oversight, artifact of oneOf/anyOf subschema complications. It would be a backwards compatible change to allow it, we will fix in 5.1.

Currently no plans to validate if the version conforms to what is said in versionType - may be hard to do with the JSON schema.

chandanbn commented 1 year ago

Tracked as #201 closing this.