Specifying vulnerable range for services or software with no version

[ccoffin]

It's fairly common for open source software to not include a version. It is also common for cloud services to not include a version, at least publicly. Should the CVE Record format include a version type that allows a vulnerable date (start or end date) or range of dates in place of a version or version range? Also, would this be sufficient to meet the requirement for having at least one version in a CVE Record?

[darakian]

Conceptually I think it could make sense to try to have a date format for these. Ideally it would be start and end dates, but maybe for operational reasons we only require one (either) at time of publication? Date formats are pretty well defined so we should be able to add strong, interoperable validation pretty easily too. Would we want to restrict usage of this date version type to cloud vendors? How do we enforce that if so?

[alilleybrinker]

I agree, a date format makes sense. Some questions, and my preference:

• Should it be a date/time or just a date?
  • Yes, it should have both. CVE is used internationally, we should be as precise as possible about time.
• Should it include a timezone?
  • Yes, for the same reason as above.
• Should it be restricted to cloud vendors?
  • I don't believe it should. It should be usable by any CNA.
• Want combinations of inclusive/exclusive on either end should it support?

To the last question, the options are:

Start	End	Meaning
Yes	No	Known start date, unknown end date; hopefully temporary until a CNA issues a fix.
Yes	Yes	Known start and end date. Most informative.
No	Yes	Unknown when a vulnerability first appeared, but known fix date.
No	No	Unknown start or end, should be disallowed; recommend defaultStatus instead.

[darakian]

Agreed on point 1.
On point 2 I think it would be nicer from a record consumer point of view if all dates were in one timezone (UTC). Perhaps cve services could accept records with any timezone and normalize to UTC? Perhaps there are risks there I don't see and normalization isn't nice enough to warrant those risks.
On point 3, I'm not sure I agree. I (as a record consumer) would prefer software with versions have vulns expressed with those versions. I fear that some "researcher" types might get lazy and default to dates.
On point 4
Yes/No: Agreed, hopefully temporary. It would be nice if we had some CVE police to enforce that temporary-ness
Yes/Yes: Ideal case.
No/Yes: Probably the common case and in my opinion its good enough to be useful to a reader.
No/No: Agreed. I would also want to disallow this case.

As far as validation/format; I assume iso8601 is everyone's preference, but we should formalize it as well as how specific we want to be. Maybe we require precision to the hour and allow for minute/second/sub-second? Require offset from UTC unless we normalize on UTC.

[ccoffin]

On point 3, I'm not sure I agree. I (as a record consumer) would prefer software with versions have vulns expressed with those versions. I fear that some "researcher" types might get lazy and default to dates.

It's not just the researcher though. There are definitely cases where a product does not have versioned releases. Lots of GitHub project cases that don't have releases/versions, though they could use the commit hash in that case. Does a commit hash always work for everyone though? Would a date be better for some?

[darakian]

I would argue that the commit hashes are versions, but to your questions

Does a commit hash always work for everyone though?

Probably not, but maybe?

Would a date be better for some?

Maybe? Git does store date information so if the reader has access to the source they can query the commit to get date information. It's certainly the case that hashes would be less ergonomic for many common case cve record consumers.

[alilleybrinker]

I've drafted up a variant of a recent CVE, rewritten to use an imaginary dateVersion type to express something like "versioning" with date/time information.

https://gist.github.com/alilleybrinker/cedb5fdf8c7946b1d111a8fffeab00b4#file-better-cve-2025-32711-json-L41-L48

This is not a full design; we'd still also need to resolve the specifics of what date/time format is acceptable.

[alilleybrinker]

Some folks in the QWG have raised that it may instead make sense to distinguish the "temporal window of exposure" from the "vulnerable versions", perhaps by introducing a new field within the product object in the affected array.

Other options would be...

1. To only permit the use of date versions for records tagged as being for exclusively-hosted-services, or
2. To constrain it only to product-owners, not to third-party CNAs.

[alilleybrinker]

Also raised: there is a concern that some CNAs may fallback to date information only, as its easier for them, if given the ability to use it as a version. The group may therefore want to constrain the instances when a "date version" can be used.