chore: bump dependencies with open security advisories - #89
Conversation
`parsers/pgparser` resolved `google.golang.org/grpc` to v1.33.1,
`google.golang.org/protobuf` to v1.25.0 and `github.com/sirupsen/logrus` to
v1.6.0 — all transitive through `github.com/auxten/postgresql-parser`, and
between them the subject of eight advisories including a CVSS 9.1 gRPC
authorization bypass (GO-2026-4762).
None was reachable. Every gRPC advisory is server-side (xDS RBAC, HTTP/2
transport) and a SQL parser starts no gRPC server, which is why `make vuln`
has been green throughout: govulncheck reports called symbols, dependency
scanners report the module graph. The graph is what a consumer's own scanner
sees, so the two views should agree.
`google.golang.org/genproto` had to move too. Bumping grpc alone makes the
workspace build fail with an ambiguous import — the pre-split monolithic
genproto and the `googleapis/{api,rpc}` sub-modules both provide
`googleapis/rpc/status` and `googleapis/api/httpbody`. This only reproduces
with `go.work` active; `GOWORK=off` resolves one module set and passes.
Bumping the parent past the split resolves it, and carries grpc to v1.83.2,
which closes the last remaining advisory (GO-2026-6443).
After this `govulncheck` reports no vulnerabilities in any of the nine
modules, with no "in modules you require" caveat.
The website lockfile picks up the patches available for fast-uri, image-size,
js-yaml, nanoid, joi, qs, svgo, smol-toml and colord. js-yaml and
serialize-javascript needed an `overrides` block: Docusaurus pins versions
with open advisories and `npm audit fix` proposes downgrading
@docusaurus/core from 3.10.2 to 3.5.2 rather than pinning the transitive.
`npm run check` passes with the overrides in place. What remains is
webpack-dev-server's dependency on a vulnerable uuid, reachable only from
`npm start` — no CI job or published artifact touches it.
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Repository: KARTIKrocks/sqlguard/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🏁 CodeAnt Quality Gate ResultsCommit: ✅ Overall Status: PASSEDQuality Gate Details
|
| github.com/gogo/protobuf v1.3.2 // indirect | ||
| github.com/golang/protobuf v1.4.3 // indirect | ||
| github.com/google/go-cmp v0.6.0 // indirect | ||
| github.com/golang/protobuf v1.5.4 // indirect |
There was a problem hiding this comment.
Suggestion: Run make tidy across every Go module, including the unpublished integration module, and commit all resulting go.mod and go.sum updates rather than updating only this module.
Severity Level: Major Custom_rule
Rule source 📖
.codeant/review.json line 70 (rule "nine-modules-in-lockstep")
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** parsers/pgparser/go.mod
**Line:** 20:20
**Comment:**
*Custom Rule: Run `make tidy` across every Go module, including the unpublished integration module, and commit all resulting go.mod and go.sum updates rather than updating only this module.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fixCodeAnt applied this rule to PR #89 and asked for `make tidy` across every module "including the unpublished integration module", on a change that bumps transitive indirect dependencies inside `parsers/pgparser` alone. The finding is wrong — `parsers/pgparser/go.mod` is the only go.mod in the repo that references grpc, logrus or genproto, and `make tidy-check` reported every module tidy — but the rule text earned it twice over. It claimed `make tidy` runs across `test/integration`. It does not: the Makefile keeps that module out of SUB_MODULES precisely because it is never released, so `make tidy` cannot reach it. The rule was describing a command this repo does not have. It also phrased the tidy requirement as an unconditional "across all of them", which reads as every go.mod changing together. Lockstep governs the public API and the Go version, not a leaf module's own indirect dependency graph. The rule now says so, and says to check whether another go.mod actually references the dependency before flagging. Only .codeant carried this claim. Greptile's `rules.md` scopes the topology note to "a change to an exported surface", and `.coderabbit.yaml` only states the no-replace-directive half, so both were already correct.
User description
Clears every open security advisory in the repo's dependency graph that has a
fix, and documents the two that don't.
The Go side:
parsers/pgparserCodeAnt's repo scan of
4029bbfreported 8 Go advisories, all transitivethrough
github.com/auxten/postgresql-parser:google.golang.org/grpcgoogle.golang.org/protobufgithub.com/sirupsen/logrusNone was reachable, which is worth stating rather than glossing over: every
gRPC advisory is server-side — xDS RBAC, HTTP/2 transport, Rapid Reset — and a
SQL parser starts no gRPC server.
govulncheckreported 0 called symbolsbefore this change, which is why
make vulnhas been green throughout. Thepoint of the bump is that a consumer's own scanner reads the module graph, not
the call graph, and would flag a 9.1 on a library they linked for SQL parsing.
The genproto part is not incidental
Bumping grpc alone breaks the workspace build:
The pre-split monolithic
genprotoand thegoogleapis/{api,rpc}sub-modulesboth provide those packages. This only reproduces with
go.workactive —GOWORK=off go test ./...resolves one module set and passes, so the firstversion of this change looked fine and
make ciis what caught it. Bumping theparent past the split fixes it, and carries grpc to v1.83.2, which closes the
last advisory (GO-2026-6443, still open at v1.83.1).
Result:
govulnchecknow reports no vulnerabilities across all nine moduleswith no "in modules you require" caveat.
The npm side:
website/22 of the 30 advisories were in the Docusaurus build chain.
npm audit fixtook fast-uri, image-size, nanoid, joi, qs, svgo, smol-toml and colord to
patched releases with no breaking change.
Two needed an
overridesblock, which is whypackage.jsonchanged:js-yaml— Docusaurus pins 4.3.0; the patches are in 4.3.2.serialize-javascript— 6.0.2 via the webpack plugins; the RCE fix is in 7.x.npm audit fixwill not do either on its own. It proposes@docusaurus/core@3.5.2, which is a downgrade from the pinned 3.10.2.npm run check(lint + typecheck + build) passes with the overrides in place.What's left: 17 moderate, all tracing to one root cause —
webpack-dev-serverdepends on auuidwith a missing bounds check. Clearingit needs a uuid v8 to v11 major bump behind a transitive, and
webpack-dev-serveronly runs undernpm start; neitherci.ymlnordocs.ymltouches it. Left alone deliberately and noted inAGENTS.md, alongwith why the
overridesblock exists so it doesn't get tidied away later.Not in this PR
The same scan flags
auxten/postgresql-parseras an unknown license. It is aCockroachDB parser fork whose LICENSE says source is Business Source License
1.1 "unless otherwise noted at the beginning of the file", and 129 of the files
pgparserimports carry a BSL header pointing at alicenses/BSL.txtthemodule does not ship. sqlguard is MIT. That needs a decision, not a dependency
bump.
Verification
make ci— fmt-check, vet, lint, vuln, test-race, lint-docs across all nine modulesmake tidy-check— all modules tidyGOWORK=off go test ./...inparsers/pgparser— the consumer's viewnpm run checkinwebsite/CodeAnt-AI Description
Remove known vulnerabilities from Go modules and the documentation build
What Changed
Impact
✅ Fewer dependency security alerts✅ Safer PostgreSQL parser dependencies✅ Safer documentation builds💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.