Kraken’s nightly dependency-CVE scan opened #819: eight open Dependabot
alerts (one high on netty-handler, others medium/high on netty-codec,
netty-codec-http, netty-codec-http2), all patched at 4.1.135.Final
or earlier. The lead’s own hypothesis noted the netty version ref in
gradle/libs.versions.toml was already 4.2.15.Final and asked Blue to
verify no 4.1.x leaked in transitively via the AWS SDK or ktor before
treating the alerts as cleared.
They already were cleared. git log -S "4.2.15.Final" traced the bump
to b890f6ce3 (tag v1.0.1063), an ancestor of both agents/main
and the exact commit Kraken scanned
(daa17043f4bd0609667ef5e2dbc96fd1d14680f7) — the fix had shipped long
before this lead was filed. ./gradlew :server:dependencyInsight
--configuration jvmRuntimeClasspath --dependency io.netty:netty-handler
confirmed the server module resolves 4.2.15.Final via the netty BOM +
conflict resolution (beating the AWS SDK’s own 4.1.135.Final request),
and the same check against both aws/cloudfront-deb-lambda and
aws/apigw-server-logging-lambda (which don’t import the netty BOM)
confirmed the AWS SDK BOM 2.46.5’s own netty-nio-client pin already
resolves netty-handler/netty-codec/netty-codec-http/
netty-codec-http2 to 4.1.135.Final — above every GHSA’s patched
floor in the cluster. GitHub’s Dependabot alert list for a Gradle repo
without a submitted dependency-graph snapshot can lag the actual
resolved classpath, which is the likely reason the alerts were still
showing “open” when Kraken’s scan read them.
No version bump needed — the classification didn’t hold up. Added
defense-in-depth only: a nettyHandlerSecurityFloor = "4.1.135.Final"
entry in gradle/libs.versions.toml and a matching
resolutionStrategy.eachDependency rule in build.gradle.kts (mirrors
the existing netty-common floor rule) that forces
netty-handler/netty-codec/netty-codec-http/netty-codec-http2
up to 4.1.135.Final if a future transitive ever requests lower on the
AWS Lambda modules’ 4.1.x path. Re-ran dependencyInsight on all three
runtime classpaths after adding the rule to confirm it resolves
identically (a no-op today, as designed).
When a nightly-scan lead’s own hypothesis says “the floor may already
be correct — verify,” actually resolve the dependency graph
(dependencyInsight) before assuming a bump is needed. git log -S on
the version-catalog entry plus git merge-base --is-ancestor against
the scanned commit is a fast way to confirm a fix already landed before
the alert was filed. Not every Kraken security lead requires a code
change — sometimes the correct PR is a stale-alert confirmation plus a
defense-in-depth hardening, not a version bump.