testcontainers / testcontainers/testcontainers-java
[Enhancement]: Add OWASP dependency check plugin to identify vulnerable dependencies
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Java
- Sterne
- 8.7k
- Forks
- 1.9k
- Ø Merge
- 2 T. 17 Std.
- Gemergte PRs (30 T.)
- 9
Beschreibung
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:
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne mit der root build.gradle und der in der Issue beschriebenen dependencyCheck-Konfiguration; prüfe, wie Subprojekte und zusätzliche Gradle-Projekte in den Build eingebunden werden. Führe den bestehenden Build aus, um den aktuellen Abhängigkeitssatz festzuhalten, und überprüfe anschließend, dass die Abhängigkeitsberichte die vorgesehenen Module abdecken und dass die zusätzlichen Projekte wie erwartet behandelt werden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- java
- Bereich
- build-system, security
- Issue-Typ
- Feature
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100