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`):

```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

```bash
# 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:

```dockerfile
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:

```yaml
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:

```dockerfile
# 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

- [x] Investigated postgres Dockerfile
- [x] Identified likely source (base image + Alpine packages)
- [x] Analyzed build dependencies
- [x] Reviewed remediation options
- [x] 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