CSAF: `revision_history` not implemented correctly

[tschmidtb51]

I had a quick look at the CSAF files produced by CERT/CC's VINCE instance: The revision_history and /document/tracking/version information differs from the human readable advisory, e.g. VU#572615: CSAF:

      "revision_history": [
        {
          "date": "2023-01-23 14:36:26.452412+00:00",
          "number": "1.20230123143626.4",
          "summary": "Released on 2023-01-23 14:36:26.452412+00:00"
        }
      ],
      "status": "final",
      "version": "1.20230123143626.4"

Human readable version:

Date Last Updated:	2023-01-23 14:36 UTC
Document Revision:	4

Looking at the CSAF, it looks like semantic versioning. However, looking at the current implementation, I doubt that this is actually the case. The human-readable version suggests that CERT/CC uses internally integer versioning. So I would suggest to use that.

[sei-vsarvepalli]

Hello @tschmidtb51

This is on purpose as we have two API's that release CSAF documents. The public API and the private authenticated API.

The private API has a different data inputs and public has different inputs. The revision numbers are also tracked in distinct ways. The attempt is to try to give

https://github.com/CERTCC/VINCE/blob/9728c0533523075137df7c8066d701f685b24716/vincepub/serializers.py#L197-L207

https://github.com/CERTCC/VINCE/blob/9728c0533523075137df7c8066d701f685b24716/vinny/serializers.py#L300-L307

Doing the semantic version helps us track these two distinct datasets with modified_date as a way to distinguish and sort the various versions. The private API can provide more distinct versions and these may NOT get published (or get published later) but will be available in the private API.

The assumption is that CSAF versioning can be different from what versioning gets displayed in the website. If you believe this can cause confusion, we can display the same versioning as CSAF Version field as an additional row or in parentheses to indicate the API based version and how it matches.

Thanks Vijay

[tschmidtb51]

Well, the issue, I see, is that the it looks like it violates rule 6 and 7 from the semantic versioning.

Also, the revision_history shows always only one element - so the first element (from the initial publication) is updated over and over, instead of adding new elements. This was actually the main reason, why I opened the ticket.

If there is a difference between the "human-readable version and the machine-readable one, feel free to add the value from the human-readable advisory into legacy_version field to those items in the revision_history that match public versions.

Does that make it clearer?

[sei-vsarvepalli]

Thanks this information is very helpful..

We have another ticket in our internal VINCE system which is related to this topic. Being able to provide CHANGELOG And track changes as public release comes out. Currently there are three instances of a Vulnerability Notice, (1) one available only to Coordinators, (2) a version available to Coordinators and Vendors (all authenticated participants) and (3) the version published for universal consumptoin. All these are currently tied together by a single VU# identifier. Perhaps they can be distinct advisories and just have relationships to each other? OR we just version numbering with iteration that identifies these as all related advisories. If we do the later, we ideally follow your SemVer requirements particular to CSAF and keep these advisories in their own format.

Vijay

[tschmidtb51]

IMHO related advisories might be the easiest option here... Happy to discuss the options in detail during our next meeting