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>
            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>
            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>

    <suppress>
        <notes>
            Ignore all vulnerabilities reported against DDF artifacts. These are false positives.
            Note: CVEs with a score of exactly 10.0 will need to be suppressed separately.
        </notes>
        <gav regex="true">ddf.*:.*</gav>
        <cvssBelow>10</cvssBelow>
        <cve>CVE-2006-6460</cve>
    </suppress>

    <suppress>
        <notes>
            Ignore all vulnerabilities reported against DDF artifacts. These are false positives.
            Note: CVEs with a score of exactly 10.0 will need to be suppressed separately.
        </notes>
        <gav regex="true">org\.codice\.ddf.*:.*</gav>
        <cvssBelow>10</cvssBelow>
        <cve>CVE-2006-6460</cve>
    </suppress>

    <suppress>
        <notes>
            javax.websocket/javax.websocket-api is not the same dependency as
            java-websocket_project:java-websocket. We use the former, the CVE is for the latter.
        </notes>
        <packageUrl regex="true">^pkg:maven/javax\.websocket/javax\.websocket\-api@.*$</packageUrl>
        <cpe>cpe:/a:java-websocket_project:java-websocket</cpe>
    </suppress>

    <suppress>
        <notes>
            The CVE is for hazelcast, but is being reported against hazelcast-client-protocol,
            which is a different project.
        </notes>
        <packageUrl regex="true">^pkg:maven/com\.hazelcast/hazelcast\-client\-protocol@.*$</packageUrl>
        <cve>CVE-2016-10750</cve>
    </suppress>

    <suppress>
        <notes>
            These CVEs are for Karaf but are being reported against Karaf Decanter
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.karaf\.decanter.*/org\.apache\.karaf\.decanter.*@.*$</packageUrl>
        <cve>CVE-2014-0219</cve>
        <cve>CVE-2016-8750</cve>
        <cve>CVE-2018-11786</cve>
        <cve>CVE-2018-11787</cve>
        <cve>CVE-2018-11788</cve>
        <cve>CVE-2019-0191</cve>
        <cve>CVE-2019-0226</cve>
        <cve>CVE-2020-11980</cve>
    </suppress>

    <suppress>
        <notes>
            Zookeeper is the only thing still using Log4J, and it has suppressions for both the
            following CVEs.

            CVE-2019-17571  https://issues.apache.org/jira/browse/ZOOKEEPER-3677 (Zookeeper not affected)
            CVE-2020-9488   https://issues.apache.org/jira/browse/ZOOKEEPER-3817 (DDF not affected,
                            doesn't configure Zookeeper with an SMTPAppender)

            Once Zookeeper migrates to Log4J2, we can remove this suppression. See
            https://issues.apache.org/jira/browse/ZOOKEEPER-2342
        </notes>
        <packageUrl regex="true">^pkg:maven/log4j/log4j@.*$</packageUrl>
        <cve>CVE-2019-17571</cve>
        <cve>CVE-2020-9488</cve>
    </suppress>

    <suppress>
        <notes>
            httpd vulnerabilities do not apply to CXF
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.cxf/cxf\-rt\-transports\-http\-netty\-server@.*$</packageUrl>
        <cpe>cpe:/a:apache:http_server</cpe>
    </suppress>

    <suppress>
        <notes>
            Karaf vulnerabilities do not apply to CXF (the "org.apache.cxf.karaf" group is used by
            CXF artifacts providing Karaf-specific functionality)
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.cxf\.karaf/.*</packageUrl>
        <cpe>cpe:/a:apache:karaf</cpe>
    </suppress>

    <suppress>
        <notes>
            Karaf vulnerabilities do not apply to Camel (the "org.apache.camel.karaf" group is used
            by Camel artifacts providing Karaf-specific functionality)
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.camel\.karaf/.*</packageUrl>
        <cpe>cpe:/a:apache:karaf</cpe>
    </suppress>

    <suppress>
        <notes>
            Maintainers of the OAuth2 SDK confirmed these are false positives:
            https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/320/owasp-dependency-check-reports-false
        </notes>
        <packageUrl regex="true">^pkg:maven/com\.nimbusds/oauth2\-oidc\-sdk@.*$</packageUrl>
        <cve>CVE-2007-1651</cve>
        <cve>CVE-2007-1652</cve>
    </suppress>

    <suppress>
        <notes>
            These CVEs are from XStream and have been mitigated by using the XStream Security
            Framework wherever DDF creates an XStream object.
        </notes>
        <packageUrl regex="true">^pkg:maven/io\.github\.x\-stream/mxparser@.*$</packageUrl>
        <cve>CVE-2013-7285</cve>
        <cve>CVE-2021-21342</cve>
        <cve>CVE-2021-21344</cve>
        <cve>CVE-2021-21345</cve>
        <cve>CVE-2021-21346</cve>
        <cve>CVE-2021-21347</cve>
        <cve>CVE-2021-21350</cve>
        <cve>CVE-2021-21351</cve>
        <cve>CVE-2016-3674</cve>
        <cve>CVE-2017-7957</cve>
        <cve>CVE-2020-26217</cve>
        <cve>CVE-2020-26258</cve>
        <cve>CVE-2021-21341</cve>
        <cve>CVE-2021-21343</cve>
        <cve>CVE-2021-21348</cve>
        <cve>CVE-2021-21349</cve>
        <cve>CVE-2021-29505</cve>
        <cve>CVE-2021-39139</cve>
        <cve>CVE-2021-39141</cve>
        <cve>CVE-2021-39144</cve>
        <cve>CVE-2021-39145</cve>
        <cve>CVE-2021-39146</cve>
        <cve>CVE-2021-39147</cve>
        <cve>CVE-2021-39148</cve>
        <cve>CVE-2021-39149</cve>
        <cve>CVE-2021-39150</cve>
        <cve>CVE-2021-39151</cve>
        <cve>CVE-2021-39152</cve>
        <cve>CVE-2021-39153</cve>
        <cve>CVE-2021-39154</cve>
        <cve>CVE-2021-43859</cve>
        <cve>CVE-2022-40151</cve>
        <cve>CVE-2022-40152</cve>
        <cve>CVE-2022-41966</cve>
        <cve>CVE-2020-26259</cve>
        <cve>CVE-2021-39140</cve>
    </suppress>

    <suppress>
        <notes>
            This CVE applies to the parent library of several contrib artifacts, and the project
            is using a version that resolves the CVE. These artifacts are false positives
            because they use a similar naming convention, but a different versioning convention.
        </notes>
        <packageUrl regex="true">^pkg:maven/ch\.qos\.logback\.contrib/.*@0.1.5$</packageUrl>
        <cve>CVE-2017-5929</cve>
    </suppress>

    <suppress>
        <notes>
            This CVE is a false positive. The siv-mode artifact is incorrectly included in other
            org.cryptomator artifacts.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.cryptomator/siv\-mode@1\.5\.2</packageUrl>
        <cve>CVE-2022-25366</cve>
        <cve>CVE-2023-37907</cve>
        <cve>CVE-2023-39520</cve>
    </suppress>

    <suppress>
        <notes>
            These CVEs are a false positive. They apply to the greater Spring Framework library.
            This artifact uses a similar naming convention, but different versioning. It is not
            included in the greater library.
        </notes>
        <packageUrl regex="true">pkg:maven/org\.springframework\.ldap/spring\-ldap\-core@3\.2\.11</packageUrl>
        <cve>CVE-2015-3192</cve>
        <cve>CVE-2015-5211</cve>
        <cve>CVE-2016-1000027</cve>
        <cve>CVE-2016-5007</cve>
        <cve>CVE-2018-11039</cve>
        <cve>CVE-2018-11040</cve>
        <cve>CVE-2018-1257</cve>
        <cve>CVE-2020-5421</cve>
        <cve>CVE-2022-22950</cve>
        <cve>CVE-2022-22965</cve>
        <cve>CVE-2022-22968</cve>
        <cve>CVE-2022-22970</cve>
        <cve>CVE-2023-20861</cve>
    </suppress>
    <suppress>
        <notes>
            This CVE is a false positive. It is related to PASV FTP requests. However, DDF does not use
            FTP.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.sling/org\.apache\.sling\.commons\.johnzon@1\.2\.16$</packageUrl>
        <cve>CVE-2021-37533</cve>
    </suppress>
    <suppress>
        <notes>
            These CVEs are false positives. It is related to Apache Sling, which DDF does not use. It is
            being reported because Apache Karaf pulls in an Apache Johnzon (JSON parsing) artifact that
            registers a service provider. Also, the code is related to the karaf configs and only admins
            can access the configs. Others have also reported this as a false positive under very
            similar conditions: https://github.com/anchore/grype/issues/1269
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.sling/org\.apache\.sling\.commons\.johnzon@1\.2\.16$</packageUrl>
        <cve>CVE-2022-45064</cve>
        <cve>CVE-2022-47937</cve>
        <cve>CVE-2023-33008</cve>
    </suppress>
    <suppress>
        <notes>
            These CVEs are a false positive. They apply to the json-smart and accessors-smart libraries.
            However, the CVEs are caused via a transitive dependency in OIDC libraries, which reference an
            outdated version of these smart libraries. We have assured that a newer version of the smart libraries
            are imported to prevent these vulnerabilities.
        </notes>
        <packageUrl regex="true">pkg:maven/net\.minidev/.*@.*$</packageUrl>
        <cve>CVE-2021-27568</cve>
        <cve>CVE-2021-31684</cve>
        <cve>CVE-2023-1370</cve>
        <cve>CVE-2024-57699</cve>
        <cve>CVE-2022-45688</cve>
        <cve>CVE-2023-5072</cve>
    </suppress>
    <suppress>
        <notes>
            These CVEs are a false positive. They apply to transitive dependencies for tika-bundle-standard 2.4.0.
            However, these transitive dependencies are not actually imported into the system. In addition, the maven
            webpage for this version of tika-bundle-standard does not list any CVEs.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.tika/tika\-bundle\-standard@2\.4\.0.*$</packageUrl>
        <cve>CVE-2021-38542</cve>
        <cve>CVE-2021-40110</cve>
        <cve>CVE-2021-40111</cve>
        <cve>CVE-2021-40525</cve>
        <cve>CVE-2022-28220</cve>
        <cve>CVE-2022-45787</cve>
        <cve>CVE-2022-45935</cve>
        <cve>CVE-2023-26269</cve>
        <cve>CVE-2024-21742</cve>
        <cve>CVE-2021-37533</cve>
        <cve>CVE-2024-47554</cve>
    </suppress>
    <suppress>
        <notes>
            These CVEs are a false positive. The CVEs apply to previous versions of mime4j libraries, but
            not the version used in this project.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.james/apache\-mime4j\-(core|dom)@0\.8\.12$</packageUrl>
        <cve>CVE-2021-38542</cve>
        <cve>CVE-2021-40110</cve>
        <cve>CVE-2021-40111</cve>
        <cve>CVE-2021-40525</cve>
        <cve>CVE-2022-28220</cve>
        <cve>CVE-2022-45935</cve>
        <cve>CVE-2023-26269</cve>
    </suppress>
    <suppress>
        <notes>
            This CVE concerns the possibility of users injecting executable data. However,
            only the admin can specify the command to be executed via platform-scheduler.
            Also, the CVE notes that experts do not agree if a user could inject data to
            reach the code location where injection must occur.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.quartz\-scheduler/quartz.*@2\.3\.2$</packageUrl>
        <cpe>cpe:/a:softwareag:quartz</cpe>
        <cve>CVE-2023-39017</cve>
    </suppress>
    <suppress>
        <notes>
            These CVEs are for spring framework, but as a transitive dependency of Apache CXF. The CVEs
            require untrusted user data reaching the spring expression library. However, there is no way
            in DDF for a user to inject user data via CXF.
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.springframework/spring\-(tx|aop|jcl|beans|core|expression|context)@5\.3\.27$</packageUrl>
        <cve>CVE-2016-1000027</cve>
        <cve>CVE-2024-38808</cve>
        <cve>CVE-2024-38820</cve>
    </suppress>
    <suppress>
        <notes>
            The CVE is for Apache soap, but is being reported against cxf-rt-bindings-soap,
            which is a different library. Confirmation https://github.com/dependency-check/DependencyCheck/issues/5543
        </notes>
        <packageUrl regex="true">^pkg:maven/org\.apache\.cxf/cxf\-rt\-bindings\-soap@.*$</packageUrl>
        <cpe>cpe:/a:apache:soap</cpe>
        <cve>CVE-2016-10750</cve>
    </suppress>
</suppressions>