Need a cvssV3Below or a cvssBelow(version=xx) suppression rule

[arnaudq]

trafficstars

The cvssBelow suppression rule does allow filtering based on the CVSS Score of a vulnerability.

From looking at the documentation, it is not clear which version of cvss is taken into account but I'm assuming that the v2 score is used.

Some vulnerability may have a very different score between v2 and v3 (e.g. CVE-2020-5529 with a CVSSv2 base score of 6.8 and a CVSSv3 score of 8.1).

Being able to specify the targeted version in the suppression rule would allow a better/more up to date filtering.

This could be exposed either as a different suppression rule (cvssV3Below) or by adding an optional version attribute to the existing cvssBelow element.

[ognjen-it]

@jeremylong It would be great if you can create/edit the schematic for suppression. For example, as @arnaudq said, to have cvssV3Below and cvssV2Below.

For example, we have a problem when we build an application, it downloads dependencies which have both scores (cvss.v2 and cvss.v3). In this situation, in suppression file, < cvssBelow > will be treated as cvssV2 score. However, if the application downloads dependency which has the only cvss.v3, < cvssBelow > will be treated as cvss.v3 score.

If a dependency has only score type by cvssv3, and for example, it is Critical 9,4 score and for example if we test suppression cvssBelow 9.5, it will be suppressed even though cvssType used by suppression system is v2. Why is this problem, because the report will not have consistency, since if we get some dependency which has score 9.4 cvssv2 High we would filter by LOW MEDIUM HIGH, because we know cvss system used is cvssv2, and like said some would have cvssv3, with a score the same as v2 but for v3 it is CRITICAL. That critical could be overpassed by us during report assessment, and suppression of false positives, wouldn't be objective.

The real problem we had is next.

1. Vulnerability was scored 8.8 by cvssV3
2. We configured suppression cvssBelow 6.9
3. When the test was run this Vulnerability was suppressed.
4. This vulnerability was actually scored 6.5 by cvssV2

[jeremylong]

What about the vulns that don't have a CVSS score? There are sources of vulnerability information that do not have any CVSS details. We currently attempt to convert the word 'high', 'medium', etc. into an equivalent score and check the cvss fail score against any of the three scores that may exist. So if we look objectively, weighing the complexity of configuration, ease of use, etc. seemed like a workable approach.

As always - if you think you have a better approach we accept most PRs.

[ognjen-it]

@jeremylong we never saw that vulnerability which doesn't have cvss score. But I think cvssV3Below should resolve the problem.

btw, I edited the post above because I thought that you will not see the post soon :)

[thomasredlin]

Any update on this?

With

  <suppress>
    <notes><![CDATA[
        This suppresses all CVE entries that have a score below CVSS 7.
        ]]></notes>
    <cvssBelow>7</cvssBelow>
  </suppress>

I also just noticed that some vulnerabilities in the report get suppressed because CVSSv2 is below 7 although CVSSv3 is above 7 and may even be Critical.

I would consider this a bug.

For example this is the case with Apache XmlGraphics Commons xmlgraphics-commons-2.3.jar and https://nvd.nist.gov/vuln/detail/CVE-2020-11988.

We would appreciate a cvssV2Below and cvssV3Below suppression or a rule that would take both into consideration and suppresses the vulnerability only if both are below a threshold.

Thanks!