fix: upgrade spock-core and mockito-core to drop vulnerable assertj-core

[gergo-papp]

Why

Application CI has been red on master for months. Clean build and Functional test pass; the failing step is Snyk Test, which exits 1 on a single pre-existing issue:

XML External Entity (XXE) Injection [High Severity] — SNYK-JAVA-ORGASSERTJ-15102413
in org.assertj:assertj-core@3.16.1, introduced by
org.spockframework:spock-core@2.0-groovy-2.5 > org.junit.platform:junit-platform-testkit@1.7.2 > org.assertj:assertj-core@3.16.1

Test-only transitive dependency, but snyk test doesn't distinguish, so CI stays red.

What

spock-core 2.0-groovy-2.5 → 2.3-groovy-2.5. junit-platform-testkit is the sole source of assertj-core, and Spock 2.2 dropped it from its POM entirely — so this removes the vulnerable path at the source rather than pinning around it. Chose 2.3-groovy-2.5 because it's the newest release on the Groovy 2.5 line and still supports Java 8; Spock 2.4 requires Java 11, which CI (setup-java with 8.x) doesn't have.

Forcing assertj-core:3.27.7 via a constraint was the alternative. Worth noting it wouldn't have been a durable fix on its own: junit-platform-testkit:1.9.0 still ships assertj-core:3.23.1, so the constraint would need maintaining as an indefinite override of a dependency we don't otherwise want.

mockito-core 2.7.22 → 4.11.0. Not cosmetic — required by the change above. Dropping testkit also stopped Spock from pulling byte-buddy up to 1.11.0, which exposed mockito 2.7.22's own byte-buddy:1.6.11. That version can't define classes on Java 11+, so CliDownloaderTest failed with Mockito cannot mock this class ... Cannot define class using reflection for anyone building on a modern JDK. 4.11.0 is the last mockito release supporting Java 8 and brings byte-buddy 1.12.19, so nothing is downgraded relative to before this PR. The test source needed no changes.

Verification

Run locally with Gradle 6.1 on JDK 11 (Gradle 6.1 can't run on newer JDKs):

• ./gradlew clean build -x functionalTest — BUILD SUCCESSFUL, CliDownloaderTest 2 tests / 0 failures
• ./gradlew functionalTest — BUILD SUCCESSFUL, Groovy specs compile against Spock 2.3
• Resolved test classpath: 20 → 13 dependencies, assertj-core absent, no version downgrades
• All 13 remaining dependency versions are clean in OSV; assertj-core@3.16.1 was the only hit (GHSA-rqfh-9r24-8c9r)

I could not get an authoritative local snyk test against the production vuln DB (my CLI is pointed at api.dev.snyk.io, which doesn't carry this advisory — it reports "no vulnerable paths" even on unmodified master). The Snyk Test step on this PR is the real confirmation.

Pre-existing issue, deliberately not fixed here

functionalTest executes zero tests. Neither build.gradle nor gradle/functional-test.gradle calls useJUnitPlatform(), so Gradle 6.1 defaults to JUnit 4 and never discovers the Spock 2.x specs — the step compiles them, then finishes in ~0.1s green. That is true on master today and is unchanged by this PR.

Left out on purpose: enabling it would actually start running SnykTestFT / SnykMonitorFT, which download the Snyk CLI and invoke it against real projects, and the specs use JUnit 4 @Rule TemporaryFolder, which needs the separate spock-junit4 module under Spock 2.x. That is its own change with its own failure modes and shouldn't ride along with a CI-unblocking fix.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.