Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
stevespringett opened this issue Sep 13, 2022 · 5 comments
Closed

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

stevespringett opened this issue Sep 13, 2022 · 5 comments

Comments

@stevespringett
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator

chandanbn commented Sep 15, 2022

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
Copy link
Contributor

zmanion commented Oct 19, 2022

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
Copy link
Collaborator

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
Copy link
Collaborator

Tracked as #201 closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants