Symptom

The repo’s security tab still showed a handful of open Dependabot alerts even though the recent QA-Sec fix train (netty, jackson, logback, bouncycastle, log4j2, commons-lang3) had landed. Reviewed against the actual manifests, they split into two buckets: alerts already mitigated on main (Maven pins/floors in gradle/libs.versions.toml + build.gradle.kts that GitHub’s manifest parser cannot see resolving), and two genuinely-open vulnerable dependencies in the non-JVM manifests:

• ws@8.18.0 / ws@8.20.1 in kotlin-js-store/wasm/yarn.lock — GHSA-58qx-3vcg-4xpx (moderate, < 8.20.1) and GHSA-96hv-2xvq-fx4p (high, < 8.21.0). Build/test toolchain only, never shipped.
• requests 2.32.5 in lambdas/python/uv.lock — GHSA-gc5v-m9x4-r6x2 (CVE-2026-25645, < 2.33.0). Present only on the python_full_version < '3.10' resolution branch that requires-python = ">=3.9" forced uv to keep.

Root cause

Two seams let patched-elsewhere dependencies stay vulnerable here:

1. The Kotlin/Wasm toolchain pins exact ws versions per requester, so two side-by-side ws entries aged in the autogenerated lockfile with no resolution() override to unify them past the patched floor.
2. requests fixed CVE-2026-25645 only in 2.33.0+, which requires Python >= 3.10. As long as lambdas/python declared 3.9 support, uv dutifully kept a second, permanently-unfixable requests 2.32.x resolution branch in the lockfile.

Fix

• build.gradle.kts: added resolution("ws", "8.21.0") next to the existing path-to-regexp resolution so kotlinUpgradeYarnLock can’t revert it; collapsed the two ws entries in kotlin-js-store/wasm/yarn.lock to a single 8.21.0 entry.
• lambdas/python/pyproject.toml: raised requires-python to >=3.10 and the dependency floor to requests>=2.33.0; re-ran uv lock, which dropped the vulnerable 2.32.5 branch and left a single clean 2.34.2 resolution.

Prevention

• When a security fix for a locked dependency only exists above the declared language floor (requires-python, Node engines, etc.), the floor itself is the vulnerability: either raise it or record an explicit risk acceptance. A version-range bump alone can silently leave a split-resolution lockfile vulnerable on the old-runtime branch.
• Any bump inside kotlin-js-store/wasm/yarn.lock must be paired with a resolution(...) entry in build.gradle.kts, or the next kotlinUpgradeYarnLock reverts it (established by the path-to-regexp fix; now followed for ws).
• Maven alerts that GitHub keeps open after a pin/floor lands are usually stale-graph artifacts: GitHub parses Gradle manifests, not the resolved graph, so eachDependency floors are invisible to it. Verify with dependencyInsight and dismiss the alert with evidence rather than re-fixing.