testcontainers / testcontainers/testcontainers-java
[Enhancement]: Add OWASP dependency check plugin to identify vulnerable dependencies
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 8.7k
- Forks
- 1.9k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 9
Description
Module
Core
Proposal
(Note: I mentioned 'core' above but this will affect core and all modules)
Motivation
Companies are increasingly concerned about tracking known vulnerabilities in their software supply chain.
This is a deep issue but a good first step is incorporating the OWASP dependency analyzer in our maven or gradle build configuration files. This plugin checks all dependencies against a database of known vulnerabilities and creates a report that lists:
- the name of the dependency
- a description of the vulnerability(ies), including their severity
- a lost of maven modules/gradle projects that include this dependency
- (iirc) the next oldest release that has no known vulnerabilities
In addition you can configure this plugin to cause the build to fail if the vulnerability score is too high. This will force the developers to update their dependencies and hopefully reduce the likeliness of a nightmare situation where an "absolutely must fix" vulnerability, e.g., the recent log4j vulnerability, will trigger the forced upgrade of multiple dependencies at the same time with the concurrent increased risk of changed behavior.
There is a safety valve that allows vulnerable dependencies to continue to be used within contributing to the vulnerability score. This is warranted if you've determined that your application never accesses the vulnerable code.
Important - this scanner does not perform any static analysis (see: findbugs, veracode). The only thing it does is check the project's dependencies against a database of vulnerabilities.
build.gradle Changes
Very few changes to the root build.gradle file are required to add the OWASP plugin.
plugins {
id 'org.owasp.dependencycheck' version "7.4.4"
}
subprojects {
// Ensure that dependency checks are always performed
check.depends(dependencyCheckAggregate)
// see https://jeremylong.github.io/DependencyCheck/dependency-check-gradle/configuration.html
dependencyCheck {
format='ALL'
}
Note: the most recent version of the plugin is 8.4.4 but it's not compatible with the current version of the JVM.
This produces a summary of the vulnerable dependencies on the console during builds, and a more detailed report
(in multple formats) in $buildDir/reports/dependency-check-report.*
Sample Output (Console)
This is the console output on my 'testcontainers-extra' project - it contain several additional JdbcDatabaseContainers and new Hamcrest matchers.
Generating report for project testcontainers-extras
Found 18 vulnerabilities in project testcontainers-extras
One or more dependencies were identified with known vulnerabilities in testcontainers-extras:
grpc-context-1.27.2.jar (pkg:maven/io.grpc/grpc-context@1.27.2, cpe:2.3:a:grpc:grpc:1.27.2:*:*:*:*:*:*:*) : CVE-2023-33953, CVE-2023-32732
guava-31.0.1-jre.jar (pkg:maven/com.google.guava/guava@31.0.1-jre, cpe:2.3:a:google:guava:31.0.1:*:*:*:*:*:*:*) : CVE-2023-2976, CVE-2020-8908
jib-build-plan-0.4.0.jar (pkg:maven/com.google.cloud.tools/jib-build-plan@0.4.0, cpe:2.3:a:jib_project:jib:0.4.0:*:*:*:*:*:*:*) : CVE-2022-25914
org.eclipse.core.commands-3.9.800.jar (pkg:maven/org.eclipse.platform/org.eclipse.core.commands@3.9.800, cpe:2.3:a:eclipse:equinox:3.9.800:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.core.contenttype-3.7.900.jar (pkg:maven/org.eclipse.platform/org.eclipse.core.contenttype@3.7.900, cpe:2.3:a:eclipse:equinox:3.7.900:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.core.jobs-3.10.1100.jar (pkg:maven/org.eclipse.platform/org.eclipse.core.jobs@3.10.1100, cpe:2.3:a:jobs-plugin_project:jobs-plugin:3.10.1100:*:*:*:*:*:*:*) : CVE-2014-125035
org.eclipse.core.runtime-3.20.100.jar (pkg:maven/org.eclipse.platform/org.eclipse.core.runtime@3.20.100, cpe:2.3:a:eclipse:equinox:3.20.100:*:*:*:*:*:*:*, cpe:2.3:a:jobs-plugin_project:jobs-plugin:3.20.100:*:*:*:*:*:*:*) : CVE-2021-41033, CVE-2014-125035
org.eclipse.equinox.app-1.5.100.jar (pkg:maven/org.eclipse.platform/org.eclipse.equinox.app@1.5.100, cpe:2.3:a:eclipse:equinox:1.5.100:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.equinox.common-3.14.100.jar (pkg:maven/org.eclipse.platform/org.eclipse.equinox.common@3.14.100, cpe:2.3:a:eclipse:equinox:3.14.100:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.equinox.preferences-3.8.200.jar (pkg:maven/org.eclipse.platform/org.eclipse.equinox.preferences@3.8.200, cpe:2.3:a:eclipse:equinox:3.8.200:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.equinox.registry-3.10.100.jar (pkg:maven/org.eclipse.platform/org.eclipse.equinox.registry@3.10.100, cpe:2.3:a:eclipse:equinox:3.10.100:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.jface-3.22.100.jar (pkg:maven/org.eclipse.platform/org.eclipse.jface@3.22.100, cpe:2.3:a:eclipse:equinox:3.22.100:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.osgi-3.16.200.jar (pkg:maven/org.eclipse.platform/org.eclipse.osgi@3.16.200, cpe:2.3:a:eclipse:equinox:3.16.200:*:*:*:*:*:*:*) : CVE-2021-41033
org.eclipse.text-3.11.0.jar (pkg:maven/org.eclipse.platform/org.eclipse.text@3.11.0, cpe:2.3:a:eclipse:equinox:3.11.0:*:*:*:*:*:*:*) : CVE-2021-41033
spotless-eclipse-base-3.4.2.jar (pkg:maven/com.diffplug.spotless/spotless-eclipse-base@3.4.2, cpe:2.3:a:diffplug:gradle:3.4.2:*:*:*:*:*:*:*) : CVE-2019-9843
Many of these are build dependencies and are not used in the final artifacts. Our community has not been concerned
about these vulnerabilities in the past - but one of the key concepts in the Secure Software Supply Chain model is that
vulnerabilities in the build dependencies are just as important as vulnerabilities in the final artifact.
This is a reasonable concern - a sophisticated attacker can almost always affect much more code with a compromised
build dependency that injects malware into everything it touches with a compromised deployed dependency.
Consider the damage that would be possible if maven-jar-plugin injected code that recognized REST
clients and attempted to exfiltrate the connection URL and credentials to a hostile site. This could be caught by
static analysis of the final artifacts - but few sites do this and the injected code may be sufficiently obfuscated to
avoid early detection.
One Gradle Complication
Maven: clean reports
Gradle: lots of extra projects. It's not hard to mentally strip off the :checkstyle and spotless-NNNNNN but it would be nice if it could be avoided. This might be a simple fix in either the build.gradle file or the dependencyCheck configuration. This is especially true when the same dependency is listed multiple times.
It's easiest to attach an example:
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the root build.gradle and the dependencyCheck configuration described in the issue; review how subprojects and extra Gradle projects are included in the build. Run the existing build to establish the current dependency set, then verify that dependency reports cover the intended modules and that the extra projects are handled as expected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100