AI Coding Agents
Security
Container image hardening with coding agents
September 25, 2026 - 2 minute read
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. Factory’s Droid Exec can run this bounded task non-interactively in CI and return a failing exit code when validation fails.
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.
Factory’s automated security review can inspect the code change for realistic exploit paths. Keep deterministic image scanning and runtime tests as separate required checks because each answers a different question.
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.
