Skip to content

Document gremlin-shaded/databricks-jdbc vendored Jackson/lz4 CVEs as accepted exceptions - #3203

Open
terryozaki-wq wants to merge 1 commit into
devfrom
document-gremlin-databricks-vendored-cves
Open

terryozaki-wq wants to merge 1 commit into
devfrom
document-gremlin-databricks-vendored-cves

Conversation

@terryozaki-wq

Copy link
Copy Markdown

Summary

  • gremlin-shaded (via tinkerpop.version, currently 3.7.7) and databricks-jdbc (currently 2.8.4) each shade a private copy of jackson-databind/jackson-core or lz4-java into their own bytecode.
  • Shaded copies are invisible to this repo's jackson2.version/jackson3.version/lz4.version dependencyManagement pins — a version bump here has no effect on them — but scanners (Dependabot/Inspector-style) still flag the embedded classes against this repo.
  • Adds docker/DEPENDENCY-EXCEPTIONS.md recording what was checked and why no fix is currently available, so the next scanner hit doesn't restart the investigation from scratch:
    • gremlin-shaded: every stable TinkerPop release through the latest 3.8.2 bundles the same vulnerable Jackson 2.18.9 (3.8.0 actually regresses to 2.15.2); only the pre-release 4.0.0-beta.3 relocates Jackson, which isn't warranted as a dependency for this alone.
    • databricks-jdbc: the bundled lz4-java is fixed in the 3.x line (confirmed by downloading and inspecting 3.4.4.jar directly), but no fix exists in the current 2.x line; this repo's own directly-declared lz4-java is already on the fixed version, so only the copy vendored inside the driver jar is affected.

No code change — this is a documentation-only accepted-exception record. Confirmed dev and IL4-dev pin the identical tinkerpop.version (3.7.7) and databricks.jdbc.version (2.8.4), so the same investigation and conclusions, originally done on IL4-dev, transfer directly.

Test plan

  • N/A — documentation only, no code or dependency change

🤖 Generated with Claude Code

… as accepted exceptions

Both jars shade a private copy of jackson-databind/jackson-core
(gremlin-shaded, via tinkerpop.version) or lz4-java (databricks-jdbc)
into their own bytecode. These copies are invisible to this pom.xml's
jackson2.version/jackson3.version/lz4.version dependencyManagement
pins, so scanners keep flagging CVEs against them that a version bump
here can't fix. Documents what was checked (every stable TinkerPop
release through 3.8.2, and databricks-jdbc 3.4.4) and why no fix is
currently available, so the next scanner hit doesn't re-start the
investigation from scratch.

No code change; this is a documentation-only accepted-exception record,
written after the same investigation on IL4-dev found both repos pin
the identical tinkerpop.version (3.7.7) and databricks.jdbc.version
(2.8.4), so the same vendored versions and conclusions apply here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@terryozaki-wq
terryozaki-wq requested a review from a team as a code owner October 26, 2026 16:01
@snyk-io

snyk-io Bot commented Oct 26, 2026

Copy link
Copy Markdown
Contributor

✅ Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
✅ Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant