stack/docs/scratchpads/181-security-go-stdlib-postgres.md

Issue #181: Security - Update Go stdlib in postgres image

Objective

Fix HIGH severity vulnerabilities in Go stdlib components found in the postgres Docker image via Trivy scanner.

Issue Summary

Trivy scan identified the following vulnerabilities:

• CVE-2025-58183 - Go stdlib vulnerability
• CVE-2025-61726 - Go stdlib vulnerability
• CVE-2025-61728 - Go stdlib vulnerability
• CVE-2025-61729 - Go stdlib vulnerability

Affected Package: stdlib (Go)

• Current Version: v1.24.6
• Fixed Versions: 1.24.12 or 1.25.6

Investigation Progress

Phase 1: Source Identification

Dockerfile Analysis

Current postgres Dockerfile (/home/jwoltje/src/mosaic-stack/docker/postgres/Dockerfile):

FROM postgres:17-alpine
...
RUN apk add --no-cache --virtual .build-deps \
    git \
    build-base
...
RUN git clone --branch v0.7.4 https://github.com/pgvector/pgvector.git /tmp/pgvector \
    && cd /tmp/pgvector \
    && make OPTFLAGS="" with_llvm=no \
    && make install with_llvm=no \
    && rm -rf /tmp/pgvector

RUN apk del .build-deps

Analysis:

• Base image: postgres:17-alpine
• Build dependencies: git, build-base
• Extension: pgvector v0.7.4 (built from source)
• Build deps are cleaned up after build (apk del .build-deps)

Potential Sources of Go Stdlib

1. postgres:17-alpine base image - Could contain Go-based tools (e.g., security scanners, monitoring agents)
2. pgvector compilation - pgvector is C/PostgreSQL extension, not Go
3. build-base or git packages - Could have Go dependencies

Phase 2: Root Cause Analysis

The Go stdlib vulnerabilities in this image are most likely coming from:

Most Probable: The base image postgres:17-alpine itself

• PostgreSQL 17 Docker image may include Go-based tooling
• Official PostgreSQL images have added various monitoring/utility tools over time
• Trivy scanner may detect Go stdlib even if only transitively included

Less Probable: Build dependencies

• build-base is C/C++ build tools, not Go
• git doesn't depend on Go
• pgvector is pure C extension

Phase 3: Available Remediation Options

Option A: Update Base Image (Preferred)

• Upgrade to postgres:17-alpine with latest patches
• Postgres 17 is the latest stable, Alpine is latest
• May already have fixed Go stdlib versions

Option B: Add Go stdlib patch/update step

• If base image can't be updated, add explicit Go stdlib update
• Alpine uses apk upgrade for package updates
• May require Go development tools to be available

Option C: Build custom base image

• Complex solution, maintenance burden
• Only if no other solution works

Findings

Investigation Commands Executed

# Verify current Dockerfile
cat /home/jwoltje/src/mosaic-stack/docker/postgres/Dockerfile

# Check git log for related security fixes
git log --all --oneline --grep="trivy\|181\|security"

# Search for existing Trivy configuration
find /home/jwoltje/src/mosaic-stack -name "*trivy*" -o -name ".trivyignore*"

# Check Woodpecker CI for scanning steps
grep -n "trivy\|scan" /home/jwoltje/src/mosaic-stack/.woodpecker.yml

Current Status

• Base image postgres:17-alpine is already latest stable
• Build dependencies removed after compilation (no bloat)
• No explicit Go tooling in Dockerfile
• Go stdlib likely transitively included in base image

Recommended Solution

Approach: Base image pinning with security updates

Since the Go stdlib vulnerabilities come from the base image postgres:17-alpine, the best solution is:

1. Keep current postgres:17-alpine base (it's the latest stable)
2. Let Docker's base image automatic security updates handle it
3. Alternatively: Pin to specific PostgreSQL patch version that includes Go stdlib fixes

Example: Pin to specific PostgreSQL version with Go stdlib fix

Once PostgreSQL releases a new patch with Go stdlib fixes (e.g., 17.2-alpine), update:

FROM postgres:17.2-alpine  # Pin to version with Go stdlib fix

Secondary: Implement Trivy scanning in CI/CD

Add Trivy scanner step to .woodpecker.yml to catch vulnerabilities early:

docker-scan-postgres:
  image: aquasec/trivy:latest
  commands:
    - trivy image --exit-code 0 --severity HIGH postgres:17-alpine
  depends_on:
    - docker-build-postgres

Resolution Applied

Update Applied

Added explicit Alpine package update/upgrade step after base image pull to ensure all packages (including those with Go stdlib dependencies) are patched:

# Update Alpine packages to patch Go stdlib vulnerabilities (CVE-2025-58183, CVE-2025-61726, CVE-2025-61728, CVE-2025-61729)
RUN apk update && apk upgrade

This ensures:

1. Alpine package index is updated
2. All installed packages are upgraded to latest patched versions
3. Go stdlib components from any packages (LLVM, build tools, etc.) are patched
4. Runs BEFORE build dependencies are installed, ensuring clean base

Why This Fix Works

• Alpine packages are tied to specific Go stdlib versions
• By running apk upgrade, we pull the latest package versions
• If Alpine has released a new postgres:17-alpine image with patched Go stdlib, Docker will use it
• The upgrade command captures all transitive dependencies including LLVM libs

Status

• Investigated postgres Dockerfile
• Identified likely source (base image + Alpine packages)
• Analyzed build dependencies
• Reviewed remediation options
• Applied fix: Added apk update && apk upgrade to Dockerfile
• Build and test updated image
• Run Trivy scan to verify fix

Verification Next Steps

1. Build the updated Docker image: docker build -t test-postgres docker/postgres/
2. Run Trivy scan on image: trivy image test-postgres
3. Verify CVE-2025-58183, CVE-2025-61726, CVE-2025-61728, CVE-2025-61729 are resolved
4. If vulnerabilities persist, may require waiting for newer Alpine/Go releases

Notes

• The vulnerability originates from Alpine Linux base packages (likely LLVM or transitive Go dependencies)
• The build process properly cleans up build dependencies (apk del .build-deps)
• The fix is minimal and non-intrusive - just ensures base packages are up-to-date
• No application code changes needed