Add CVSSv4 support to Dependency-Track

[tobiasgies]

Description

This adds support for CVSSv4 scores to Dependency-Track. Scores are stored in the database, will be returned as part of the relevant HTTP API resources following existing conventions, can be updated via the REST API, and will be processed by parsers for most vulnerability sources. They will also be preferred over CVSSv3 and CVSSv2 scores when determining the severity of a vulnerability.

Addressed Issue

fixes #4707

Additional Details

CVSSv4 handling not implemented in certain parsers

The following parsers do not have handling for CVSSv4 scores added by this PR, since the APIs they are based on are commercial offerings that I do not have access to:

• Snyk
• VulnDB

Only backend work completed for now

This PR obviously only addresses the server / API side of implementing CVSSv4 support. I am planning to work on support in the frontend next, but wanted to put my work on this repository out there first. I hope to get some feedback on this so I don't run in the wrong direction with any frontend changes.

Trivy protobufs updated

To be able to process CVSSv4 scores supplied by trivy, I have updated the protobuf files stored in this repo to the state of their release/v0.67 branch. I have kept the customizations / changes to the headers of the protobuf files the same, though. For the remainder of each protobuf file, I chose easier copy/paste-ability in the future over keeping the diff small. I hope that's okay.

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly
  • NOTE: This is likely an open to-do item and I'd love some feedback on what needs documenting.

[owasp-dt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ -0.02% (target: -1.00%)	✅ 77.78% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (07316d9)	24077	19476	80.89%
Head commit (e983b98)	24176 (+99)	19552 (+76)	80.87% (-0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#5456)	135	105	77.78%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

[tobiasgies]

NotificationPublisherResourceTest.testNotificationRuleTest failed.

Well that's new. I haven't seen that test fail in my local test runs yet. I'll have a look to see if I can reproduce... any info on if it's just a bit brittle?

EDIT: From what I can tell it seems we just found a particularly busy Actions runner. The test takes between 5 and 6 seconds to run on my local machine (AMD Ryzen 9 9900X, 64 GB RAM). I could increase the timeout for this test to 15 seconds to make it less likely for this to re-occur. Not sure if that's desirable though.

[stohrendorf]

I could increase the timeout for this test to 15 seconds to make it less likely for this to re-occur. Not sure if that's desirable though.

IMHO you can do that as long as it's not excessive. I have done so myself in other PRs to mitigate some flaky tests that were clearly failing because of low resources in the CI environment.

[tobiasgies]

IMHO you can do that as long as it's not excessive. I have done so myself in other PRs to mitigate some flaky tests that were clearly failing because of low resources in the CI environment.

Alright, thank you. In that case: Extended timeout to 20s to hopefully alleviate the flakiness.

[snieguu]

Maybe we should do here more strict validation, accept only valid CVSSv4 vectors

[tobiasgies]

I agree in principle, I just copy/pasted the validation code for the other CVSS vector versions for the moment. However I think this might be duplicate work - the org.metaeffekt.core:ae-security package contains stricter validation logic in CvssVector.parseVector. Any invalid vector will cause the method to return null instead of a CvssVector instance, causing the data to be thrown out.

With that in mind, do you still think additional validation is needed in this place?

[snieguu]

Yes I know that for every other places related to CVSS we have PRINTABLE_CHARS_PLUS.
Regarding to

Any invalid vector will cause the method to return null instead of a CvssVector instance, causing the data to be thrown out.

validation in CvssVector.parseVector is also very simple, regex is:

private static final Pattern CVSS_PATTERN = Pattern.compile("CVSS:\\d+\\.?\\d?");

For instance, I am able to create such internal Vulnerability in DependencyTrack 4.13.6(note that i was able to put invalid cvss 4.0 vector into cvss 2.0)

From my experience strict validation should be present from the begining of the feature because then data that normaly will be rejected(because validation) are living in db and can cause a problems

Second thing is that OWASP product should be secure as much as possible, because this is OWASP mission at the end,
how can we teach people to write application according to ASVS 4.X when we not do the same.

On the other hand previous version of cvss was written in a way that is used in PR, making difference here can cause problems that i am not aware of, so I agree with that maybe it can be addressed later(I can do that)

[nscuro]

It might make sense to look into creating a custom validator, like we have for cron expressions for example.

I do agree that adding that for existing CVSS types might cause issues that would need proper data migration first. But for everything we add going forward, it makes sense to be more defensive as to what we accept.

[stohrendorf]

A migration shouldn't be necessary, the persistence framework should add columns itself.

[stohrendorf]

Regarding the other analyzers you didn't extend, Snyk docs are here. For VulnDB, this seems to be the official reference.