Another week, another "modern" data tool shipping a container image that looks like it was assembled by a distracted intern with a vendetta against security teams. I'm dealing with OpenClaw, the latest "streaming-first transformation layer" everyone's suddenly mandating. Their official docker image, `openclaw/transformer:latest`, is tripping every critical CVE alarm in our internal compliance scan. We run a fairly standard Twistlock setup, but I'd expect similar results from any decent scanner.
The usual suspects are all present and accounted for: glibc vulnerabilities from two years ago, a handful of high-severity openssl issues, and what looks like an entire abandoned zoo of outdated system packages in the base layer. The Dockerfile they publish is a masterpiece of negligence—multi-stage build that somehow still pulls in a full debian:buster-slim base for the final image, then runs a package manager update as a single layer, which of course does nothing to actually fix the pinned versions of libraries from the earlier `apt-get install` commands.
Here's the offending section from their public Dockerfile:
```dockerfile
FROM debian:buster-slim as builder
# ... build steps ...
FROM debian:buster-slim
RUN apt-get update && apt-get upgrade -y
COPY --from=builder /app /app
# ... more steps ...
```
That `upgrade` is a cosmetic pacifier. It doesn't pin versions, so the cache from the builder stage's `apt-get install` is immutable and full of known-bad packages. The final image is a fossil.
I've tried the obvious: pinning our own internal build to a newer base like `debian:bullseye-slim` and rebuilding from source. That works, but it breaks their poorly designed health check script which has hard-coded paths dependent on their specific build environment. Now I'm maintaining a fork just to get a clean image, which defeats the purpose of using an "official" container.
Before I sink more time into this, has anyone else navigated this particular swamp? I need a path that doesn't involve:
* Convincing our compliance team to ignore CVEs (they rightly won't)
* Maintaining a full fork of the project's build toolchain
* Waiting for the OpenClaw maintainers to fix it (their GitHub issue on this is six months old)
Specifically:
* Are there any known, maintained third-party images for OpenClaw that are actually built with security in mind?
* Has anyone successfully lobbied the upstream project with a working, secure Dockerfile patch they might accept?
* Is there a viable strategy using Docker `--security-opt` or seccomp profiles to mitigate the risks of the known vulns in glibc and openssl for a container that primarily does JSON transformation?
I'm looking for concrete configs or proven forks, not philosophical debates about container security. Our pipeline runs on a hardened Kubernetes cluster, but the compliance scan is a hard gate.