Symptom

Nightly dependency-CVE scan (Kraken) flagged a Dependabot high-severity alert for com.google.code.gson:gson (GHSA-4jrv-ppp4-jm57, affects < 2.8.9). The alert was triggered because androidApp transitive chains (Firebase/Play Services) declare gson 2.8.9 exactly, which surfaces in the Gradle dependency graph even though conflict-resolution already elevates the effective version to 2.11.0.

Root cause

gson was not explicitly managed anywhere in the build. Gradle’s dependency conflict resolution happened to pick the highest requested version (2.11.0, from grpc-core), so no vulnerable version landed on any runtime classpath. However, the absence of an explicit floor meant Dependabot saw the 2.8.9 declaration and fired an alert, and future transitive additions could have regressed to a vulnerable version without any guard.

Fix

Added gson = "2.11.0" to gradle/libs.versions.toml (same block as the other security-pinned versions: jackson, netty, bouncycastle, jose4j, gson). Added an allprojects { configurations.configureEach { resolutionStrategy.eachDependency {} } } block in the root build.gradle.kts that floors gson at 2.11.0 across all configurations, with a because("Floor: GHSA-4jrv-ppp4-jm57 ...") annotation for traceability.

Prevention

• Every security-sensitive transitive dependency should have an explicit version floor in libs.versions.toml + a resolutionStrategy rule (or BOM constraint) rather than relying on Gradle conflict-resolution picking the highest version by accident.
• When Kraken flags a “declared version is vulnerable” alert, check whether Gradle’s resolved version is already safe before assuming the classpath is vulnerable. The fix in those cases is to make the implicit safe resolution explicit, not to add a direct dependency.