PatchPilot: remediate CVEs

[moolen]

CVE remediation (audit-only)

Outcome: No further fixes applied in this rollout — audit-only; repository files were not modified (except this output). Human intervention is required to implement and release an updated image.

Evidence: image build path

• Published image: ghcr.io/moolen/logistis:v0.1.1 (120 scanner findings).
• Build definition: Root Dockerfile (ARG BASEIMAGE=golang:1.19, ARG RUNIMAGE=alpine:3.14, runtime apk add curl).
• CI: .github/workflows/ci.yml runs docker/build-push-action with context: . and pushes ghcr.io/moolen/logistis:<version> — matches the scanned image.
• Makefile sets DOCKERFILE := Dockerfile for local builds.
• Also relevant: .github/workflows/release.yml promotes :main to tag and builds kubectl-blame with goversion: ...go1.19.1... — same stale toolchain surface outside the container.

Recommended remediation (safest effective path)

1. Go toolchain / stdlib (bulk of findings): Replace golang:1.19 with a current patch in the same image family (e.g. golang:<ver>-alpine3.xx). Pick the minimum Go version that satisfies the highest fixed-version bar across reported stdlib CVEs (several 2025–2026 advisories call for ≥1.26.1 or ≥1.25.8 depending on CVE). Do not guess tags: list tags from the registry (e.g. Docker Hub / crane / registry API) for golang within the desired 1.26.*-alpine* (or chosen line) and select a published tag.
2. Alpine runtime + OpenSSL + curl: Bump RUNIMAGE from alpine:3.14 to a supported Alpine that ships non-vulnerable curl/libcurl and OpenSSL (current Alpine uses OpenSSL 3.x; findings reference libcrypto1.1/libssl1.1 from 3.14). Pin apk add to explicit package versions that close the listed curl CVEs, or use a base where default packages are already patched.
3. Go modules (go.mod): Raise go to match the builder; run go get / go mod tidy to bring indirect deps to at least: golang.org/x/net ≥0.38.0 (stricter GHSA ceiling in the set), google.golang.org/protobuf ≥1.33.0, github.com/golang/glog ≥1.2.4, github.com/sirupsen/logrus ≥1.8.3, golang.org/x/text ≥0.3.8, plus any other indirect bumps required for compatibility. Refresh go.sum; run govulncheck ./... after.
4. Release workflow: Update the pinned goversion tarball URL in release.yml to the same major.minor.patch as the Docker build, or switch to a maintained setup-go pattern, so shipped binaries are not rebuilt on vulnerable Go.
5. Dockerfile hygiene: After package installs, ensure the final runtime USER is non-root if policy requires it (current file runs the binary as root).
6. Validation: go build ./..., go test ./..., multi-arch image build as in CI, then rescan the pushed image.

Actions taken (this run)

• Read .patchpilot/input/cve-remediation.json and reviewed Dockerfile, go.mod, .github/workflows/ci.yml, .github/workflows/release.yml, and Makefile.
• Did not change Dockerfile, go.mod, workflows, or dependencies (audit-only constraint).

Validation steps performed

• Repository file review only; no go build, go test, or govulncheck executed (no remediation diff to validate).

Fixed findings

• None — audit-only rollout; no repository remediation applied.

Unresolved findings (still not fixed)

Scanner reported 120 rows; many share the same CVE across paired packages (e.g. curl/libcurl, libcrypto1.1/libssl1.1). Below is a deduplicated summary by package / surface (full per-row enumeration would repeat the same CVE IDs many times for stdlib).

