Suppression of specific CVE based on CVSS value

[rseeton]

Our implementation of DependencyCheck uses suppression files to 'quiet' issues which are considered not-applicable or low risk, based - in part - on the CVE's CVSS. However, the CVSS ratings are subject to change based on new information or assessment. Our suppression files currently expire, using the 'until' option, resulting in re-analysis on a regular basis.

In addition to time-bounded suppression, we would like to see CVSS-bounded suppression.

While the CVE's CVSS is below client specified threshold, the issues is suppressed. If CVSS changes to exceed the threshold, the CVSS-bounded suppression fails and the issue is restored to the report.

If both time-bound and CVSS-bound criteria are present, the system would use an 'OR' condition - if either is violated the suppression is no longer valid.

e.g. CVE-2022-34305 is currently under review (https://nvd.nist.gov/vuln/detail/CVE-2022-34305). We don't currently consider this an issue requiring action - but that may change depending on the outcome of the reanalysis. Our current plans are to review it in November, but, if the risk escalates our plans could change.

The cvss_limit in the example would be our proxy for a risk escalation. With this setup the dependency_check logic would be suppress until 2022-11-01 AND while cvss_limit < 7.0.

<suppress until="2022-11-01" cvss_limit="7.0">
      <notes>
      <![CDATA[
      IMCR-2162 - Temporarily suppress CVE-2022-34305 as we expect an update to Tomcat 10.x 
      file name: tangerine-release-5.2.0.5-5.tar.gz: tangerine-release-5.2.0.5-5.tar: catalina-ant.jar
      ]]>
      </notes>
      <cve>CVE-2022-34305</cve>
</suppress>

[aikebah]

A remark on the specific CVE you mention: I would assume your installed Tomcat instances would not include the examples webapplication? So that issue could be fully suppressed regardless of CVE rating (after ensuring you did not copy/paste the example code to your own authentication form).

the Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability

[rseeton]

@aikebah - You are correct - for this specific CVE, we have implemented the Tomcat Security guidelines and removed the various default application packages - which should allow the issue to be fully suppressed.

However, our Security Engineering team is uncomfortable with "blanket" suppressions. A 'change in severity' trigger would allow us to use "severity changes" as a proxy trigger for re-visiting issues of concern.

[jeremylong]

See the sample suppression file: https://jeremylong.github.io/DependencyCheck/general/suppression.html (line 38). Is this what you are looking for? It might not work as expected as the suppression rules are currently or conditions...

[aikebah]

@jeremylong Not quite what @rseeton appears to be looking for. The case to be solved is to get a new alert (to trigger re-evaluation by the security team) when a CVE gets re-analyzed to a higher CVSS rating than before, which might influence their internal assessment. At the initial CVSS rating the CVE has been judged 'acceptable risk'.

Let's assume (for the sake of argument, and with an extreme difference in CVSS vector) an issue that according to the initial vulnerability analysis was classified as a locally exploitable issue requiring authentication. After initial publication of the CVE someone finds out that the bug that was fixed could actually have been remotely exploited without authentication, so the CVE gets re-evaluated at a new CVSS score reflecting a remote, unauthenticed attack.

Based on the initial CVSS (local, authenticated) it may have been considered an acceptable risk until next release, but after the discovery that it actually could be exploited remotely and did not require authentication suddenly the team would no longer consider it suppressable until next release.

So the request is for an ANDed condition. Suppress the vulnerability if it is 'this vulnerability' and does not exceed 'CVSS of the vulnerability at the time of our assesment'

cvssBelow would suppress any issue not exceeding the cvss threshold.

[rseeton]

Hello all, I've had a chance to test @jeremylong 's suggestion (apologies for the delay) and @aikebah is unfortunately correct - cvssBelow suppresses all issues below a threshold, which is greedier than what we were hoping for.

This is not a critical issue - the tool works well for us, but it would be a nice enhancement. Thanks.