Add a CVE Triage Checklist to the rules

[todb]

Hello, CVE! Please see this proposed update to the rules! It actually doesn't change or add or remove any rules, but instead, offers a cheat sheet for CNAs to answer basic questions of "should I write a CVE for this bug?"

We think it would be useful to incorporate this into the rules directly. I'll follow this up with a note to the CVE Board for discussion.

[zmanion]

SPWG briefly discussed this today, in general terms of "companion documentation." Rough consensus in SPWG is that this is useful but should live separately from the official Rules document.

[todb]

Bump. Would love to get this in on the 4.2.0 release.

[todb]

SPWG briefly discussed this today, in general terms of "companion documentation." Rough consensus in SPWG is that this is useful but should live separately from the official Rules document.

This will ensure that precisely the people who need it will never find it. :/

[zmanion]

Is a pointer good enough?

1.6 Shortcut Checklist

Go <here> for the short version.

[todb]

mwahhh okay. Yes. Sure. Let's do it. I can publish this triage in a gist or something. Or we can drop it in a triage.md in this repo so it'll get version tracked properly.

[todb]

Fixed @zmanion ?

[Santoshkumarpuppala]

Reading this as a CNA-adjacent researcher rather than a CNA — I do open-source vulnerability research and the "should this get a CVE" call is the one I make most often, so a cheat sheet like this is genuinely welcome. Two substantive notes and two trivial ones.

The substantive one: 1.3 is where I'd expect the most common rejection to appear, and it isn't there. I keep a labelled record of every candidate I've investigated and rejected — around 550 — and roughly half fail for a single reason: the caller was already entitled to the capability. Not a missing check, but an actor operating inside its intended trust boundary, where the behaviour looks alarming precisely because the privilege is real. The closest existing bullet is "a documented non-default configuration change made by an authorized user," which is narrower — that's about configuration, and this is about capability. Something like "the behaviour is reachable only by an actor already entitled to that capability" would cover it, and I think it would retire more borderline submissions than any other line in the list.

Two smaller gaps in the same section. "The issue is in a Product that was never publicly available" covers products that never shipped, but not code that never shipped inside a product that did — main-only bugs are common and don't have a home here. And there's no reachability criterion at all: a sink that's genuinely dangerous but gated upstream, or unreachable through any exposed path, reads as assignable under the current text. Both are frequent in my rejects.

On the closing line — "if the decision is close, the CNA with the most appropriate Scope should prefer assignment" — I'd flag it rather than argue it. It's a reasonable default when the risk is under-assignment. My own data points the other way: when a call feels close, the reason is usually that an entitlement question hasn't been resolved yet, and resolving it usually ends in "no." I don't think that generalises beyond web-application authorization, which is my corner, so take it as one practitioner's experience rather than a case for flipping the default. But it may be worth saying which failure the default is chosen to avoid.

Trivial: CVE_Triage.md is titled "# 1.1 CVE Triage Checklist" and its first section is also "## 1.1", while CNA_Rules.md points at it as 1.6 — worth reconciling before it lands. And there's a typo, "for eample", in the DVWA bullet.

Also — on the placement discussion above, for whatever an outside view is worth: the concern that a separately-filed checklist won't be found by the people who need it seems right to me. A pointer in the Rules is much better than nothing, but as a new reader I'd only have found it because it was linked from something I was already reading.