Symptom

Dependabot / Kraken nightly scan flagged org.bitbucket.b_c:jose4j:0.9.5 as a high-severity CVE (GHSA-3677-xxcr-wjqv, patched in 0.9.6). GitHub’s SBOM confirmed version 0.9.5 in the repo’s dependency graph. Kraken initially classified it as a shippable-runtime dependency; investigation showed it is build-classpath-only.

Root cause

com.android.tools.build:bundletool (pulled by AGP for Android packaging) transitively depends on jose4j. This lands in the Gradle buildscript classpath, not the server runtime classpath — it is never shipped in the deployed JAR or Debian package. Gradle’s project-level dependency resolution does not see buildscript classpaths; hence ./gradlew :server:dependencies reported nothing for jose4j even though GitHub’s SBOM correctly listed it.

Fix

• Added jose4j = "0.9.6" to gradle/libs.versions.toml as the canonical version record (with a comment explaining the buildscript-only scope).
• Added a buildscript { configurations.all { resolutionStrategy.force(...) } } block at the top of build.gradle.kts to override the bundletool-requested 0.9.5 with 0.9.6 across every buildscript configuration.

Prevention

• Build-classpath CVEs do not appear in ./gradlew :module:dependencies output. Use GitHub’s SBOM (gh api /repos/.../dependency-graph/sbom) + the SBOM’s relationships array to identify which package introduced the vulnerable dep.
• The existing DependencyVersionGuardTest pattern does not extend to buildscript classpaths (different ClassLoader); no automated regression test is feasible for this class of vulnerability. The libs.versions.toml entry and the buildscript force together serve as the guard — a future editor who removes either will re-expose the GHSA alert.