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 recommend trusted base images, small build contexts, multi-stage builds, pinned dependencies where appropriate, and regular rebuilds. Those controls give an agent concrete constraints instead of an open-ended cleanup goal.
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 image hardening changes small. One measured risk, one reproducible rebuild, and one evidence set are easier to approve than a combined base-image migration and application refactor.
