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.

[santosomar]

During the CSAF TC meeting on 2024-11-27, there was a discussion about this issue (to Differentiate Between disclosure_date and first_known_exploitation_date in CSAF Documents)

A few folks suggested not to include these fields. However, for the purpose of documentation and awareness. The suggestion is not to include these as mandatory fields.

It will be good to introduce a differentiation in the /vulnerabilities[] section of CSAF documents by defining two distinct fields: disclosure_date and first_known_exploitation_date. These fields will serve different purposes and follow the guidelines outlined below:

1. Disclosure Date (disclosure_date):

   • Type: String of format date-time.
   • Definition: Holds the date and time the vulnerability was publicly disclosed.

2. Date of First Known Exploitation (first_known_exploitation_date):

   • Type: String of format date-time.
   • Definition: Records the date and time the vulnerability was first observed to be exploited in the wild. This is good for representing CISA KEVs, etc.
   • Exclusions: Does not include exploitation in lab or testing environments.

Rationale:

• An OPTIONAL field, that clarifies the distinction between when a vulnerability is disclosed and when it is observed to be actively exploited.

Action Items:

• Send a call to action to the TC about this issue and obtain additional feedback from the TC.

[mipfu]

Naming is hard :)

my 2 cents:

Date Timestamp field have the tendency to be used inflationary in any data model.
Therefore a naming convention is helpful.
From my personal experience a best practice is
a _ convention.

• publish_date -> datetime_published
• first_known_exploitation_date -> _date_first_known_exploited
• disclosure_date -> date_disclosed

It helps to understand that "from that timestamp value on the status changed to the verbs state. e.g published"

using the present-verb raises the abiquity if it was intended to be published or actually published at that date or was it published.
For the first use datetime_publishing vs datetime_published