Feature request: CVSS v4 scores/vector support

[jostaub]

Hi,

Currently, DefectDojo only "supports" CVSS Version 3.x. By "support," I mean that the fields in the Findings model and the integrated CVSS score calculator are specifically named and structured around CVSS v3. In the past, there have already been separate issues discussing support for different CVSS versions (e.g., #9378 and #12365). Now that CVSS 4.0 is gaining broader adoption (e.g., the EUVD uses it), this topic is becoming more relevant. I think it would be practical to have a version-agnostic way of storing score and vector data, since this would allow users to freely choose which CVSS version to use without modifying the DefectDojo data model or having contradictory information in field names.

A previous, now-closed approach (see #9380) proposed adding new CVSS-specific fields to the Findings model. In my opinion, this kind of solution risks cluttering the model over time as more versions emerge.

Proposed Solution:
I propose a refactor of how CVSS data is stored in the Findings model. Instead of embedding the CVSS version into the field names, DefectDojo should generalize the field structure and store only the version agnostic core data:

• cvss_vector instead of cvssv3
• cvss_score instead of cvssv3_score

Additionally, I suggest introducing a new field: cvss_version, which would explicitly store the CVSS version used. Ideally, this field wouldn’t be necessary—since the version is usually part of the vector—but some data sources (e.g., OpenVAS CSV reports) do not include the vector, only a numeric score. In such cases, being able to specify the version used to generate the score could be useful (especially if there would be an "Unknown" version choice). Another benefit of having a separate cvss_version field is that it allows users to explicitly choose which CVSS version to use when manually adding a finding. However, one could argue that this could be handled purely as a UI feature, with the CVSS version inferred from the score prefix—since using the prefix is part of the specification. That said, this approach could introduce complications if the vector needs to be processed further.

Advantages:
Ideally, this approach enables the easy addition of future CVSS versions (simply add a new value to the allowed values like in the severity field), as long as the underlying paradigm of score and vector remains consistent. Furthermore, it allows users to freely choose a CVSS version while maintaining clean and consistent variable naming in both the UI and source code.

Disadvantages:
This change may break compatibility for applications relying on the current DefectDojo API. However, it should be feasible to map cvssv3_score and cvssv3 to the new generalized fields (cvss_score, cvss_vector) and provide a deprecation warning, with full removal in a future major release.

I’d would be happy to hear/read the thoughts of the community and maintainers on this approach. I’m willing to implement the change myself if it receives sufficient approval (I believe it may touch files currently affected by the feature freeze).

[valentijnscholten]

This was my initial thought as well. But I think we should support both v3 and v4 in paralllel. There are (some) reports that provide both. And depdning on the user they may want to use v4 because it's newer. But some corporations have standardized tools/reports/complaince on v3. I haven't looked at any metrics or reports that are based on cvssv3 on Defect Dojo, but in general I think it's easy to support both in parallel.

[jostaub]

Given the idea of supporting two CVSS scores/vectors per finding, what do you think about introducing two categories of CVSS data per finding: a Primary and a Secondary?

We could expose a setter function that parsers use to assign CVSS data, defaulting to the Primary category. This could also be made user-configurable, allowing users to define which CVSS version (e.g., v3 or v4) should be stored in the Primary category. That way, users who don’t care about specific versions can rely on the default behavior, while those who want consistency can enforce, for example, that v3 always goes into the Primary slot. Parsers that report both v3 and v4 could then sort the data into the appropriate category based on this configuration.

This approach would give organizations flexibility in choosing which version to prioritize, while still benefiting from the earlier proposal. However, it would also make the implementation more complex.

Alternatively, if we dropped the idea of supporting two simultaneously CVSS scores/vectors per finding and instead relied on the filtering approach (as discussed earlier) combined with the initial idea of version agnostic CVSS data, the implementation would be simpler. This would still allow organizations to enforce a consistent CVSS version. For instance, if a parser detects both v3 and v4 scores, the filter could be configured to only populate the CVSS data with the v4 version and optionally store the other (e.g., v3) in the notes or a similar secondary location.

[valentijnscholten]

I feel we don't know enough about how users use v4 vs v3 to warrant a complex prioritization scheme. I think for it's fase to just store both values are all we are doing with them is display them. Once v4 becomes more prevalent we can look at adding feature flags to control some behavior such as which columns are displayed. One thing that currently may happen in some parsers is that they use the vector to determine severity. If needed we can already add one feature flag now to control which vector is selected for this.

[jostaub]

I think you're right, my idea might be over complicating things to much. (I updated the title to better reflect the current state of discussion).

CVSS V2 "support" was requested in #12365. Is this something that DefectDojo wants to "support"? Since this it would basically require the same changes as for V4 and so could be easily implemented together.

[valentijnscholten]

Anyone reading this, please provide feedback on the PR (#12751). There are some open questions.