filePath does not work for findings in WAR files during release builds

[TorstenKruse]

Our project finally builds an EAR which contains multiple JAR and a WAR. We are using Java 8, maven 3.8 and dependency-check 6.5.3. Besides lot of other dependencies the project contains org.exolab.castor:castor-xml:0.9.6b (don't blame me for the old version, the whole project is quite old ;)). I use castor as an example for the bug, there are some more finding like this.

We solved the CVE-2014-3004 for Castor via config.properties and added a suppression:

<suppress>
    <notes><![CDATA[CVE-2014-3004 fixed in castor.properties]]></notes>
    <gav>org.exolab.castor:castor-xml:0.9.6b</gav>
    <cve>CVE-2014-3004</cve>
</suppress>

This is working fine since years.

Now, I don't know what changed (perhaps dependency-check update, perhaps first time we have a critical JAR in the project?) normal builds are still ok, but release builds fail with a finding in:

File Path: /home/jenkins/.m2/repository/de/abc/def/webapplication/1.3.0.25/webapplication-1.3.0.25.war/WEB-INF/lib/castor-xml-0.9.6b.jar
MD5: 15de72b04a2973fb5d12fd844042e6f1
SHA1: e35b79c311a030c77f0a2dca518226249e2632c4
SHA256:8b99aa1c927e3ed4487ff1028c8f146ff932ecbd9dc746a270a9a26a4df559f1
Referenced In Project/Scope:MyApplication :: Webapplication Container:compile

Evidence is empty.

Identifiers: cpe:2.3:a:castor_project:castor:0.9.6b:::::::* (Confidence:Low)

This webapplication-1.3.0.25.war is the WAR which is contained in the EAR and it is right, that the WAR contains the castor.jar.

I also understood, that the suppression above does not match, because dependency-check did not find the GAV, but just a file.

I don't understand, why dependency-check scans the files from maven m2-repo folder. If someone can tell me, how to avoid this, it would be a valid solution.

As I did not find any way to avoid this scan, I thought it would help to add a suppression via filePath. So I created the following:

<suppress>
    <notes><![CDATA[CVE-2014-3004 fixed in castor.properties - FP for finding in m2-repo WAR file]]></notes>
    <filePath regex="true">.*</filePath>
    <cve>CVE-2014-3004</cve>
</suppress>

First there was more context in the regex, I reduced this during testing. But also with the above ".*" the castor finding in the WAR is reported and fails the build.

Is this a bug in dependency-check or should I fix something?

Log file [2022-06-29T11:28:13.395Z] + mvn -Dstyle.color=always dependency-check:aggregate [2022-06-29T11:28:13.396Z] ----- withMaven Wrapper script ----- [2022-06-29T11:28:13.396Z] Picked up JAVA_TOOL_OPTIONS: -Dmaven.ext.class.path="/build/workspace/ntingApplication_master-depcheck@tmp/withMavendb455bbd/pipeline-maven-spy.jar" -Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/build/workspace/ntingApplication_master-depcheck@tmp/withMavendb455bbd" [2022-06-29T11:28:13.396Z] Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0 [2022-06-29T11:28:13.396Z] Maven home: /usr/share/java/maven-3 [2022-06-29T11:28:13.396Z] Java version: 1.8.0_322, vendor: IcedTea, runtime: /usr/lib/jvm/java-1.8-openjdk/jre [2022-06-29T11:28:13.396Z] Default locale: en_US, platform encoding: UTF-8 [2022-06-29T11:28:13.396Z] OS name: "linux", version: "4.18.0-394.el8.x86_64", arch: "amd64", family: "unix" [2022-06-29T11:28:14.948Z] [13:28:14] dependency-check-maven:6.5.3:aggregate [2022-06-29T11:28:19.544Z] [13:28:18] Checking for updates [2022-06-29T11:28:19.544Z] [13:28:18] Skipping NVD check since last check was within 168 hours. [2022-06-29T11:28:19.544Z] [13:28:19] Check for updates complete (287 ms) [2022-06-29T11:28:19.544Z] [2022-06-29T11:28:22.076Z] [13:28:21] Finished Archive Analyzer (2 seconds) [2022-06-29T11:28:22.077Z] [13:28:21] Finished File Name Analyzer (0 seconds) [2022-06-29T11:28:19.544Z] [13:28:19] Analysis Started [2022-06-29T11:28:22.643Z] [13:28:22] Finished Jar Analyzer (0 seconds) [2022-06-29T11:28:22.643Z] [13:28:22] Finished Dependency Merging Analyzer (0 seconds) [2022-06-29T11:28:22.643Z] [13:28:22] Finished Version Filter Analyzer (0 seconds) [2022-06-29T11:28:22.643Z] [13:28:22] Finished Hint Analyzer (0 seconds) [2022-06-29T11:28:23.578Z] [13:28:23] Created CPE Index (1 seconds) [2022-06-29T11:28:25.483Z] [13:28:25] Finished CPE Analyzer (2 seconds) [2022-06-29T11:28:25.483Z] [13:28:25] Finished False Positive Analyzer (0 seconds) [2022-06-29T11:28:25.483Z] [13:28:25] Finished NVD CVE Analyzer (0 seconds) [2022-06-29T11:28:25.743Z] [13:28:25] Finished RetireJS Analyzer (0 seconds) [2022-06-29T11:28:32.311Z] [13:28:31] Finished Sonatype OSS Index Analyzer (5 seconds) [2022-06-29T11:28:32.311Z] [13:28:31] Finished Vulnerability Suppression Analyzer (0 seconds) [2022-06-29T11:28:32.311Z] [13:28:31] Finished Dependency Bundling Analyzer (0 seconds) [2022-06-29T11:28:32.311Z] [13:28:31] Analysis Complete (12 seconds) [2022-06-29T11:28:32.311Z] [13:28:31] Writing report to: /build/workspace/ntingApplication_master-depcheck/target/dependency-check-report.xml [2022-06-29T11:28:32.311Z] [13:28:31] Writing report to: /build/workspace/ntingApplication_master-depcheck/target/dependency-check-report.html [2022-06-29T11:28:32.311Z] [13:28:31] Writing report to: /build/workspace/ntingApplication_master-depcheck/target/dependency-check-report.json [2022-06-29T11:28:32.311Z] [13:28:31] Writing report to: /build/workspace/ntingApplication_master-depcheck/target/dependency-check-report.csv [2022-06-29T11:28:32.311Z] [13:28:31] Writing report to: /build/workspace/ntingApplication_master-depcheck/target/dependency-check-report.sarif [2022-06-29T11:28:32.311Z] [13:28:31] Writing report to: /build/workspace/ntingApplication_master-depcheck/target/dependency-check-junit.xml [2022-06-29T11:28:32.311Z] [2022-06-29T11:28:32.312Z] One or more dependencies were identified with known vulnerabilities in PrintingApplication: [2022-06-29T11:28:32.312Z] [2022-06-29T11:28:32.312Z] webapplication-1.3.0.25.war: bcprov-jdk15on-1.64.jar (cpe:2.3:a:bouncycastle:bouncy-castle-crypto-package:1.64:::::::, cpe:2.3:a:bouncycastle:bouncy_castle_crypto_package:1.64:::::::, cpe:2.3:a:bouncycastle:legion-of-the-bouncy-castle:1.64:::::::, cpe:2.3:a:bouncycastle:legion-of-the-bouncy-castle-java-crytography-api:1.64:::::::, cpe:2.3:a:bouncycastle:the_bouncy_castle_crypto_package_for_java:1.64:::::::) : CVE-2020-15522 [2022-06-29T11:28:32.312Z] webapplication-1.3.0.25.war: castor-xml-0.9.6b.jar (cpe:2.3:a:castor_project:castor:0.9.6b:::::::) : CVE-2014-3004 [2022-06-29T11:28:32.312Z] webapplication-1.3.0.25.war: reactor-netty-core-1.0.19.jar (cpe:2.3:a:netty:netty:1.0.19:::::::) : CVE-2014-3488, CVE-2015-2156, CVE-2019-16869, CVE-2019-20444, CVE-2019-20445, CVE-2021-21290, CVE-2021-21295, CVE-2021-21409, CVE-2021-37136, CVE-2021-37137, CVE-2021-43797, CVE-2022-24823 [2022-06-29T11:28:32.312Z] webapplication-1.3.0.25.war: spring-core-5.3.20.jar (cpe:2.3:a:pivotal_software:spring_framework:5.3.20:::::::, cpe:2.3:a:springsource:spring_framework:5.3.20:::::::, cpe:2.3:a:vmware:spring_framework:5.3.20:::::::) : CVE-2016-1000027

[aikebah]

First of all I would suggest bumping DC to 7.1.1 (though I doubt whether it will solve your current issue it would at least save you having to do FP suppressions related to FP reports that have been resolved in the releases since 6.5.3)

Following that, check the report output to make sure that it's not because of the updated OSSINDEX. OSSINDEX findings can be recognized by a OSSINDEX indicator behind the CVE and they need to be suppressed by <vulnerabilityName>. OSSINDEX recently (end of May) opened up more of their internal vulnerability intelligence for public use, so as you indicate that it used to work before and recently stopped working it could be related to that (the CVE only recently having been added to the public vulnerabilitydata of OSSINDEX).

[TorstenKruse]

Finally I managed to get our CI updated to DC 7.1. But this did not change the results.

I see no hint about OSSINDEX. I add the complete finding data to my initial post.

Any more ideas for a) what triggers DC to find this issue or b) how to suppress this issue?

