VulnDB Vulnerabilities Always Shown as Unassigned Severity

[LaVibeX]

Current Behavior

Currently in the latest master version, all VulnDB vulnerabilities consistently display an “Unassigned” severity. This can be misleading for users who rely on accurate severity information. This should be addressing promptly to ensure that users receive reliable data regarding vulnerability severity.

Additionally, this issue affects the new Audit Vulnerability counter integrated by PR #736. When all vulnerabilities originate from VulnDB, the severity counters will display 0 in all fields, and the green counter will also be 0.

Steps to Reproduce

1. Go to the vulnerability section.
2. Examine the severity field for any VulnDB vulnerability.
3. Associate a VulnDB-related CPE with a sample component.
4. Verify the Audit Vulnerability counter after implementing the changes from PR #736.

Expected Behavior

• The severity field should accurately reflect the severity level of each vulnerability based on available data.
• The Audit Vulnerability counter should correctly account for VulnDB vulnerabilities.

Dependency-Track Version

4.11.0-SNAPSHOT

Dependency-Track Distribution

Executable WAR

Database Server

PostgreSQL

Database Server Version

No response

Browser

Google Chrome

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[lukas-braune]

Just a remark: I cannot confirm this as an issue of DT v4.10.1. It seems to be a regression from a later revision.

[nscuro]

Indeed it might be a regression introduced in #3408

In short: DT before 4.11 did not store the severity in the database, unless explicitly set by the user. Instead, it would compute the severity based on CVSSv2, CVSSv3, and OWASP RR scores whenever the severity was accessed. This made it impossible to reliably query by severity, hence we changed that behavior in the PR mentioned above.

Seems like we missed VulnDB there.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.