JVM version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.
After integrating the pact-jvm artifacts into a project and running vulnerability scans a concerning number of "vulnerable transitive dependency detected" messages cropped up in automated scans. While I assume (without having verified this!) that a lot are effectively "false-positives" in the sense that the vulnerability is not exploitable (by default) it would nevertheless be good form to upgrade these vulnerable dependencies declared in the pact-jvm artifacts to later versions without known vulnerabilities.
In particular at least the following implementation dependencies have known vulnerabilities and newer versions (I only list updates to patch or minor releases; major upgrades are clearly marked because of expected incompatibilities) that may be used:
com.jayway.restassured:rest-assured:2.9.0 -> major release upgrade onlyio.rest-assured:rest-assured:5.2.0 (4.5.1 or 3.3.0 maybe better compatible but potentially also vulnerable)
While going through the list I noticed that most of these versions are not centrally managed (by default) for all sub-projects in the global gradle.properties which would make management way easier (and still allow overriding in particular cases where it is necessary).
Also I noticed that that consumer/junit/build.gradle has a faulty dependency tree by declaring a dependency twice in different versions:
Updating, testing and validating all of these proposed updates is probably a large and thankless chore but would reduce unnecessary noise when consuming these artifacts and working with them. It may be an idea to try centralising the dependency management and try whether Dependabot can help with PRs and automated builds that show failures early.
After integrating the pact-jvm artifacts into a project and running vulnerability scans a concerning number of "vulnerable transitive dependency detected" messages cropped up in automated scans. While I assume (without having verified this!) that a lot are effectively "false-positives" in the sense that the vulnerability is not exploitable (by default) it would nevertheless be good form to upgrade these vulnerable dependencies declared in the pact-jvm artifacts to later versions without known vulnerabilities.
In particular at least the following implementation dependencies have known vulnerabilities and newer versions (I only list updates to patch or minor releases; major upgrades are clearly marked because of expected incompatibilities) that may be used:
ch.qos.logback:logback-core:1.2.5
->ch.qos.logback:logback-core:1.4.4
ch.qos.logback:logback-classic:1.2.5
->ch.qos.logback:logback-classic:1.4.4
com.fasterxml.jackson.datatype:jackson-datatype-joda:2.10.2
->com.fasterxml.jackson.datatype:jackson-datatype-joda:2.13.4
com.github.rholder:guava-retrying:2.0.0
-> no update available :(commons-beanutils:commons-beanutils:1.9.4
-> no update available :(io.ktor:ktor-server-netty:1.6.2
->io.ktor:ktor-server-netty:1.6.8
io.ktor:ktor-http-jvm:1.6.1
->io.ktor:ktor-http-jvm:1.6.8
io.netty:netty-handler:4.1.66.Final
->io.netty:netty-handler:4.1.84.Final
leiningen-core:leiningen-core:2.9.4
->leiningen-core:leiningen-core:2.9.10
org.apache.maven:maven-core:3.8.1
->org.apache.maven:maven-core:3.8.6
org.apache.tika:tika-core:1.27
->org.apache.tika:tika-core:1.28.5
org.springframework.boot:spring-boot-starter-test:2.5.3
->org.springframework.boot:spring-boot-starter-test:2.5.14
(org.springframework.boot:spring-boot-starter-test:2.7.4
)ws.unfiltered:unfiltered-netty-server_2.12:0.9.1
->ws.unfiltered:unfiltered-netty-server_2.12:0.10.4
xerces:xercesImpl:2.12.1
->xerces:xercesImpl:2.12.2
The following test dependencies are affected:
com.amazonaws:aws-java-sdk-s3:1.12.32
->com.amazonaws:aws-java-sdk-s3:1.12.324
com.fasterxml.jackson.core:jackson-databind:2.12.4
->com.fasterxml.jackson.core:jackson-databind:2.13.4.2
com.fasterxml.jackson.core:jackson-databind:2.11.0.rc1
->com.fasterxml.jackson.core:jackson-databind:2.13.4.2
com.github.rest-driver:rest-client-driver:1.1.45
-> major release upgrade onlycom.github.rest-driver:rest-client-driver:2.0.1
com.github.tomakehurst:wiremock:2.27.2
-> no update available :( - should probably switch tocom.github.tomakehurst:wiremock-jre8:2.34.0
(?)com.github.tomakehurst:wiremock-jre8:2.27.2
->com.github.tomakehurst:wiremock-jre8:2.34.0
com.jayway.restassured:rest-assured:2.9.0
-> major release upgrade onlyio.rest-assured:rest-assured:5.2.0
(4.5.1
or3.3.0
maybe better compatible but potentially also vulnerable)io.dropwizard:dropwizard-testing:1.3.7
->io.dropwizard:dropwizard-testing:1.3.29
io.github.http-builder-ng:http-builder-ng-apache:1.0.4
-> abandoned/archivedorg.apache.commons:commons-collections4:4.1
->org.apache.commons:commons-collections4:4.4
org.springframework.boot:spring-boot-starter-web:2.5.3
->org.springframework.boot:spring-boot-starter-web:2.5.14
(org.springframework.boot:spring-boot-starter-web:2.7.4
)org.yaml:snakeyaml:1.23
->org.yaml:snakeyaml:1.33
While going through the list I noticed that most of these versions are not centrally managed (by default) for all sub-projects in the global gradle.properties which would make management way easier (and still allow overriding in particular cases where it is necessary).
Also I noticed that that consumer/junit/build.gradle has a faulty dependency tree by declaring a dependency twice in different versions:
This should probably be cleaned up as well.
Updating, testing and validating all of these proposed updates is probably a large and thankless chore but would reduce unnecessary noise when consuming these artifacts and working with them. It may be an idea to try centralising the dependency management and try whether Dependabot can help with PRs and automated builds that show failures early.