The field name 'release_date' is confusing, consider changing the name to 'public_date'

[zmanion]

While the documentation is clear, the field name 'release_date' is confusing. Could it be changed to 'public_date' or 'date_public'?

I'd suggest a minor documentation update also: "...the date and time the vulnerability was originally publicly disclosed" (or "published" or "made public").

https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html

3.2.3.11 Vulnerabilities Property - Release Date
Release date (release_date) with value type string of format date-time holds the date and time the vulnerability was originally released into the wild.

3.2.1.12.2 Document Property - Tracking - Current Release Date
Current release date (current_release_date) with value type string with format date-time holds the date when the current revision of this document was released.

3.2.1.12.5 Document Property - Tracking - Initial Release Date
Initial release date (initial_release_date) with value type string with format date-time holds the date when this document was first published.

[santosomar]

You bring up an important point about potential confusion with the term. During the TC meeting on 2028-09-25, we discussed that it's important to note that CSAF documents are sometimes distributed in a non-public manner and may carry classifications such as TLP amber, red, etc. In these cases, the documents are shared with a restricted audience under specific confidentiality protocols (i.e., TLP).

Using the term public_date or date_public might imply that the information is always released publicly, which isn't always the case. The term 'release_date' is intentionally used to encompass both public and non-public releases of vulnerability information. It signifies the date and time the vulnerability was initially disclosed, regardless of the audience or distribution limitations.

[tschmidtb51]

Regarding the Vulnerabilities Property - Release Date - the public release is true, for the Document Property - Tracking - * Release Date this could also be only available to a closed user group (aka intended audience).

[zmanion]

I had not considered a restricted or private "release." But, I think that document/tracking/*_release_date should work for any restricted/TLP level of CSAF distribution.

I'm specifically concerned with the document/vulnerability/release_date, which as defined, seems like it is "date truly public as in on the internet" and which should be true regardless of the TLP. For example, I could deliver a TLP:RED CSAF about a public vulnerability and "date public" would probably be of interest to my readers.

The main issue is just the field name, not the meaning of the field (or any other date fields). It should also be a non-breaking/backwards compatible change.

[tschmidtb51]

I wonder whether we should differentiate for /vulnerabilities[] between disclosure_date and first_known_exploitation_date with

Disclosure date (disclosure_date) with value type string of format date-time holds the date and time the vulnerability was publicly released. If that date is in the future, it states the intended disclosure date.

Note: The date needs to be adjusted if there is a disclosure embargo breach to reflect the true public disclosure.

Date of the first known exploitation (first_known_exploitation_date) with value type string of format date-time holds the date and time the vulnerability was first observed to be exploited in the wild. This does not include the exploitation in lab or testing environments. The date should be set to the best of the author's knowledge and is expected to be revised if earlier exploitations become known.

[zmanion]

Whatever the field name, I think it's useful to have a universally applicable datetime stamp for when the vulnerability is published, i.e., make public, on the internet, in the wild. This can be independent of any private notifications, disclosures, or releases.

[zmanion]

Also a note that while I was previously an OASIS CSAF member, I was not when I filed this issue. Just ran into this during CSAF use.