Executive Summary

Two of the most reliable post-compromise techniques attackers use inside a container are shell execution and filesystem persistence. Removing the shell and making the root filesystem read-only closes both. Security teams have wanted this configuration for years. The reason production environments rarely have it is migration cost: rewriting Dockerfile entrypoints, auditing init scripts, remapping writable paths, and retesting pipelines across dozens of services turns into weeks of engineering time that stalls the initiative before it ships.

CleanStart's approach removes that cost. A statically compiled init binary, clnimg-init, replaces the shell entrypoint automatically during image build. The Dockerfile stays the same, the CI/CD pipeline stays the same, and the deployment process stays the same. What changes is what runs inside the container: no shell, a read-only root filesystem, and write access restricted to memory-backed paths the application explicitly needs. clnimg-init handles signal forwarding, environment validation, and process lifecycle management, which is everything a shell entrypoint traditionally provided, without exposing a shell an attacker can pivot into.