Container build-time techniques

Building from scratch means the container image starts as an empty filesystem. No distribution base layer. No package manager. No shell. Nothing except what the build process explicitly places into the image.

Traditional Dockerfile pattern:

FROM debian:12
RUN apt-get update && apt-get install -y nginx
...

ARMORRED pattern with Nix:

FROM scratch
COPY /nix/store/.../nginx /nix/store/.../nginx
COPY /nix/store/.../glibc /nix/store/.../glibc
COPY /nix/store/.../openssl /nix/store/.../openssl
...

Nix computes the transitive closure of dependencies required for nginx to execute and copies only those exact paths into the container. The result is a minimal, reproducible image with zero inherited components.

The difference between base-image inheritance and scratch-based builds is substantial. For nginx 1.26:

Component breakdown:

Fewer components means:

• Reduced attack surface: fewer binaries and libraries that could contain vulnerabilities
• Faster vulnerability scanning: fewer components to correlate against CVE databases
• Simplified incident response: smaller SBOM makes impact assessment faster
• Smaller supply chain risk: fewer dependencies means fewer upstream sources to trust

Minimal component sets produce significantly smaller images. For nginx 1.26:

Smaller images provide operational benefits:

• Faster pull times in CI/CD pipelines and during deployments
• Reduced storage costs in registries and local caches
• Lower network transfer costs
• Faster horizontal scaling as new pods pull images

The locked tier achieves greater size reduction by removing optional nginx modules and debug symbols while retaining functionality.

Fewer components dramatically reduces vulnerability exposure. Upstream nginx 1.26 inherits vulnerabilities from the Debian base image:

Vulnerability reduction: 99.1%

The single remaining HIGH vulnerability (OSV-2021-777 in libxml2) is a low-probability heap-use-after-free discovered through fuzzing that has no known exploit and no upstream fix. ARMORRED retains libxml2 because nginx uses it for XSLT transformations.

All critical and medium vulnerabilities exist in packages that nginx does not use (perl, libtiff, libexpat, libwebp, etc.) and are eliminated by not including them in the scratch-based build.

Whether shell binaries are present in an ARMORRED image is an implementation detail that varies per image and build, not a defining property of the tier. Some images may include a shell in one tier but not the other; others may include or exclude it in both.

When a shell is absent, it eliminates entire classes of attacks:

• Command injection vulnerabilities cannot execute shell commands
• Container escape exploits that rely on sh or bash for post-exploitation fail
• Attackers who achieve code execution cannot spawn an interactive shell
• kubectl exec and podman exec cannot provide shell access

When a shell is present, it supports operational workflows, health check scripts, and debugging.

As an example, the current nginx 1.26 build:

Always check the specific image's analysis page under Images for the exact shell availability of the image you are deploying.

When a shell is absent, use HTTP-based health checks rather than exec-based probes:

ARMORRED images run as non-root by default. The application binary executes as UID 65534 (nobody) with no elevated privileges.

Verify non-root execution:

Running as non-root:

• Prevents privilege escalation exploits from immediately gaining root
• Limits the scope of filesystem access if the container is compromised
• Aligns with the principle of least privilege
• Satisfies pod security standards that prohibit root containers

Applications that require binding to privileged ports (<1024) must use Linux capabilities rather than running as root.

ARMORRED images are designed to run with a read-only root filesystem. All writable state (logs, temporary files, application data) is directed to mounted volumes.

Example podman run with read-only root:

Read-only root filesystems:

• Prevent attackers from modifying binaries, libraries, or configuration after container start
• Prevent persistence mechanisms such as cron jobs, SSH keys, or backdoors
• Make containers immutable and cattle rather than pets
• Align with the principle of immutable infrastructure

ARMORRED images include standardized OCI labels documenting the build:

These labels enable:

• Automated detection of ARMORRED images in runtime environments
• Policy enforcement based on org.armorred.tier value
• Traceability back to the build process via org.opencontainers.image.description
• Version identification for automated update workflows

Container build-time hardening provides foundational security through attack surface reduction. The following table uses nginx 1.26 as an example:

Specific details (shell availability, exact component lists, module inclusion) vary per image. Consult the Images section for per-image analysis.

These container-level protections work in combination with application build-time hardening and runtime protections to provide defense-in-depth.