CleanStart launches shell-less read-only containers

CleanStart has introduced a shell-less, read-only container architecture for production environments. The approach uses a new build-time init binary, clnimg-init.

The tool is designed to harden runtime behaviour without requiring changes to existing Dockerfiles, CI/CD pipelines or deployment workflows.

Container security teams have long pushed for shell-less containers and read-only filesystems because they remove common routes attackers use after an initial compromise. Yet many organisations have held back because adopting those controls often requires application teams to rewrite entry points, review initialisation scripts, remap writable paths and retest services.

That migration work can be substantial for companies running large numbers of containerised applications. CleanStart is positioning clnimg-init as a way to shift that work into the image build process instead of leaving it to developers and platform engineers.

During image creation, the binary automatically replaces traditional shell entry points. Applications continue to run as before, while the resulting production image has no shell and a read-only root filesystem.

According to CleanStart, write access is restricted to memory-backed paths required by the application. The binary also handles signal forwarding, environment validation and process lifecycle management, tasks often managed by shell entry points in container images.

For many engineering teams, the core issue is the trade-off between stronger runtime controls and the risk of disrupting software delivery. Security leaders may favour tighter restrictions, but developers often resist changes that could affect application behaviour or force updates to established pipelines.

"Every security control that asks developers to change their workflow has a ceiling. The more work it creates, the less it gets adopted, and production environments stay exposed," said Nilesh Jain, Chief Executive Officer of CleanStart. "clnimg-init removes that ceiling. The shell is gone, the filesystem is locked, and the developer did not have to touch a thing."

CleanStart says the architecture is intended to be largely invisible to developers. Customers do not need to install new tools, retrain teams or alter registry settings, Helm chart configuration or deployment patterns to adopt the hardened runtime setup.

Security trade-off

Shell access inside containers often remains available in production because it provides a familiar way to launch processes and troubleshoot systems. A writable filesystem can also simplify application behaviour. Those same features, however, can give attackers a way to execute commands or establish persistence after gaining access.

By removing the shell and limiting write access, CleanStart is targeting two areas that security practitioners often cite as central to post-compromise activity. Debugging can still be handled through its CleanSight observability tooling and through Kubernetes ephemeral debug containers, according to the company.

"A shell-less read-only container eliminates two of the most reliable post-compromise persistence mechanisms attackers depend on," said Biswajit De, Chief Technology Officer of CleanStart. "The question was never whether these controls were worth having. It was whether they were worth the migration cost. clnimg-init answers that. The cost is zero."

The new architecture has been added to CleanStart's image construction pipeline. Existing customers can adopt the hardened runtime configuration without changing Dockerfiles or deployment configuration.

CleanStart describes itself as a provider of verifiable, compliance-ready container images built through reproducible, hermetic build pipelines. The company was founded by Nilesh Jain, Vijendra Katiyar and Biswajit De.