CVE Validation Library - uriType - references, collectionURL, repo, packageURL

[ccoffin]

Purpose:

This will be one of multiple discussions to query the QWG and others on how best to use the upcoming CVE Services Validation Library for performing additional or more accurate CVE Record Format JSON schema validation during record ingest. The Validation Library will allow the CVE Program to perform programmatic validations beyond what the current JSON schema validation can provide. A simple example might be where we want to validate that a provided CWE ID actually exists by referencing the current CWE List. This is not possible using JSON schema validation, but would be possible with the Validation Library.

Discussion:

The uriType definition is used referenced and used by multiple properties within the CVE Record Format schema. The most common use is for references of a CVE record and these will almost entirely be http, https, and possibly some ftp types. References can also be used in the product/collectionURL, product/repo, and problemTypes/descriptions/references properties of the schema (see the Schema Locations section for all locations). Last, the recently added product/packageURL property also references and uses the uriType. From my understanding, PURLs should always start with pkg:. PURL syntax is already being validated by CVE Services and this will be something included within the initial release of the validation library. However, we could also include a simple pattern match in the schema to make sure that this property value starts with pkg:.

The uri type in the JSON schema is meant to validate the value provided and ensure that it conforms to RFC 3986. Beyond the usual http:, https:, and ftp: references, RFC 3986 provides a number of examples such as ldap:, urn:, telnet:, mailto:, etc. It's not likely that we would want or need all of these types within CVE references and other properties in the CVE Record Format schema. In simple terms, any value that has one or more alphanumeric characters followed by a colon, then followed by one or more alphanumeric characters (e.g., x:y) will pass the JSON uri type check. One interesting thing to note here, Vulnogram appears to do some client validation of references and will not allow values that do not start with "http://", "https://", or "ftp://" (it may allow more but i didn't check everything). It will fail and not allow publishing even with a missing forward slash. If we agree that only http, https, and ftp should be used in references, we could include a simple pattern match in the schema to make sure that only those uri types are allowed.

Separate from the syntax, we may also want to consider checks to ensure that the reference being provided exists. For references, it might be useful to verify that the reference is live, especially when a record is initially submitted. There may be some technical limitations to this and some sites might not allow this kind of automated checking, but it's worth investigating to see if it is possible.

Examples from RFC 3986:
The following example URIs illustrate several URI schemes and variations in their common syntax components:

  ftp://ftp.is.co.za/rfc/rfc1808.txt

  http://www.ietf.org/rfc/rfc2396.txt

  ldap://[2001:db8::7]/c=GB?objectClass?one

  mailto:John.Doe@example.com

  news:comp.infosystems.www.servers.unix

  tel:+1-816-555-1212

  telnet://192.0.2.16:80/

  urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Schema Location(s):

https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L7
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L19
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L138
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L278
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L367
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L923
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L936

Question(s):

• Can we use the Validation Library to improve the quality and accuracy of the data provided by CNAs when using the uriType definition?
• Can the proposed validation be implemented using only the Validation library, or could it also be accomplished using the JSON schema?

Examples:

• Fail (or Warn) when the provided reference does not start with http:, https:, or ftp:. (Schema and Validation Library)
• Fail (or Warn) when the provided reference does not include a top-level domain. (Validation Library)
• Fail (or Warn) when the provided reference (on record submission) is not live. (Validation Library only)
• Fail when the provided packageURL (PURL) does not start with pkg:. (Schema and Validation Library)

[ccoffin]

One case of an invalid reference was pointed out after i wrote up the above discussion. It might be handled by failing or warning on a missing top-level domain.

CVE-2026-28309 (https://cveawg.mitre.org/api/cve/CVE-2026-28309) has the following reference:
https://https://www.solarwinds.com/trust-center/security-advisories/CVE-2026-28309

This appears to pass the vulnogram validation since it starts with https://, but obviously includes an additional string (https://) that makes it an invalid reference.

[darakian]

Some thoughts post QWG. For anything purl related there's an npm package maintained by the purl spec folk that should be easy to integrate.
https://www.npmjs.com/package/packageurl-js

For a base case we probably do want to trim down the number of schemes; I don't think anyone wants telephone numbers or emails as references. There is also a system of reference tags
https://github.com/CVEProject/cve-schema/blob/main/schema/tags/reference-tags.json
which could have associated forms added to them.

Eg. We set some baseline like http: or https: for an untagged reference and pkg: if the reference is tagged as product. Other forms could be allowed for other tags.

[ccoffin]

Other references that have been pointed out. These should be flagged using the validation library.

• https://www.cve.org/CVERecord?id=CVE-2024-13182 (second reference)
• https://www.cve.org/CVERecord?id=CVE-2025-34097 (fifth reference)