Thanks for help.

[aikebah]

for b) the answer is in your report /build/workspace/ntingApplication_master-depcheck/target/dependency-check-report.html if you retrieve that and open it in your browser there should will be a 'suppress' link next to the CVE that should properly suppress it.

for a) the answer is that ODC only inspects dependencies of your project (including transitive dependencies), not project code or configuration for code/configuration-level mitigation of an issue. And as the CVE appears to be only solved 'by default' in Castor v1.3.3. So if you apply the configuration change yourself instead of an upgrade to version 1.3.3 you have to signal that to ODC by suppressing the CVE. As to the why it takes it from you m2 repo: that would logically be because the war is not the product of one of your reactor projects (not a submodule of the project that you run the aggregate goal on), so it operates on the war-file that maven resolved as a dependency for your ear-project.

[TorstenKruse]

A suppression via the link will just be a suppression by SHA1. We try to avoid this, because there is no regexp posibility and thus the suppression will fail for any further version of the dependency. But you a right, it would be a valid solution for now. Perhaps the only available.

For a) my question was not precise enough. How to suppress by GAV is well known. I mentioned this in my first post. The second part of your answer hits the core. The war IS the product of a maven submodule. Because of this it used to work for years with the GAV suppression for the dependency. Now DC does not use the maven dependency but the file from the m2 repo folder. Any detailed idea, why this started to happen now?

