Kraken’s nightly dependency-CVE scan opened #822: one open low-severity
Dependabot alert on ch.qos.logback:logback-core (GHSA-p47f-322f-whfh,
vulnerable range <= 1.5.32, first patched 1.5.33). The lead proposed
bumping the logback version ref in gradle/libs.versions.toml from
1.5.32 to 1.5.33.
gradle/libs.versions.toml pinned logback = "1.5.32", consumed via
libs.logback.classic in both server/build.gradle.kts and
composeApp/build.gradle.kts. ./gradlew :server:dependencies
--configuration jvmRuntimeClasspath confirmed logback-classic:1.5.32
pulls in logback-core:1.5.32 transitively and both resolve on the
shipped runtime classpath — the “shippable runtime” classification was
correct. server/build.gradle.kts’s shadowJar minimize { exclude(...)
} block also excludes ch.qos.logback:.*:.*, but that’s a
minimize-safety exclusion (keeps classes ProGuard-style minimize can’t
statically prove are used, e.g. logback.xml-driven appenders) — it
does not remove logback from the shipped jar, so the alert’s runtime
classification held up.
gradle/libs.versions.toml — bumped logback from 1.5.32 to 1.5.33,
matching the alert’s first_patched_version exactly (single-CVE cluster,
no multi-advisory range to reconcile). Re-ran ./gradlew :server:dependencies
--configuration jvmRuntimeClasspath to confirm logback-core now
resolves to 1.5.33 project-wide, and :server:jvmTest stays green.
For a single-alert cluster where the GHSA’s first_patched_version is a
non-null, unambiguous value, the proposed bump can be taken at face
value once the “is it actually on the runtime classpath” check passes —
no need to cross-reference advisory prose the way a multi-advisory
cluster (see the jackson-databind lesson, 2026-07-08-jackson-2-21-4-vs-2-21-5.md)
requires. Still always run the dependency-tree check before trusting the
“shippable runtime” tag; a minimize { exclude(...) } entry for the
package can look like evidence it’s not shipped when it’s actually the
opposite.