fix(security): refresh postgres-mcp Trivy ignore list - #208
Conversation
|
Warning Review limit reached
Next review available in: 24 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe Trivy ignore configuration revises CVE exclusions across UBI9 base-image libraries and utilities, updates applicability statements, removes older entries, and adds package URL and expiration metadata. ChangesTrivy ignore rule updates
Estimated code review effort: 4 (Complex) | ~45 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Up to standards ✅🟢 Issues
|
6ae445b to
c794d9e
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.trivy/postgres-mcp.trivyignore.yaml:
- Around line 2-6: Update all Trivy ignore entries in this file, including the
glib2 entry, to include a meaningful future expiration date via the repository’s
supported expiration field. Preserve each existing rationale and choose dates
that require periodic review rather than permanent suppression.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 11bb89a9-3686-41e3-8275-e7cfbb4ec51c
📒 Files selected for processing (1)
.trivy/postgres-mcp.trivyignore.yaml
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.trivy/postgres-mcp.trivyignore.yaml (1)
413-603: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winScope package-specific ignore entries with exact
purlsThese blocks are justified by the specific UBI9 packages/Go module, but an id-only entry also suppresses the same CVE if Trivy attributes the finding to a different dependency in the future. Add exact
purls:entries for the relevant RPM packages/Go module, using non-wildcard versions/qualifiers where needed.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.trivy/postgres-mcp.trivyignore.yaml around lines 413 - 603, Update each ignore entry in the shown package-specific blocks to include an exact purls constraint for the justified UBI9 RPM package or golang.org/x/crypto module, using the precise package name and required non-wildcard version or qualifiers. Preserve the existing CVE IDs and statements, and ensure each ignore cannot suppress the same CVE when attributed to another dependency.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.trivy/postgres-mcp.trivyignore.yaml:
- Around line 413-603: Update each ignore entry in the shown package-specific
blocks to include an exact purls constraint for the justified UBI9 RPM package
or golang.org/x/crypto module, using the precise package name and required
non-wildcard version or qualifiers. Preserve the existing CVE IDs and
statements, and ensure each ignore cannot suppress the same CVE when attributed
to another dependency.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 62602ad0-7edf-487a-a2a9-e4d83dc93f7a
📒 Files selected for processing (1)
.trivy/postgres-mcp.trivyignore.yaml
moizpgedge
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.trivy/postgres-mcp.trivyignore.yaml (1)
968-970: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winOperational: version-pinned purls plus a single shared expiry date create one hard CI cliff.
Every entry pins an exact
name@versionand expires on the same day (2026-10-29). Two consequences worth planning for: (a) any base-image package bump silently drops the match and re-reports the CVE mid-cycle; (b) on 2026-10-29 the entire suppression set lapses at once, likely turning a green pipeline red in a single run. Consider staggering expiry dates by package group, and adding a scheduled job that scans with--show-suppressedso orphaned/stale entries and upcoming expiries surface before they block a release.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.trivy/postgres-mcp.trivyignore.yaml around lines 968 - 970, Update the Trivy ignore configuration to avoid a shared expiry cliff: stagger expired_at dates across related package groups instead of using one common date, and add a scheduled scan using --show-suppressed to identify stale or orphaned version-pinned purls and upcoming expirations before CI is affected.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.trivy/postgres-mcp.trivyignore.yaml:
- Around line 8-10: Update every expired_at value of 2026-10-29T00:00:00Z in the
Trivy ignore configuration to the YYYY-MM-DD value 2026-10-29, preserving the
existing ignore entries and structure.
---
Nitpick comments:
In @.trivy/postgres-mcp.trivyignore.yaml:
- Around line 968-970: Update the Trivy ignore configuration to avoid a shared
expiry cliff: stagger expired_at dates across related package groups instead of
using one common date, and add a scheduled scan using --show-suppressed to
identify stale or orphaned version-pinned purls and upcoming expirations before
CI is affected.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: f3ac0cd1-a210-4fb8-adbf-6b0aacf9fce9
📒 Files selected for processing (1)
.trivy/postgres-mcp.trivyignore.yaml
| purls: | ||
| - "pkg:rpm/redhat/glib2@2.68.4-19.el9_8.2" | ||
| expired_at: 2026-10-29T00:00:00Z |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -uo pipefail
# 1) Is this ignorefile actually wired into CI/scan tooling?
rg -n --hidden -g '!.git' 'trivyignore|--ignorefile|trivyignores' . || echo "NO REFERENCE FOUND"
# 2) Any mix of expired_at formats in the file?
rg -n 'expired_at' .trivy/postgres-mcp.trivyignore.yaml | sed -n '1,5p'
rg -n 'expired_at' .trivy/postgres-mcp.trivyignore.yaml | awk '{print $2}' | sort -u
# 3) Entry count vs expired_at count (every entry should be date-bounded)
grep -c '^ - id:' .trivy/postgres-mcp.trivyignore.yaml
grep -c 'expired_at:' .trivy/postgres-mcp.trivyignore.yamlRepository: pgEdge/pgedge-postgres-mcp
Length of output: 403
🌐 Web query:
Trivy ignore file expired_at value format time.Time RFC3339 vs yyyy-mm-dd parsing
💡 Result:
In Trivy, the expired_at value in ignore files (such as .trivyignore and .trivyignore.yaml) must be specified in the yyyy-mm-dd date format [1][2][3]. While early development discussions sometimes referenced RFC3339 [4], the actual implementation uses the yyyy-mm-dd layout for parsing expiration dates [5][2]. Key details regarding the format: - YAML Format (.trivyignore.yaml): The expired_at field explicitly requires the yyyy-mm-dd format [1][3]. - Legacy Format (.trivyignore): The expiration is defined using the exp:yyyy-mm-dd syntax [4][2]. - Technical Implementation: Internally, Trivy uses Go's time.Parse with the layout string "2006-01-02" (which corresponds to yyyy-mm-dd) to parse these values [5]. It does not support full RFC3339 timestamps (which include time and timezone offsets) for these fields [5][4]. If an expired_at value is not set, the ignore finding is considered valid indefinitely [1][5].
Citations:
- 1: https://trivy.dev/docs/latest/configuration/filtering/
- 2: https://trivy.dev/docs/latest/scanner/misconfiguration/config/config/
- 3: https://trivy.dev/docs/latest/guide/configuration/filtering/
- 4: feat: allow expiration date for .trivyignore entries aquasecurity/trivy#2332
- 5: https://github.com/aquasecurity/trivy/blob/main/pkg/result/ignore.go
🏁 Script executed:
#!/bin/bash
set -uo pipefail
echo "Changed files summary:"
git diff --stat || true
echo
echo "Diff around postgres-mcp trivyignore (if present):"
git diff -- .trivy/postgres-mcp.trivyignore.yaml | sed -n '1,220p' || true
echo
echo "References to .trivy/postgres-mcp.trivyignore.yaml or postgres-mcp.trivyignore:"
rg -n --hidden -g '!.git' 'postgres-mcp\.trivyignore|postgres-mcp\.trivyignore\.yaml|trivyignore\.yaml|--ignorefile|trivy' . || true
echo
echo "Trivy YAML syntax/ignore file docs in repo comments or files:"
rg -n --hidden -g '!.git' 'expired_at|purls:|vulnerabilities:|[.]trivyignore|trivyignore\.yaml' README* .github .trivy || true
echo
echo "Inspect first 90 lines:"
sed -n '1,90p' .trivy/postgres-mcp.trivyignore.yamlRepository: pgEdge/pgedge-postgres-mcp
Length of output: 18052
Use YYYY-MM-DD for Trivy ignore-file expirations.
Trivy parses expired_at in 2006-01-02 layout, so the RFC3339 timestamp is invalid for at least this YAML ignore config. Change every 2026-10-29T00:00:00Z to 2026-10-29; otherwise the ignored findings may not apply and a scan with --quiet can still report failures outside this PR.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.trivy/postgres-mcp.trivyignore.yaml around lines 8 - 10, Update every
expired_at value of 2026-10-29T00:00:00Z in the Trivy ignore configuration to
the YYYY-MM-DD value 2026-10-29, preserving the existing ignore entries and
structure.
Rebuilt the server image from current source and rescanned with Trivy. Every "fix available" Critical/High finding from the report disappears on a fresh build: pgx 5.7.6->5.10.0, golang.org/x/crypto 0.44.0->0.54.0, golang.org/x/net 0.47.0->0.57.0, and the Go stdlib via the floating golang:1.26-alpine tag all resolve without a code change. microdnf update already in Dockerfile.server also picks up patched gnutls, libcap, openssl/openssl-libs, libacl, and the previously reported glib2 finding on a fresh build. The only Critical/High findings with no upstream fix are 5 curl-minimal/ libcurl-minimal CVEs (QUIC, WebSocket, SASL auth, TLS-mismatch, SSH/SCP), none of which the single `curl -fsSL -o` KB-download invocation in Dockerfile.server can trigger. Replaced the stale curl entries (already fixed, no longer present in any scan) with the current 5, each justified by the specific curl feature it requires. Also refreshed glib2 and openssl/openssl-libs entries to the current CVE set (CGO_ENABLED=0 pure Go binary never calls into either library), removed the now fully-clean glibc section, and added golang.org/x/crypto/openpgp (unmaintained package, only bcrypt is actually imported). Verified: `trivy image --ignorefile .trivy/postgres-mcp.trivyignore.yaml` against the freshly-built image reports 0 Critical, 0 High. Co-Authored-By: Claude <noreply@anthropic.com>
Added justified trivyignore entries for the 71 remaining CVEs (106 total across split subpackages), each naming the specific unreached code path. Verified against a raw scan: 0 orphaned entries, 0 gaps. Fresh image scan now reports 0 findings at every severity.
Same fix already applied to nla-web.trivyignore.yaml in this repo: CodeRabbit flagged that all 106 entries here matched a CVE ID against any package in the scan (no purls) and never expire (no expired_at), so a rationale tied to today's CGO_ENABLED=0/UBI9 assumptions would stay in force indefinitely even if those assumptions changed. Rebuilt Dockerfile.server fresh, took a raw scan, and generated package-scoped purls (bare, unqualified) plus expired_at: 2026-10-29T00:00:00Z for all 106 entries from the actual scan output, so every purl matches the exact package+version present in the image. Cross-checked: 0 gaps, 0 orphans, both before and after the rewrite. Verified: go build/vet/test pass, and `trivy image --ignorefile .trivy/postgres-mcp.trivyignore.yaml` against the freshly built image reports 0 findings on both scan targets (redhat OS packages and the Go binary).
161bdab to
cdf332b
Compare
2 participants
What this fixes
A security scan of the published server image flagged 2 Critical and
46 High-severity warnings. Almost all of them came down to one thing:
the published image was old. It was built before several software
updates that had already happened. Rebuilding it from the current
version, with no other changes, fixed nearly everything on the list.
What was left
A handful of warnings remained in a small helper library used only to
download one file during setup (no fix is available for these yet).
I checked what each one actually requires to be a problem, and none of
those conditions exist here: this download happens once, with no login,
no special network setup, and nothing an attacker could realistically
reach. These are documented as "checked, doesn't apply" rather than
silently ignored.
There were also about 113 lower-severity warnings, all in software
included in the base image but never actually used by the server
itself. Same approach: wrote a specific, checkable reason for each one,
then double-checked the entire list against a fresh scan to make sure
nothing was missed or left over from before.
Results
Scanning the newly built image against the updated list of "checked,
doesn't apply" items shows zero warnings, at every severity level.
What this doesn't do
This doesn't publish a new version of the image — that's a separate
release step. The already-published image is unaffected until that
happens.
https://pgedge.atlassian.net/browse/PLAT-701
Summary by CodeRabbit