You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noted in latest version of schema the addition of severity but seems to allow for multiple score of the same type without a means to distinguish so if you wanted to favour a severity say from a source it is challenging to work out. Currently there are only in database CVSS_V3 because of this lack of being able to distinguish identical score types should the data struct instead of being
You could even enumerate the types supported but this allows same flexibility bit avoids the doubt around duplicate values as that is simply not valid.
I believe it is too late to make a backwards-incompatible change like this. It would be fine to say in prose that duplicate entries for a given type should not occur.
Thanks for bringing this up! As @rsc mentions, changes in the schema should be backwards compatible. I'm happy to upload a PR adding a line saying that duplicate entries should not occur.
So I would add that but also add types like "CVSS_V3" and "CVSS_V2" as well known types. As you have lost the key you effectively need to now manage this enumerator.
I noted in latest version of schema the addition of severity but seems to allow for multiple score of the same type without a means to distinguish so if you wanted to favour a severity say from a source it is challenging to work out. Currently there are only in database CVSS_V3 because of this lack of being able to distinguish identical score types should the data struct instead of being
as types really should be unique base don this
You could even enumerate the types supported but this allows same flexibility bit avoids the doubt around duplicate values as that is simply not valid.
So what is done today in the database would be;
The text was updated successfully, but these errors were encountered: