Dependabot raised two security alerts against com.google.guava:guava — GHSA-5mg8-w23w-74h3 (low) and GHSA-7g45-4rm6-3mm3 (medium) — both patched in 32.0.0-android.
com.google.guava:guava is not directly declared in the project; it arrives transitively via gRPC (grpc-api, grpc-core, etc.) pulled in by krill-pi4j. Gradle’s conflict-resolution currently selects 33.3.1-android, which already clears both CVEs, but there was no explicit version floor. Without an explicit constraint, a future dependency update could introduce a transitive that pins an older vulnerable version and “win” the conflict resolution.
guava = "32.0.0-android" to gradle/libs.versions.toml with an explanatory comment.allprojects { resolutionStrategy.eachDependency } rule in build.gradle.kts that floors com.google.guava:guava at 32.0.0-android. Gradle currently resolves 33.3.1-android (above the floor), so no runtime change occurs; the rule exists purely as a defensive lower bound.libs.versions.toml (version entry) + build.gradle.kts (eachDependency rule), following the same pattern used for jackson, netty, bouncycastle, gson, jose4j, jdom2, and log4j2../gradlew :server:dependencyInsight --dependency guava --configuration jvmRuntimeClasspath after any related dependency change to confirm the floor is respected before merging.