CVE ID	Package	File location	Status	Reason
Multiple distinct CVE/GHSA IDs (stdlib)	stdlib	Dockerfile (BASEIMAGE=golang:1.19), go.mod (go 1.19), .github/workflows/release.yml (Go 1.19.1 tarball)	Open	Audit-only; requires Go toolchain bump to a current patched release (see fixed-version hints in input; newest issues need 1.25.x / 1.26.x range).
CVE-2023-0286, CVE-2023-0215, CVE-2022-4304, CVE-2022-4450, CVE-2023-0464, CVE-2023-0465	libcrypto1.1, libssl1.1	Dockerfile (RUNIMAGE=alpine:3.14)	Open	Audit-only; upgrade Alpine/runtime — old OpenSSL 1.1.1 packages.
CVE-2022-43551, CVE-2022-43552, CVE-2023-23914, CVE-2023-23915, CVE-2023-23916, CVE-2023-27533–CVE-2023-27538, CVE-2023-27536 (and paired libcurl rows)	curl, libcurl	Dockerfile (apk add curl on Alpine 3.14)	Open	Audit-only; pin/upgrade curl or move to base with patched curl.
GHSA-qppj-fm5r-hxr3, GHSA-4v7x-pqxf-cx7m, GHSA-vvpx-j8f3-3w6h, GHSA-xrjj-mj9h-534m, GHSA-4374-p667-p6c8, GHSA-69cg-p879-7622, GHSA-vvgc-356p-c3xw, GHSA-fxg5-wq6x-vr4w, GHSA-2wrh-6pvc-2jm9, GHSA-qxp5-gwg8-xv66	golang.org/x/net	go.mod (indirect)	Open	Audit-only; bump module to ≥0.38.0 (and any higher minimum required by go mod tidy).
GHSA-8r3f-844c-mc37	google.golang.org/protobuf	go.mod (indirect)	Open	Audit-only; bump to ≥1.33.0.
GHSA-6wxm-mpqj-6jpf	github.com/golang/glog	go.mod (indirect)	Open	Audit-only; bump to ≥1.2.4.
GHSA-69ch-w2m2-3vjp	golang.org/x/text	go.mod (indirect)	Open	Audit-only; bump to ≥0.3.8.
GHSA-4f99-4q7p-p3gh	github.com/sirupsen/logrus	go.mod (direct)	Open	Audit-only; bump to ≥1.8.3.

Notes

• What worked well: Input JSON and repo layout clearly tie the scanned image to the root Dockerfile and ci.yml push to ghcr.io/moolen/logistis; go.mod versions match scanner-reported module versions.
• What was difficult: This rollout is audit-only (no file edits), so registry tag listing and govulncheck could not be used to pin an exact golang:*-alpine* tag; the operator must list tags from the registry and pick a compliant patch. The finding set is large but dominated by stdlib + old Alpine — a coordinated Go + Alpine bump addresses most rows.
• Missing tooling/context: Working jq/python in the environment for automated dedupe; direct access to docker/crane/registry APIs to enumerate candidate base image tags; post-change image rescan results to confirm closure.

Human intervention requested by agent: true

Network Audit

• traffic mode: proxy
• network mode: audit
• domains observed: 3
• api2.cursor.sh attempts=13 result=allowed port=443 seen=connect
• localhost attempts=5 result=upstream_error port=80 seen=http error="dial tcp [::1]:80: connect: connection refused"
• repo42.cursor.sh attempts=13 result=allowed port=443 seen=connect

Agent Logs

cve-remediation stdout

Summary of what was done:

## Result

This rollout is **audit-only**: only **`.patchpilot/output.json`** was written (no `Dockerfile`, `go.mod`, or workflow edits).

### Findings captured in the output

- **Image/build:** `ghcr.io/moolen/logistis` is built from the repo root **`Dockerfile`** and pushed by **`.github/workflows/ci.yml`** (`docker/build-push-action`, `IMAGE_NAME: ghcr.io/moolen/logistis`). **`Makefile`** also points at that `Dockerfile`.
- **Root cause:** `golang:1.19` (stdlib **go1.19.1**), **`alpine:3.14`** (OpenSSL **1.1.1q**, old **curl**), and outdated **`go.mod`** deps (`golang.org/x/net`, `protobuf`, `glog`, `logrus`, `x/text`, etc.). **`.github/workflows/release.yml`** still uses a **Go 1.19.1** tarball for **kubectl-blame**.
- **`pr_summary`:** Operator-focused remediation (bump Go + Alpine in the same families, list registry tags instead of guessing, bump modules to the stated floors, align `release.yml`, then build/test/govulncheck/rescan).
- **`human_intervention_needed`:** **`true`** (required for this audit-only pass).
- **Fixed findings:** **None** (no code changes).
- **Unresolved:** Summarized in a **deduplicated** table (stdlib + Alpine SSL/curl + Go modules) so it is not a 120-row repeat of the same CVEs.
- **Notes:** Wrapped exactly in `<!-- patchpilot agent notes -->` … `<!-- patchpilot agent notes end -->`.

[moolen]

Agent Log Assets

• pr-8-cve-remediation.stdout.log

Network Audit

• traffic mode: proxy
• network mode: audit
• domains observed: 3
• api2.cursor.sh attempts=13 result=allowed port=443 seen=connect
• localhost attempts=5 result=upstream_error port=80 seen=http error="dial tcp [::1]:80: connect: connection refused"
• repo42.cursor.sh attempts=13 result=allowed port=443 seen=connect