Change database schema to accommodate different types of severity indicators

[sbs2001]

Repaste from gitter :

@sbs2001
Mar 04 14:53
Btw, I wanted to start discussion regarding storage of severity indicators: The problem is different advisories provide severity scores in different formats, for example cvss v1,cvss v2,cvss v3,cvss v3.1 or just textual description(High,Low,Medium). I can think of 2 approaches:

1. Make separate columns for each type of severity indicator for model Vulnerability.
   OR

2. cvss scores of different versions can be interconverted by manipulating the attack vector, this adds some error (upto 5%). This way we will have 2 columns to indicate severity one for cvss score of the latest standard and other for textual representation of severity.
   What are your opinions?

[sbs2001]

Other approaches I can think of is having 2 columns for cvss, 1st column will store the version of cvss and 2nd column will store the score .

Or have a single column for severity with datatype JSON eg 'cvssv1:5','cvssv2':8'

[pombredanne]

What about having something tad different?
I do not want us to be limited to CVSS which is a rather complex system and we know tat there can be several interpretation of them for the same vulnerability.

IMHO we should have instead three data points for each score:

• like for a reference, some source URL of sorts where that score was published
• a type of score (cvss, etc)
• the score value itself.

And since there can be many of these, we make that a model of its own.
This is a tad heavier but this is the correct model IMHO.
It could be toned down to a single JSON field, but that does not help much with queries

[pombredanne]

A third an likely cleaner approach is based on the facts that we know that:

1. there are multiple scoring mechanisms aka. "scoring type" (some formal cvssversion, or informal high/medium/low)
2. for a "scoring type" there can be different interpretations from different "sources" leading to different "score"

So IMHO you could get these "type, source, score" in a Score table that has has a foreign key to a Vulnerability much like a Reference of sorts.

Single JSON columns get messy quickly and are best avoided, and limiting ourselves to the CVSS scores is not enough IMHO.

[sbs2001]

@pombredanne I think the new VulnerabilityReference from #206 takes care of this. Apart from different versions of cvss and sometimes indicators like MEDIUM , there seems no other scoring system, so IMHO having the severity indicators inside VulnerabilityReference seems more appropriate, since it also contains all things you mentioned, so we won't lose on context.

[pombredanne]

from #18 (comment)

We can also interconvert between cvss v2,cvss v3,cvss v1 . We need to do this since not all advisories use same cvss version. https://security.stackexchange.com/questions/127335/how-to-convert-risk-scores-cvssv1-cvssv2-cvssv3-owasp-risk-severity shows how to do this .

[sbs2001]

Here's the repaste of @pombredanne 's notes of the chat we had recently about this issue

Vulnerability: CVE-2020-12100

References
- NVD ref1 URL:https://nvd.nist.gov/vuln/detail/CVE-2020-12100
- Mitre ref2 URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12100
- Gentoo ref3 URL:https://security.gentoo.org/glsa/202009-02
- OpenWall ref4 URL:https://www.openwall.com/lists/oss-security/2020/08/12/1
- RedHat ref5 URL:https://access.redhat.com/security/cve/cve-2020-12100

Score1
- For Vulnerability: CVE-2020-12100
- Type: CVSS2
- Value: base:5.2 vector: XXXXXXX/YYYY/ZZZZ
- From Reference: NVD ref1

Score2
- For Vulnerability: CVE-2020-12100
- Type: CVSS3
- Value: base:7.5 vector: XXXXXXX/YYYY/ZZZZ
- From Reference: NVD ref1

Score3
- For Vulnerability: CVE-2020-12100
- Type: CVSS3
- Value: base:7.5 vector: XXXXXXX/YYYY/ZZZZ
- From Reference: RedHat ref5

Score4
- For Vulnerability: CVE-2020-12100
- Type: Redhat-scale
- Value: Important Impact
- From Reference: RedHat ref5

Score5
- For Vulnerability: CVE-2020-12100
- Type: Gentoo-scale
- Value: normal
- From Reference: Gentoo ref3

Score6
- For Vulnerability: CVE-2020-12100
- Type: CVSS3
- Value: base:7.5 vector: XXXXXXX/YYYY/ZZZZ
- From Reference: OpenWall ref4

In the future we may get 
Score7
- For Vulnerability: CVE-2020-12100
- Type: VCODE
- Value: 0-High
- From Reference: Vulnerable Code refYYYY


Say we first collect the JSON from NVD for CVE-2020-12100
1. we create a vuln
2. we create several refs including one for the NDV record itself
3. we relate the vuln to packages. We may create some packages
4. we create two scores: Score1 and Score2 that we relate to the current  NDV record ref

Later:
1. we collect Gentoo vulnerabilities and stumble on Gentoo ref3 URL:https://security.gentoo.org/glsa/202009-02
2. we try to create a new ref related to the existing vuln... (but in fact we find it exists because it was created above)
3. we create a score for Score5 and relate it to this ref


Still later:
1. A VulnerableCode contributor provides another score: High
For this we would have some data entered and stored in some models TBD.
This record and its URL becomes a reference
2. we create a new score pointing the vuln and that reference (that happens to be stored in our DB somehwere)



How do we use the scores?

1. used for filtering
- show me vulnerabilities above some score
- show me packages with vulnerabilities above some score

2. used for display
- give me all the scores for a package vulnerability


Typical workflow leading with packages:
1. detect packages in use --> get some PURL
2. lookup in VC for these packages and possibly filter filter on score

Or with vulnerability:
1. Filter vulnerabilities above some score (possibly new ones)
2. list all packages that are affected --> get some PURL
3. Search is these PURLs are in use anywhere


Some issues:
- filtering has to be for a type?
- what if we have more than of the same score type with different values?
- Could we have our own score average? based on what model?
- Our we just provide our own new scale?
- When querying by package the scores of that package type should be more prominent?