Incorrect severity score due to identical Reference URLs

[keshav-space]

When multiple distinct scores have the same reference URL, we end up overwriting the VulnerabilitySeverity.
See the SUSE example below, where different vulnerabilities have identical sets of severity.

The bug is in how we handle the VulnerabilityReference. Each VulnerabilityReference has a URL that is set to be unique. To store a severity for vulnerability, we create a VulnerabilityReference (using the source URL of score) and then create a VulnerabilitySeverity (with severity details and ForeignKey relationship to VulnerabilityReference created earlier). Since the URL field is set to unique, things get complicated in the case of SUSE as all the scores come from the same URL i.e. "https://ftp.suse.com/pub/projects/security/yaml/suse-cvss-scores.yaml." This results in a single SUSE VulnerabilityReference linked to all vulnerabilities, which leads to a same set SUSE severity score for all vulnerabilities.

This might not be limited to SUSE alone, there is a high chance that other severity scores were also overwritten.

• Refrence Suse scores importer should support version 4 #1592 (comment)

[TG1999]

We should have severity on vulnerability and package-vulnerability relationship if we don't have severity on the package-vulnerability relationship then we should use only the vulnerability severity.

[TG1999]

• Start with tests to see what's breaking
• Refactor VulnerabilitySeverity models, disassociate severity from reference. And attach severity on vulnerability and package-vulnerability relationship

[TG1999]

Blocked by this #1612

[pombredanne]

Here are a few practical todos:

1. We need to disable the the display of score ranges in the VCIO and DJCD web ui, remove it from the APIs
2. The "Package vulnerability risk" index designed in CRAVEX: Calculate Package Vulnerability Risk #1543 will be the way to go and is under review in Add support for Calculating Risk in VulnerableCode #1593

[keshav-space]

@nnobelis Thanks for pointing this out. This has now been fixed in #1636. The correct SUSE score should be available on https://public.vulnerablecode.io/ after the next release.

Before	After

Before	After