How to harden container images without breaking them

To harden a container image safely, start from one scanner finding, make the smallest change that removes it, then rebuild without cache, scan the new digest again, and run the image with its production entrypoint. A coding agent can do this repository work when each step leaves evidence in the pull request.

Container image hardening removes unnecessary software and limits what a compromised workload can do. Coding agents can handle much of the repository work, but a broad instruction such as “secure this image” invites unrelated upgrades and makes the result hard to verify. A useful task starts with a specific finding and ends with a rebuilt, tested image.

Docker’s build best practices explain how base-image selection and multi-stage builds limit what reaches the runtime image. Apply the controls relevant to the finding instead of combining every possible hardening change in one patch.

Scope container image hardening from evidence

Begin with the image digest, Dockerfile path, build command, target architecture, and scanner finding. Record the affected package and the layer that introduced it. A vulnerable operating-system package may come from the base image, while an application dependency may be installed later. The repair path differs.

Give the agent an explicit boundary. It may update a base image digest, remove an unused package, split build and runtime stages, or set a non-root user. It should leave deployment configuration and unrelated application dependencies unchanged unless the finding requires them.

Each kind of change has its own way of breaking a working image. The table pairs the common hardening edits with what to check after the rebuild.

Preserve a rollback point before editing. Record the prior digest and the command that produced the current image. This allows reviewers to compare artifacts and restore the known build if runtime tests uncover a compatibility problem.

Validate the hardened container image

Rebuild without relying on a developer’s local cache, then scan the resulting digest rather than the Dockerfile alone. Confirm that the targeted finding is gone and inspect any new findings introduced by the replacement base. A smaller package count can reduce attack surface, but package count by itself does not prove that an image is secure.

Run the image with its production entrypoint and the same user, filesystem, port, and health-check assumptions used in deployment. Exercise startup, shutdown, network access, certificate loading, and any native libraries. Removing a shell or package manager may be appropriate for runtime, but only after tests show the service does not depend on it.

Make container hardening reviewable

The pull request should name the original finding, old and new image digests, changed layers, build command, scanner command, and runtime tests. Include the reason for every package removal or privilege change. Avoid pasting credentials, complete environment dumps, or private registry tokens into logs.

Reviewers need to distinguish a source fix from a scanner exception. If remediation is unavailable, document the affected component, reachability, compensating control, owner, and expiration date. An unbounded ignore rule hides future findings.

Keep the repair tied to the finding and show how the rebuilt image addresses it. Reviewers can then assess the runtime consequences without separating an unrelated application refactor from the security change.

How Factory runs container hardening work

Factory is a platform for running a software factory, where agents called Droids take work from a signal to a reviewed pull request. A scanner finding on a container image is that kind of signal, and the work after it follows the same path each time.

Run the edit in CI with Droid Exec. Droid Exec is Factory's headless mode. Each run is a single non-interactive pass that is read-only by default. --auto low allows file edits but blocks package installs and test runs, and --auto medium adds builds, tests, and local git operations. The dependency scan recipe shows a three-job layout where no credential is present while dependency or test code runs, a pattern that fits image rebuilds too.

Start from the finding. Factory Automations can start a Droid on a schedule or on a GitHub event, such as a push to a branch. Webhook triggers, which let a scanner post findings directly, are in private preview.

Review the change. Factory's security review checks the pull request against STRIDE, OWASP, and supply chain risks in two passes, candidates first and validation second. Deterministic image scanning and runtime tests stay as separate required checks because each answers a different question.

Frequently asked questions

What is container image hardening?

Container image hardening removes unnecessary software from an image and limits what a compromised workload can do. Common changes are a newer base image digest, removing unused packages, multi-stage builds, and a non-root user.

How should a coding agent scope a hardening task?

Start from a specific scanner finding with the image digest, Dockerfile path, build command, target architecture, and the layer that introduced the package. Limit the edit to what the finding requires and leave deployment configuration alone.

How do you verify a hardened image?

Rebuild without the local cache, scan the resulting digest, confirm the target finding is gone, and inspect new findings. Then run the image with its production entrypoint, user, ports, and health check.

How does Factory help with container hardening?

Droid Exec can run the bounded edit in CI with an explicit autonomy level, Automations can start the work on a schedule or GitHub event, and Factory security review checks the pull request before an owner merges it.

Further reading

• SBOM automation
• Safer dependency updates
• CVE explained
• Private AI security remediation
• Docker build best practices