Running dependencyCheck concurrent in multiple CI pipelines throws error

[SvenLie]

Describe the bug
A clear and concise description of what the bug is.

Version of dependency-check used
The problem occurs using version 7.1.2 of the docker container

Log file
https://gist.github.com/SvenLie/94f6e98447bcd2d79c90cd4a9e0553d7

To Reproduce
Have to CI-Pipelines running the command "/usr/share/dependency-check/bin/dependency-check.sh --data ".dependency-check" --out ".dependency-check" --suppression ".dependency-check/suppressions.xml" --scan "./" --project "$CI_PROJECT_TITLE" --format ALL --enableExperimental --disableYarnAudit" at the same time. One pipeline will fail with log above. When running the command only one time it works

[mprins]

Your logfile does not show any problems or failure nor does your description shed any light on your problem, so I'm just guessing that you are running int concurrent modification problems.
The default H2 store is not designed to be used in concurrent scenario's.
The documentation provides various solutions and workarounds.

[jeremylong]

Maybe add --log odc.log to see the log file. As stated above - the provided output does not show any errors. If I had to guess - running ODC multiple times might cause you to hit the rate limit imposed by the NVD. See https://jeremylong.github.io/DependencyCheck/data/index.html

@mprins regarding the concurrency issue with H2 - ODC goes to great lengths so that isn't an issue. Each instance will make a temp copy of the database. During the updates there is a lock file respected by all instances - and they will wait before attempting to update and/or make their temporary copy for the analysis.

[bersti]

We experienced the same issue and managed to get the following stack trace:

Caused by: org.owasp.dependencycheck.exception.ExceptionCollection: One or more exceptions occurred during analysis:
ConcurrentModificationException: null
ConcurrentModificationException: null
ConcurrentModificationException: null
at org.owasp.dependencycheck.Engine.analyzeDependencies (Engine.java:669)
at org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.runCheck (BaseDependencyCheckMojo.java:1821)
at org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.generate (BaseDependencyCheckMojo.java:1070)
at org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.generate (BaseDependencyCheckMojo.java:1023)

Still doesn't exactly reveal the cause of the ConcurrentModificationExceptions. However, I suspect one of the recent changes causing it, i.e. turning the suppression rules collection into a singleton, see this commit. The SuppressionRules singleton is not thread-safe and concurrent access may cause exactly those ConcurrentModificationExceptions.

We had to downgrade to v7.1.1 to avoid running into those problems.

[aikebah]

@bersti The final exceptioncollection stacktrace should mean that earlier on in the log you can find the actual errors getting logged as well. Those would be the pointers to what goes wrong in your case.

[siladu]

Think I'm experiencing the same thing since upgrading from 7.1.0.1 to 7.2.1.

CI runs gradle plugin dependencyCheckAggregate on a multi-module project using an executor configured with the gradle parallel option.

An unexpected error occurred during analysis of '/tmp/dctempc6e92274-57f3-4975-aa5f-0d90c79abf96/check14895804919083143977tmp/336/pom.xml' (CPE Analyzer): null

java.util.ConcurrentModificationException
	at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1043)
	at java.base/java.util.ArrayList$Itr.next(ArrayList.java:997)
	at org.owasp.dependencycheck.analyzer.AbstractSuppressionAnalyzer.analyzeDependency(AbstractSuppressionAnalyzer.java:136)
	at org.owasp.dependencycheck.analyzer.CpeSuppressionAnalyzer.analyzeDependency(CpeSuppressionAnalyzer.java:91)
	at org.owasp.dependencycheck.analyzer.AbstractAnalyzer.analyze(AbstractAnalyzer.java:131)
	at org.owasp.dependencycheck.analyzer.CPEAnalyzer.determineIdentifiers(CPEAnalyzer.java:960)
	at org.owasp.dependencycheck.analyzer.CPEAnalyzer.determineCPE(CPEAnalyzer.java:298)
	at org.owasp.dependencycheck.analyzer.CPEAnalyzer.analyzeDependency(CPEAnalyzer.java:779)
	at org.owasp.dependencycheck.analyzer.AbstractAnalyzer.analyze(AbstractAnalyzer.java:131)
	at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:88)
	at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:37)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

(See https://app.circleci.com/pipelines/github/ConsenSys/web3signer/2315/workflows/6c01b2d5-689a-4d69-898f-ef8972ae681d/jobs/7729/parallel-runs/0/steps/0-105)

---

Also, not sure if related to this issue but seems to correlate with the 7.1.0.1 -> 7.2.1 upgrade, I get flaky dependencyCheckAggregate failures where the logs report vulnerabilities: https://app.circleci.com/pipelines/github/ConsenSys/web3signer/2307/workflows/c3cef431-387f-4e8f-84cc-210741cfa161/jobs/7695

however the generated report does not: https://output.circle-artifacts.com/output/job/223315ad-72bf-4f9a-be4e-0f60cf60d6ca/artifacts/0/test-reports/dependency-check-report.html

and indeed it passes on a rerun.

[jeremylong]

This should be fixed with the next release (patched via #4935).