[aikebah]

That sounds like a bug to me, I'll try and see if I can reproduce it. For in-reactor dependencies it should use the information available in the reactor.

[aikebah]

What is the overall structure of your multimodule project? ear-file module side by side with the war-file module and maybe some supporting library modules under a multimodule umbrella project as in:

umbrella
+- pom.xml
+- ear
    +- pom.xml
    ...
+- war
    +- pom.xml
    ...
+- lib1
    +- pom.xml
    ...
...

[TorstenKruse]

Yes. But EAR module in different subfolder (if this matters)

project pom (your umbrella) contains:

   <modules>
    <module>modules/sftp</module>
    <module>modules/common</module>
    <module>modules/control</module>
    <module>modules/encryption</module>
    <module>modules/mail</module>
    <module>modules/persistence</module>
    <module>modules/pdf</module>
    <module>modules/provider</module>
    <module>modules/invoice</module>
    <module>modules/servicepartner</module>
    <module>modules/mailopt</module>
    <module>modules/webapplication</module>
    <module>webapplication-container</module>
</modules>

The webapplication-container produces the EAR. It has in its own pom.xml a single dependency additional to the umbrella:

	<dependency>
		<groupId>${project.groupId}</groupId>
		<artifactId>webapplication</artifactId>
		<version>${project.version}</version>
		<type>war</type>
	</dependency>

