CSAF files: How to handle multiple versions of the same document?

[carlosthe19916]

While creating this PR #78 I came across to notice that there is the possibility to have multiple CSAF files (each different from the other, in regards of its content) that share the same identifier. E.g.

• Date: Day1.

  • The Advisory MyAdvisory-123 is released.
  • The sha256 of the file is 123456
  • The current_release_date of the file is Day1
  • the initial_release_date of the file is Day1
  • The version of the file is v1

• Date: Day2. For some reason a new version of the same advisory is released

  • The Advisory MyAdvisory-123 has the same identifier
  • The sha256 of the file changed in comparison to the previous one released on Day1
  • current_release_date of the file is Day2 as it is the day when the current document is being released
  • initial_release_date is Day1 because the very first version of the current advisory was released on Day1
  • The version of the file is v2

So how to handle these use cases? We did not need to worry about this so far but is it something to consider now? Is it a priority?

[carlosthe19916]

Not entering into the implementation details here is what I think:

• Multiple versions of an advisory share the same identifier e.g. MyAdvisory-123 or CVE-123 (for Red Hat naming system)
• We can group multiple versions of a single advisory based on the identifier

graph TD;
    MyAdvisory-123-->v1;
    MyAdvisory-123-->v2;
    v1-->sha256_v1;
    v2-->sha256_v2;
    v1-->current_release_date_v1;
    v2-->current_release_date_v2;

Loading

There is still the question about how to import the CVEs included into each advisory without duplicating data but being able to manage evolution over time of entities is something I think we should consider, at least at a design level; unless it is too premature for the first version.

If my understanding of multiple versions of CSAF files is not accurate, my apologies and we can close this discussion

[ctron]

CSAF advisories are written in a way that the newest version should overwrite all versions before.

[carlosthe19916]

But we will still have 2 different files uploaded at different points in time. If the last overwrites the previous one, are we going to keep track of the previous one somewhere?

• "Only the last matters" approach seems valid. Fair enough

I was just opening this discussion in light of understanding if there is any value on keeping track of file versioning. e.g. "day1 the product was affected because Advisory1 said so". But "day2 it seems the product is not affected any longer because Advisory1 has a version 2 and that one indicates my product is no longer affected".

[ctron]

True, there may be two different files in the stream of time. However, you will never know when the supplier/vendor provides a new version. So you might always have the case of skipping one.

On day2 the product would still be affected. As the version of the product is part of that. A vulnerability that is in a certain version of a product won't go away. However, you might get an update. And so the old version is still vulnerable. But then there would be a new version as part of the advisory which is marked as "fixed".

The only real information which might "go away" is the "under investigation" information. and that would anyway only be a temporary state, being resolved by either "vulnerable" or "not vulnerable".

[bobmcwhirter]

fwiw, currently tracking advisories not just by id, but also by hash.

We should still sort/version between them, but every statement related to an advisory should in theory be tied back to a very specific hashed advisory document.