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

Incorrect severity score due to identical Reference URLs #1597

Open
keshav-space opened this issue Sep 23, 2024 · 4 comments
Open

Incorrect severity score due to identical Reference URLs #1597

keshav-space opened this issue Sep 23, 2024 · 4 comments

Comments

@keshav-space
Copy link
Member

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.

Screenshot from 2024-09-23 14-01-15
Screenshot from 2024-09-23 14-01-02

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.

@TG1999
Copy link
Contributor

TG1999 commented Sep 24, 2024

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
Copy link
Contributor

TG1999 commented Sep 24, 2024

  • 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
Copy link
Contributor

TG1999 commented Oct 15, 2024

Blocked by this #1612

@pombredanne
Copy link
Member

pombredanne commented Oct 31, 2024

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

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

No branches or pull requests

3 participants