[haukened]

Name of feature:

Not really a feature - this is a vulnerability cleanup for the step-ca Docker images. Nothing changes in how the image works.

Pain or issue this feature alleviates:

Hey folks! We scan everything we pull with JFrog Xray, and smallstep/step-ca:0.30.2 came back with 231 findings (36 critical, 112 high). None of it is in your code. I dug in to figure out where it was actually coming from, and it turned out to be mostly an image freshness problem, not a code problem:

• Alpine packages (124 findings). The runtime stage builds FROM smallstep/step-cli:latest, and that image only gets rebuilt when the CLI ships. Anything Alpine patched since then rides along unpatched. The step-cli Dockerfile already runs apk upgrade, but step-ca doesn't, so it inherits whatever was stale.
• Go toolchain (52). 0.30.2 was built with Go 1.26.1 back in March. The builder uses golang:alpine, so a rebuild picks up current Go on its own. Nothing to change there.
• Go modules (55). Dependabot already fixed nearly all of these on master. The one it missed is pgx, probably because it's indirect.

So this PR does two small things:

1. Runs apk upgrade --no-cache in the runtime stage of docker/Dockerfile (and apt-get upgrade -y in Dockerfile.hsm), same as the step-cli Dockerfiles already do.
2. Bumps github.com/jackc/pgx/v5 from v5.9.2 to v5.12.0. That fixes GHSA-j38q-h3ph-jjpq (SQL injection in simple-protocol batches) and GHSA-95fj-3fxw-g62g (a require_auth / channel_binding bypass that hits 5.9.0 through 5.11.0). I went with 5.12.0 instead of 5.13.0 on purpose - 5.13 changes how client certs get loaded, and that felt like something you'd want to look at on its own.

Why is this important to the project (if not answered above):

Here's where things land with this branch, built on top of the matching cli and step-kms-plugin branches:

	0.30.2 (published)	this branch
Trivy - OS packages	225	0
Trivy - Go binaries	282	3 (see below)
Grype	453	3 (see below)
Xray export	231	4 left, none of them fixable by a version bump

For the Xray row I took every finding in the export and checked it against what's actually installed in the rebuilt image, using Xray's own affected-version ranges. 227 of the 231 clear. 9 of those are only gone because you already moved to go-jose v4 in cddde30a - credit where it's due. The 4 that are left are scanner data issues:

• CVE-2026-119566 is filed against prometheus/common, but it's actually a Prometheus server bug. No version of the library will ever clear it.
• CVE-2026-4738 is GDAL's bundled copy of zlib, not system zlib.
• CVE-2026-85091 (zlib) and CVE-2026-33630 (c-ares) have no version range in Xray's data. The image has zlib 1.4 and c-ares 1.34.9, both past the affected versions.

Two things I left alone on purpose:

• The x/crypto/openpgp deprecation notice (GO-2026-5932). It's the 3 Trivy hits above, once per binary. Nothing imports openpgp, and govulncheck agrees it's never called. The only "fix" is x/crypto v0.59.0, but that release drops DSA from x/crypto/ssh and rejects SSH certs with no principals. step ssh fingerprint on an ssh-dss key works today and breaks on 0.59.0, and 21 tests across authority and authority/provisioner fail because two test fixtures sign certs without principals. That's your call to make, not mine to sneak into a "security fixes" PR. Dependabot will bring it to you anyway.
• busybox CVE-2025-60876 only shows up in Grype, as an NVD name match. Alpine doesn't list it and there's no fixed busybox.

The part I think matters most: release order. This image copies step from step-cli:latest and step-kms-plugin from step-kms-plugin:cloud. If step-ca goes out at the end of November before those two release, I measured 82 of the Xray findings still being in there (10 critical, 40 high), all in those two binaries. For a clean image the order would be:

1. a cli release (with Bump github.com/jackc/pgx/v5 to v5.12.0 cli#1737)
2. a step-kms-plugin release (Upgrade OS packages in Docker images step-kms-plugin#390 for the images, but main's already clean - the last release was v0.17.0 back in April, and that's what step-ca bundles today)
3. then step-ca

Is there documentation on how to use this feature? If so, where?

N/A - nothing user-facing changes. Same entrypoint, CMD, healthcheck, step user (uid 1000), volumes, packages and platforms.

In what environments or workflows is this feature supported?

I didn't want to break prod for anyone, so I tested it pretty hard against the published 0.30.2 as a baseline:

• First-run setup via DOCKER_STEPCA_INIT_* (with ACME and SSH): goes healthy, prints the admin password once, shreds it, creates the same provisioners
• Issuing certs with step ca certificate, and step ca health
• Binding :443 as the non-root step user (so the file capability survives)
• step kms through the bundled plugin
• Postgres backend on pgx 5.12.0 against a real postgres:17: same 24 tables, issue and revoke both land in the DB
• The -hsm image, same checks, with pcscd starting from the entrypoint
• linux/386 as well as amd64

I also ran your CI locally on Go 1.26 and 1.27: golangci-lint with your shared config, the go generate and go mod tidy checks, govulncheck, make test (including the TPM simulator tests), make build, and CodeQL with the security-and-quality suite. Everything passes, and CodeQL comes back with the exact same results as master.

In what environments or workflows is this feature explicitly NOT supported (if any)?

Nothing new is unsupported. I couldn't build arm64 or arm/v7 locally, but the package and module versions are the same across architectures. The -hsm image still has about 470 Debian findings after the upgrade, but every one of them is affected or fix_deferred on Debian's side, so there's nothing to upgrade to yet.

Supporting links/other PRs/issues:

• Companion PRs: Bump github.com/jackc/pgx/v5 to v5.12.0 cli#1737 (pgx bump), Upgrade OS packages in Docker images step-kms-plugin#390 (same OS package upgrade)
• pgx advisories: GHSA-j38q-h3ph-jjpq, GHSA-95fj-3fxw-g62g
• The x/crypto changes I held back: golang/crypto@96c6cf4 and golang/crypto@8483352 (empty principals), golang/crypto@a1058eb (DSA removal)

Happy to adjust any of this - totally understand if you'd rather fold it into your own base image work.