Holistic review of Reserved-but-Public IDs

[zmanion]

Reserved-but-public (RBP) IDs come in several flavors.

1. Vendor CNA publishes official advisory/vulnerability information, there is delay before vendor CNA populate CVE entry
2. Typographical mistake
3. Accidentially publishing a valid ID for a not-yet-published vulnerability
4. Others?

Case 1. is particularly painful for "hot" vulnerabilities, i.e., the period of time that starts when a new vulnerability is published and consumers are scrambling for information, including information provided in and indexed by CVE entries.

The Program should take a comprehensive look and make some decisions about RBP, including:

1. Whether or not to disclose RESERVED state at all (via Services API and via bulk download), see Review ID reservation, specifically how/why reservation is conveyed to consumers #15
2. Timeouts for CNAs to publish RBP entries
3. What action, if any, to take when RBP timeouts occur

[zmanion]

An idea from CVEProject/cve-schema#218:

2. After a warning to the CNA and a grace period secretariat can create a stub published CVE record pointing to the RBP evidence URL.

This would only work when the RBP is a valid CVE ID (not a typo or other mistake) and a public URL with relevant information exists (e.g., a vendor CNA advisory).

[kurtseifried]

Why not let trusted third-parties publish data? E.g. with hot topics even just a placeholder with a link to something is better than nothing at all.

As for typos/hijacked CVE ID's if the public believes they are real, they are real. One time at Red Hat had a CVE from our reserved pool taken by virtue of a vendor that includes a YEAR-NUMBER in the URL of their advisory, which journalists took to be a CVE reference (MITRE reached out with a "what i going on?" to which I replied "no idea, that's in our pool but we haven't used it yet at all" and then noticing the URL did the trick. If the CVE is "new" why not just roll with it? This also speaks to making CVE id's easier to get.

[kurtseifried]

We currently have 71 GSD entries that have a CVE in the reserved state, and large amounts of data/vendors fixing it, e.g.:

{
"GSD": {
"alias": "CVE-2022-31631",
"id": "GSD-2022-31631",
"references": [
"https://www.suse.com/security/cve/CVE-2022-31631.html",
"https://www.debian.org/security/2023/dsa-5363",
"https://advisories.mageia.org/CVE-2022-31631.html",
"https://access.redhat.com/errata/RHSA-2023:0848",
"https://access.redhat.com/errata/RHSA-2023:0965",
"https://ubuntu.com/security/CVE-2022-31631"
]
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@mitre.org",
"ID": "CVE-2022-31631",
"STATE": "RESERVED"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided."
}
]
}
}
}
}

We'd be happy to fold our data back into CVE (also note a lot of these URLs are from CVE CNAs so they are likely correct and not mistakes).