The webapplication produces the WAR.

[aikebah]

Curious if in your report you see the same as I see in my quick-n-dirty reproducer attempt: a double listing of the dependencies of your war artifact - both as a direct artifact and prefixed with your war-file and a colon.

I could not try with the castor-xml library as a dependency as that doesn't appear to be available on a well-known maven repository as per mvnrepostory.com there appear to be published only versions of castor-xml under the org.codehaus.castor groupId, starting off at the 1.3.x versions.

[aikebah]

that duplicate library with the war-file-colon-prefix in the Dependency column would then likely be the one not sensitive to your suppression-file, while the first (the plain library name as a dependency) has it's vulnerability suppressed with your original suppression file.

In my experiment this only appears to happen for release-versioned (non-SNAPSHOT) war-file. Once I change the version to snapshot it takes only the plain library as a dependency.

[aikebah]

Appears to work without issues as long as the release-version of the war is not available in the maven local repository (e.g. if you run the dependency-check:aggregate in your build pipeline before the maven install phase is reached; once installed in the local repository (or available in a central maven repository and therefore resolved to the local repository) the war dependencies of release-wars appear to be duplicated.

[TorstenKruse]

Wow. You are absolutely right! All the dependencies included in the WAR are double listed. And (see issue title) the problem only happens during release builds and not normal snapshot builds. Great to know, that our behaviour is reproducible.

We even tried with mvn package instead of mvn install to avoid adding the version to the m2 repo. This works, but this is no valid solution because we need the artifacts in nexus and e.g. our license check will break, if the dependencies are not in the local m2 repo.

So it would be great to get a solution for release builds. Is there any chance for a fix in DC?

Or is it perhaps possible to bind DC to a phase before install instead of its default phase verify?

[aikebah]

Trialling with a few versions learns that at least back to 6.0.0 the duplicate dependencies exist, but up to 6.1.6 the duplicates (at least if resolvable) get bundled up with the war-colon-prefixed library becoming a related dependency of the plain dependency (in my demo case:Dependencies Scanned: 7 (4 unique)) At 6.2.0 they start appearing as separate dependencies (in my demo case: Dependencies Scanned: 7 (7 unique))

Did your problems start after an update of the dependency-check version from 6.1.6 or earlier to 6.5.3?

[TorstenKruse]

The first failed release build I can find is with version 6.5.3. Former release builds were ok. We used 6.0.2 and 6.2.2 before. So also 6.2.2 seemed to be ok for us. But not 100% sure.

[aikebah]

Or is it perhaps possible to bind DC to a phase before install instead of its default phase verify?

verify phase is before install in the default maven lifecycle

note that mvn install will not place your artifacts in Nexus, only mvn deploy will do that. mvn install only places them in the localrepo (the repository cache of the build server).

mvn package dependency-check:aggregate install might work for you as a temporary work-around: instruct maven to run the default lifecycle up to package, then run dependency-check aggregate goal, then run/continue default lifecycle up to install.

And would I be correct to assume that the castor-xml as used in the war is manually published at the given gav-coordinates on your nexus instance? Or is there some hidden public maven repository that has it available but isn't indexed by mvnrepository.com?

[TorstenKruse]

You are right, our default maven call is "clean deploy dependency-check:aggregate". Perhaps I can tweak this project specfic.

As the JAR is found in local m2 folder, install will "hurt" as much as deploy I think.

And you are correct again, the castor-xml is published in a private nexus repo from our customer.

[aikebah]

@jeremylong Do you remember what the semantics is for the checks in

https://github.com/jeremylong/DependencyCheck/blob/794723481b70c59384f8b330238aceedbb7ac1f8/core/src/main/java/org/owasp/dependencycheck/Engine.java#L547-L549

Because the addition of matching dctemp in the actualFilePath in 794723481b70c59384f8b330238aceedbb7ac1f8 is what triggers this issue, duplicating every regular dependency with a similar archive-relative-path dependency as the direct artifact and the one packaged in the war-file are no longer merged together.