How does CSAF [consumers] implements and consume handling CVE description updates/CVSS rescore

[jeandominoserver]

Hello,

@mreeder && I are wondering how and if any of our Companies are handling updating CSAF records post publication once there is an update in the corresponding external dependecy MITRE record ?

Section 3.7 of the CVSS3.1 scoring User Guide : the score must be re-calculated for that specific implementation

Section 3.9 of the CVSS4.0 scoring User Guide: the metric values must be re-assessed for that specific implementation

With that context now laid out; i am wondering how CSAF can handle and if our TC/CSAF standard should care about the potential discrepancies those actions could inject between the consumer of a dependency performing their own scoring according to the CVSS Scoring user-guide VS the public CVSS scoring.

Further to that, if publishing external dependencies scoring as part of your CSAF payloads, what is the guidance with regards to those external dependencies being re-scored post the initial public disclosure/communication ?

Also, wondering if any of us as part of their CSAF implementation have envisioned such a use case and what decision did you came up with ?

Thank you all,

Sincerely,

JD

[jeandominoserver]

adding @tschmidtb51 to awareness.

[tschmidtb51]

tl;dr: Check (favorably) if an update to the CSAF document is necessary and provides added value to the reader

---

A CSAF document is a "point-in-time" knowledge document: It conveys the information that you had at a specific point in time - therefore, we need the revision history and the initial / current release date.

In general

A CSAF document should be updated, if significant new information is available. In the case of a security advisory, new information might be a new / alternate vendor fix or a new product status (e.g. a product was under investigation and has now been found to be (not) affected).
An exception is, if the document hasn't been touched for years...
Note that it is not expected to update all old advisories for each new, fixed product version after the first one has been published.

Regarding CVE updates

IMHO usually, they make sense. So if you copied the CVE description (and didn't modify it for / tailored it to your product), go ahead and update the CVE description. Probably, you need to revisit your investigation result anyway as the new CVE description might provide additional insights which might have an influence on your assessment / remediation. Do not forget to flag in the revision history, that the CVE description has been updated in such a case.

Regarding CVSS updates

A CVSS score applies to a specific product. So also today, you should make sure the CVSS vector is correct for your specific product. This is also in line with the sources you linked. In many cases, CVSS is not used correctly as people think there is the one CVSS score for a vulnerability. However, CVSS has it built-in that you re-assess the vulnerability for your specific environment: This might be a customer environment or the environment of your product. The latter naturally results in the CVSS vector for your product - just make the modified values the base values to allow the next person in the chain to make their own CVSS environment assessment.
CSAF 2.1 introduces the source for all metrics elements: It allows you to provide different assessments for one product.
BTW: AFAIK, Red Hat re-scores all upstream vulnerabilities for their products (in the security advisories).

[tschmidtb51]

@jeandominoserver Does that answer your question (at least from the standards / BSI's perspective)?