How should security teams build minimal Docker containers for security tooling without carrying unnecessary build dependencies into production images?

Use a multi-stage build. Compile or fetch the tool in a builder stage, then copy only the finished binary into a slim runtime image. This keeps build-time packages, source trees, and caches out of the final container, which reduces image size, speeds deployment, and lowers the attack surface of tooling used in security operations.

Why multi-stage builds are the right pattern for security tooling

Security tooling often needs compilers, package managers, headers, and test utilities during build time, but those same dependencies are usually unnecessary, and sometimes risky, in production. A multi-stage build cleanly separates “create the tool” from “run the tool,” so the final image contains only what is needed to execute the binary and nothing that expands the operational blast radius.

That separation matters because container images are part of your attack surface. A smaller runtime image is easier to inspect, faster to patch, and less likely to contain stray files, build caches, or debug utilities that an attacker could abuse. It also makes the image easier to reason about when the container is used in security operations rather than as an application host.

For teams building security utilities, the practical benefit is that the builder stage can be permissive while the runtime stage stays narrow. The build stage can use full language toolchains, signing tools, and dependency managers, while the final stage should inherit only the compiled artifact and the minimum runtime libraries required by that artifact. When the tool is statically linked, the runtime image can often be reduced even further.

What belongs in the builder stage, and what must stay out of production

The builder stage is where you fetch source, resolve dependencies, compile code, and run tests. That is the right place for package indexes, source trees, temporary objects, and cache directories because they help produce a trustworthy artifact but do not help operate it. If the tool is pulled from an upstream release rather than compiled, the same logic applies: verify it in a build stage, then copy only the verified output into the runtime stage.

The production image should contain the executable, required runtime libraries, and any narrowly scoped configuration or trust material the tool genuinely needs. It should not contain compilers, shells, package managers, VCS metadata, or leftover archives. The cleaner the handoff between stages, the less chance there is of accidentally shipping a dependency tree that is irrelevant to execution and useful to an attacker.

Teams often underestimate how much “temporary” build material survives when Dockerfiles are written for convenience. Layered filesystems do not forgive sloppy cleanup inside a single stage, and they certainly do not help when the final image is copied from the wrong stage. For security tooling, the safest default is to treat the runtime image as a release artifact, not a development environment.

Risk and Threat Considerations

When build dependencies leak into the final image, the container becomes easier to tamper with and harder to defend. Extra utilities can support post-compromise activity, while extra packages and caches increase the likelihood of inherited vulnerabilities, secret residue, and configuration drift across environments.

Failure mechanism: A rushed Dockerfile copies the whole build context, or reuses the build stage as the runtime stage, leaving compilers, package managers, source code, and caches inside production images. That widens the attack surface and can expose sensitive build-time material if the image is inspected or compromised.

Impact: The image becomes larger, slower to distribute, and more expensive to patch, but the more serious issue is control failure: security tooling should be minimally trusted by default, and unnecessary build dependencies undermine that objective.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 4 — Secure Configuration of Enterprise Assets and Software	Minimal runtime images reduce unnecessary software exposure.
	CIS 16 — Application Software Security	Build-stage separation supports safer software release artifacts.
Recommendation — Strip build tools from production images and keep only required runtime packages. Use build pipelines that produce clean release artifacts for deployment.
NIST CSF 2.0	PR.DS — Data Security	Keeping build files and caches out of runtime images limits unintended exposure.
	PR.IP — Information Protection Processes and Procedures	Multi-stage builds are a repeatable process for producing hardened images.
Recommendation — Minimize exposed build artifacts and sensitive files in deployed containers. Standardize multi-stage builds as the default container packaging pattern.

Practitioner Guidance

What to verify: Confirm that the final image contains only the binary, its required shared libraries, and the minimal OS packages needed to run it. If package managers, shells, compilers, or source directories appear in the runtime image, the build is not yet minimal enough.

Common mistake: Copying the entire build filesystem, or using a “slim” base image while still inheriting build artifacts from the wrong stage, gives a false sense of hardening. Minimal size is useful, but minimal content is the real control objective.

What good looks like: The runtime image is reproducible, small enough to inspect quickly, and stable across rebuilds because it contains only the release artifact and explicitly justified runtime dependencies.

Practitioner takeaway: Build containers as if the final image will be treated like a production security boundary, because for security tooling, it effectively is.