Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Severity schema should it be a map rather than an array? #34

Open
MikeMoore63 opened this issue Mar 2, 2022 · 3 comments
Open

Severity schema should it be a map rather than an array? #34

MikeMoore63 opened this issue Mar 2, 2022 · 3 comments
Assignees

Comments

@MikeMoore63
Copy link

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

"severity" : [
    {
         "type":"string",
         "score":"string"
    }
]

as types really should be unique base don this

"severity" : {
     "type_key" : "score"
     ....
}

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;

"severity" : {
    "CVSS_V3": "CVSS v3 score uri"
    "CVSS_V2":"CVSS v3 score uri"
    "ANotherseverityscore": "An other score"
}
@rsc
Copy link

rsc commented Mar 2, 2022

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.

@oliverchang oliverchang self-assigned this Mar 3, 2022
@oliverchang
Copy link
Contributor

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.

@MikeMoore63
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants