fix: patch Snyk-reported OpenTelemetry API vulnerability#3745
Conversation
Bump the OpenTelemetry stack to clear a high-severity advisory in opentelemetry-api that ships in the image: - API/SDK 1.60.1 -> 1.62.0 - Java agent + instrumentation 2.26.1 -> 2.28.1 Also override the Spring Boot BOM's managed opentelemetry.version (1.49.0), which otherwise pins opentelemetry-extension-kotlin to a stale, CVE-affected release transitively, so every shipped opentelemetry-* jar resolves to 1.62.0. Verified against the built bootJar and a Gradle Snyk scan: no opentelemetry findings remain. Compile and data unit tests pass.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR updates OpenTelemetry Gradle dependency versions and adds a project extension property to control OpenTelemetry core resolution. gradle.properties bumps the agent/instrumentation versions to 2.28.1 and API to 1.62.0; build.gradle adds a new ChangesOpenTelemetry Version Updates
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Documents risk-acceptance for the advisories that remain after the dependency-fix PRs (#3742, #3743, #3744, #3745). None of these have a clean upstream fix, and none carry meaningful real-world risk — so rather than leave them flagged as open alerts (drowning out future *real* findings), they're explicitly accepted with a justification and a re-review expiry. ### `webapp/.snyk` — browser-side, input crosses no trust boundary | Advisory | Package | Why accepted | |---|---|---| | `SNYK-JS-ZXCVBN-3257741` | zxcvbn (ReDoS) | input is the user's own password as they type; worst case is self-slowdown of their own tab. Unmaintained, no patched release. | | `SNYK-JS-INFLIGHT-6095116` | inflight (leak) | reached only via a Node-only `broadcast-channel → rimraf → glob` path not exercised in the browser bundle. Deprecated, no fix. | | `SNYK-JS-D3COLOR-1076592` | d3-color (ReDoS) | parses app-controlled chart colors, not untrusted input. Fix needs a major d3 bump that risks breaking recharts. | ### `e2e/.snyk` — test-only Cypress harness | Advisory | Package | Why accepted | |---|---|---| | `SNYK-JS-XLSX-6252523` | xlsx (ReDoS) | never shipped, runs in CI against known fixtures. No npm fix (SheetJS distributes via CDN only). | | `SNYK-JS-XLSX-5457926` | xlsx (prototype pollution) | same as above. | Each entry has a one-year `expires` so they resurface for re-review. Verified locally — `snyk test` in `webapp/` and `e2e/` reports these as ignored (e2e is now clean). Follow-up tech-debt (not security): migrate `zxcvbn` → the maintained `@zxcvbn-ts/core` fork. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated security vulnerability management policies to the latest format and configuration standards across testing and application environments. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
This PR is stale because it has been open for 30 days with no activity. |
|
This PR was closed because it has been inactive for 14 days since being marked as stale. |
Clears the high-severity Snyk advisory in
opentelemetry-apithat ships in thetolgee/tolgeeimage (the last shipped high from the Snyk report).Changes
1.60.1→1.62.02.26.1→2.28.1(the agent2.N↔ API1.(N+34)pairing;2.28.xis the latest agent that targets API1.62)opentelemetry.version(1.49.0)The BOM override matters: Spring Boot 3.5.14 pins
opentelemetry.version=1.49.0, which transitively heldopentelemetry-extension-kotlinat a stale, CVE-affected1.49.0inserver-appeven thoughopentelemetryApiVersionwas already higher (it only escaped forapi/context, whichserver-appdeclares directly). Forcing the managed version makes every shippedopentelemetry-*jar resolve to1.62.0.The Docker image's OTEL agent download uses this same
opentelemetryJavaagentVersionvia a build-arg, so the agent stays in lockstep automatically.Verification
Built
bootJarshows allopentelemetry-*jars at1.62.0(-instrumentation-annotationsat2.28.1). Gradle Snyk scan: no opentelemetry findings remain. Full compile + data unit tests (623) pass.Summary by CodeRabbit