[RSS] Don't Be a CVE Dummy

https://jericho.blog/2024/11/28/dont-be-a-cve-dummy/

"So please, if you are writing documentation and need to use dummy CVE identifiers, please use one of the ones MITRE designated a decade ago"

@buherator That’s a nice bit of CVE lore! We should make these more obvious and prominent than a single blog post.

And yes, having a small set of always-valid-but-test CVEs would be nice to publish. That’s a neat idea.

Hey would it be cool to make them Luhn-formula-like so you can detect truncation?

Something like

CVE-2024-12342
CVE-2025-12343
CVE-2026-12340

(all the digits add up to modulo 0)

cc @zmanion

@todb @zmanion Based on the post I'm afraid including error detection in new ID's would cause a Hell of a mess at the consumers side :(

@buherator @zmanion yeah there's no real appetite for this kind of checksumming for all CVE IDs (or is there?). That would be a radical change. But for test CVEs? Maybe useful!

@todb @buherator Well the new-ish rules say to use "CVE-1900-*": https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_5-4_Example_or_Test_CVE_IDs

Does anyone know how @attritionorg made that list? Seems similar to examples here: https://cve.mitre.org/cve/identifiers/syntaxchange.html

@todb @buherator I'd be down with annual automated reservation of a documented set of example IDs, if people really want current-looking examples. I think "CVE-1900-*" is simpler tho.