add 30 day urgency metric

[zmanion]

cc @wadesparks @ccondon-vc @cve-team

IMO this should be lower than 30 days, but propsing 30 as a starting point. As worded in this PR, age of public disclosure is not the only factor, but it could be made a strict requirement in the future.

Older than X: MUST not DIBS
Newer than Y: MUST DIBS
In between Y and X: MAY DIBS

[wsparks-vulncheck]

I support the idea of nailing down a timeframe as one determining factor in DIBS eligibility. We’ve talked before about what makes sense (e.g., <14 days, <30 days), but we’ve never put a firm stake in the ground. This should be one of many signals of CVE “hotness” and therefore DIBS eligibility. At the end of the day, I think CNAs know a DIBS when they see one, and I worry that rigid requirements for an optional process will discourage participation (which we are already lacking if we are being honest).

[patrickmgarrity]

While I agree that defining a clear timeframe is important and 30-days seems like a good starting point, I am concerned about any requirement, explicit or implicit, for a CNA-LR to ACK in order for the timer to conclude.

A core principle we previously discussed is that DIBS was not designed to become a CNA-LR permission-based system forcing research CNAs to ask for permission before assigning CVEs ("Mother May I"). I am concerned that this proposal moves in that direction. Introducing an ACK requirement makes assignment contingent on approval rather than on the absence of a collision, which risks unnecessary delays and effectively turns CNA-LRs into blockers for high visibility, high risk, and urgent vulnerabilities.

If consensus mechanisms require CNA-LR approval to proceed, the process shifts toward centralized, permission-based decision making. This can delay CVE issuance even when no competing claim exists, which is not what DIBS was designed to accomplish.

[zmanion]

Despite the minor editorial changes, the core of this PR is:

Vulnerabilities that have been Publicly Disclosed less than or equal to 30 days SHOULD be considered as Urgent. Vulnerabilities that have been Publicly Disclosed more than 30 days SHOULD be considered as Not Urgent.

This was meant to align with @wadesparks's comment (and previous RWG discussion) that time (age) of Public Disclosure should be one factor. Being time, it's somewhat easy to measure, so lets set a 30 day stake in the sand and move it later if needed.

[zmanion]

@patrickmgarrity I share your concerns about over-centralization, approvals, and delays, but I don't think this specific change/PR affects those concerns. This timer is just to help define when a vulnerability is urgent enough (hot or not) to qualify for DIBS. It's also worded as SHOULD, not MUST.

[patrickmgarrity]

The dif of the PR has changes that pertain to CNA-LR language which expand beyond adding a 30-day metric which is why I put the comment I did...

[zmanion]

Thanks I see what you mean, but I'll argue that any changes about "CNA-LR" are purely editorial, that is, the existing DIBS language already says that the process should end in "CNA-LR" if the vulnerability is Publicly Disclosed and Not Urgent. We could (maybe should) rewrite that part of DIBS to say something less, like "if Not Urgent then not DIBS, follow the main rules?" But in a separate issue/PR, and maybe after some discussion? I suggest we treat these independently, as in, this issue is only about adding the 30 day "hot or not" boundary.

@patrickmgarrity IIUC your concern is that the current CVE CNA Operational Rules (4.2.1.2) say that for "...Publicly Disclosed Vulnerabilities, if the CNA with the most appropriate scope" doesn't act within 72 hours, then a Root/CNA-LR MUST act? A current rules change under discussion is to better define 4.2.1.2 and "most appropriate scope" in a way that allows other CNAs to act, esentially after the Supplier CNA (if they exist) and before the Root/CNA-LR (reminder, "LR" means "last resort").