dependency-check-maven-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">

    <!--
       SUPPRESSION GUIDANCE:
       ====================

       1. This is a global suppression file, meaning it is used when scanning all modules in DDF.
       We decided to use a single suppression file since managing files for each module was
       impractical. However, this approach has a notable downside: there is no way to suppress
       vulnerabilities for a single module.

       This is problematic because we would like to ignore vulnerabilities for certain modules -
       docs & itest modules in particular. The dependency-check plugin skips test-scoped
       dependencies, but docs and itests have compile-time dependencies and so they get reported
       by the plugin, even though they don't matter at runtime (all we care about).

       What this means:
       When you go to suppress a vulnerability because it only affects the itests or the docs,
       be very sure that it isn't used at runtime.

       Real-world example:
       JRuby 9.2.6.0 (used by docs only) depends on Bouncy Castle (BC) 1.59, which has known
       vulnerabilities. But BC is used at runtime by other dependencies, so this vulnerability
       can't be suppressed.

       NOTE: If the dependency-check plugin aggregate goal supported skipping children or
       overriding the suppression file, we could work around this. It currently doesn't. See
       https://github.com/jeremylong/DependencyCheck/issues/2152

       2. Due to how dependency-check identifies libraries false positives may occur
       (i.e. a CPE was identified that is incorrect). Suppressing these false positives is fairly
       easy using the HTML report. In the report next to each CPE identified (and on CVE entries)
       there is a suppress button. Clicking the suppression button will create a dialogue box which
       you can simple hit Control-C to copy the XML that you would place into a suppression XML
       file.

       3. In general, prefer fixing a vulnerability over suppressing it, even if DDF isn't
       affected. Pulling on dependencies with no vulnerabilities is better than relying on
       assumptions that DDF isn't affected (which may be subject to change - unfortunately this
       file isn't checked for accuracy often).

       If you do choose to suppress, consider adding guidance on how to address the vulnerability
       in the future if others choose to do so.

       4. If the dependency-check plugin reports a particular dependency version is used, it's
       often right, even if it isn't an installed bundle at runtime. The OWASP report includes a
       section "Referenced In Projects/Scopes" for each vulnerable dependency. Before calling
       something a false positive, run `mvn dependency:tree` on those affected projects and inspect
       the output.

      -->

    <suppress>
        <notes>
            org.springframework.osgi:spring-osgi-core:1.2.1 pulls in Spring 2.5.6.SEC01
            dependencies, which have a bunch of CVEs. It's only used in itests, though, so
            suppressing for now.

            TODO: Look into migrating to org.apache.servicemix.bundles.spring-core, as Spring
            stopped supporting releases as OSGi bundles a long time ago.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.springframework/org\.springframework\..*@2.5.6.SEC01$</packageUrl>
        <cve>CVE-2011-2730</cve>
        <cve>CVE-2013-4152</cve>
        <cve>CVE-2013-7315</cve>
        <cve>CVE-2014-0054</cve>
        <cve>CVE-2016-9878</cve>
        <cve>CVE-2018-1270</cve>
        <cve>CVE-2018-1271</cve>
        <cve>CVE-2018-1272</cve>
    </suppress>

    <suppress>
        <notes>
            A CVE against slf4j for the class "EventData", which is not used in DDF or pax-logging.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.slf4j/slf4j\-ext@.*$</packageUrl>
        <cve>CVE-2018-8088</cve>
    </suppress>

    <suppress>
        <notes>
            These CVEs come from the Codice country code converter library, though it's a little
            unclear why.

            CVE-2015-6420 affects Apache Synapse, which it doesn't use.
            CVE-2017-15708 affects a number of Cisco products, which it doesn't use.
            Moreover, these vulnerabilities are only exploitable when using a version of Apache
            Commons Collections before 3.2.2, and neither it nor DDF do.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.codice\.countrycode/converter@.*$</packageUrl>
        <cve>CVE-2015-6420</cve>
        <cve>CVE-2017-15708</cve>
    </suppress>

    <suppress>
        <notes>
            Ignore vulnerabilities in AsciiDoc and JRuby. They are used only when building the
            documentation, not at runtime.
        </notes>
        <cpe>cpe:/a:asciidoctor:asciidoctor</cpe>
        <cpe>cpe:/a:jruby:jruby</cpe>
    </suppress>

    <suppress>
        <notes>
            This is a SUSE-specific security issue related to file permissions in the tomcat
            packaging. The vulnerable dependency is embedded the pax-web-jsp bundle, so file
            permissions are not an issue.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.tomcat\.embed/tomcat\-embed\-jasper@.*$</packageUrl>
        <cve>CVE-2020-8022</cve>
    </suppress>

    <suppress>
        <notes>
            file name: groovy-2.4.4.jar
            file name: groovy-xml-2.4.4.jar
            file name: groovy-json-2.4.4.jar

            DDF uses an old version of REST Assured which pulls in these vulnerable Groovy
            dependencies. Suppressing since REST Assured and Groovy are only used for testing.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.codehaus\.groovy/groovy.*@2\.4\.4$</packageUrl>
        <cve>CVE-2016-6814</cve>
    </suppress>

</suppressions>