fix: don't fail deserializing the document if CVSS can't be parsed

[dejanb]

Currently the deserialization of the document fails if CVSS v3 can't be parsed. This can happen if the CVSS vector string is malformed or parsing library can't properly handle the value (like temporal scores for CVSS v3).
Instead of failing, we should store the original vector string and the score, so that the user can get the original values and handle them as needed. This will also allow us to to have the original CVSS vector strings in the output for versions currently not supported by the CVSS library and enable future support for CVSS v4 in CSAF more easily.

[ctron]

I somehow doubt that a change like that would ever go into upstream. Which means that having that patch and using that logic, we'd forever need to maintain our own fork. I don't think that's wise.

Instead of taking a shortcut like this, we should go and actually implement what is missing.

[dejanb]

I don't think it's a shortcut, the v2 is already returning just a raw value and all other libraries we are using (cve and osv) let the score handling to the client as well. For example, for our use case, I would like to have original vector string from the document, which would currently be impossible without deserialize/serialize everything (which would not guarantee that we would get the original value for all use cases).

The uplstream of this library seems to be abandoned project, so the maintenance is on us . Should we move this scm-rs. I suppose the goal would be to use (https://github.com/csaf-rs/csaf/) when it gets ready.

I was thinking to go back to cvss_v2 and cvss_v3 fields instead of the vector, as that is more natural and change the API less.

If a change like this is too much, I would see to at least make the client library can recover from this error gracefully and get the original score(s) in the error that it can handle on its own. It will take a bit more time for the cvss library to be able to support all versions properly, so this issue will come up regularly.

[ctron]

I agree that we should take ownership (or fork) that library. And I think it's ok to just define this as a String. And let some other part deal with this.