## Context
Image scanner flags the `prod-twenty` server image for OpenSSL CVEs. The
image carries **two independent OpenSSL surfaces**, and they are fixed
by different levers:
| Surface | Version (before) | Used by app at runtime? | Fix lever |
|---|---|---|---|
| **Node-bundled** OpenSSL | `3.5.6` | ✅ yes (Node links its own) | Node
base bump (separate; `24.16.0-alpine3.23` is already the latest digest)
|
| **Alpine system** `libcrypto3`/`libssl3` | `3.5.6-r0` | ❌ no (`ldd
node` shows no link) | **this PR** — apk upgrade to `3.5.7-r0` |
The pinned `node:24.16.0-alpine3.23` base bakes `libcrypto3`/`libssl3`
at `3.5.6-r0`, while the Alpine v3.23 repo now ships `3.5.7-r0`. These
libs ship as deps of `apk-tools`/`libapk`/`ssl_client` (so they can't be
removed), and Node does not link them — but the scanner still flags them
by version.
## Change
Pin a patched floor (`libcrypto3>=3.5.7-r0`, `libssl3>=3.5.7-r0`) in the
`apk add` lines of both runtime stages (`twenty-server` and
`twenty-app-dev`) so apk upgrades them at build time. Same technique
already used for `curl`/`nghttp2-libs`/`postgresql18-client` (#20805).
## Verification
- Built `--target twenty-server`; image builds clean.
- On the built image, `libcrypto3` and `libssl3` resolve to `3.5.7-r0`.
- Node-bundled OpenSSL is unaffected by this change (separate surface,
no Dockerfile-side upgrade path until a newer Node release links a
patched OpenSSL).
Charles Bochet
402e4b6a78