fix: pin alpine openssl packages in CLI image

[floreks]

Summary

• pin libssl3 and libcrypto3 in the final CLI image stage to 3.5.7-r0
• keep the remediation scoped to the confirmed remediable image-package alerts
• document why the reported Go stdlib and transitive oras.land/oras-go/v2 alerts were not changed here

Why this is safe

• the repository already uses golang:1.26.4-alpine3.22; this change only constrains the installed Alpine OpenSSL packages in that existing image family
• apk policy for Alpine 3.22 resolves both packages to 3.5.7-r0, matching the fixed version identified during discovery

Reported alerts covered

• libssl3 image-package alert: pinned to 3.5.7-r0
• libcrypto3 image-package alert: pinned to 3.5.7-r0

Remaining reported findings and blockers

• Go stdlib / toolchain findings (CVE-2024-45341, CVE-2024-45336): the repo already declares go 1.26.4 in go.mod, which is newer than the discovery-noted fixed 1.23.5+ / 1.23.6+ ranges, so no remediation edit was needed
• oras.land/oras-go/v2 / GHSA-fxhp-mv3v-67qp: the dependency is transitive via helm.sh/helm/v3 v3.21.2. Inspecting the downloaded Helm module confirmed Helm 3.21.2 still requires oras.land/oras-go/v2 v2.6.1. I could not verify a minimal newer Helm version carrying a patched ORAS version from the module proxy in this environment, so I did not guess at a parent or override update

Files changed

• Dockerfile — pin libssl3 and libcrypto3 in the final image stage

Validation

• docker run --rm alpine:3.22 sh -lc "apk update >/dev/null && apk policy libssl3 libcrypto3"
• docker build --target final -t plural-cli-security-check .

Existing PRs considered

• I attempted to list open PRs for pluralsh/plural-cli through the GitHub API from this environment, but the unauthenticated response body was empty, so I could not confirm any existing broad remediation PR covering all reported alerts

Labels

• dependencies

[floreks]

This PR was generated by the codex Plural Agent Runtime. Here's some useful information you might want to know to evaluate the ai's perfomance:

Name	Details
💬 Prompt	Repository: pluralsh/plural-cli...
🔗 Run history	View run history

[greptile-apps]

Greptile Summary

This PR pins libssl3 and libcrypto3 to 3.5.7-r0 in the final CLI image stage to remediate confirmed image-package vulnerability alerts, while leaving the builder stage and Go-level findings untouched.

• Only the final stage is modified; the builder stage is unchanged since the Go binary is compiled with CGO_ENABLED=0 and does not dynamically link OpenSSL.
• The hard-pinned version (=3.5.7-r0) validated against the current Alpine 3.22 mirror will cause build failures whenever Alpine publishes a newer patch release (e.g. 3.5.7-r1), as old package versions are removed from mirrors; the floating base-image tag compounds this risk.

Confidence Score: 4/5

Safe to merge as a targeted security remediation; the only concern is future build fragility from the hard-pinned package version.

The change is a single-line security pin validated against the current Alpine 3.22 repository. The one forward-looking concern — hard-pinning an Alpine package version that will be removed from mirrors when Alpine releases its next patch — doesn't break anything today but will silently break CI on the next Alpine OpenSSL patchlevel bump unless the pin is also updated then.

Dockerfile line 38 — the hard-pinned libssl3 and libcrypto3 versions will need updating whenever Alpine ships a patch release for those packages.

Important Files Changed

Filename	Overview
Dockerfile	Pins libssl3 and libcrypto3 to 3.5.7-r0 in the final runtime stage to remediate image-package CVE alerts; builder stage is unmodified.

_{Reviews (1): Last reviewed commit: "fix(security): pin alpine openssl packag..." | Re-trigger Greptile}

[greptile-apps]

Hard-pinned version will break builds on the next Alpine patch

apk update fetches the latest Alpine 3.22 package index, which only retains the current version of each package. As soon as Alpine ships libssl3=3.5.7-r1 (or any higher patchlevel), 3.5.7-r0 is removed from every mirror and this layer will fail with "version constraint not satisfiable." Because the base image tag golang:1.26.4-alpine3.22 is also floating, a routine base-image rebuild after that Alpine update will break CI without any change to this Dockerfile.

A common mitigation is to pair the version pin with a pinned base-image digest (golang:1.26.4-alpine3.22@sha256:…) so the build is fully reproducible, or to plan for a Dependabot/Renovate rule that bumps the version pin whenever Alpine publishes a patch release.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!