ClearCutt
Hardened Image Blueprint
Operational boundaries & threat model constraints

Project Limitations & Boundaries

ClearCutt establishes trust through inspectable evidence. To help platform and security teams make informed engineering decisions, we explicitly document the constraints, operational boundaries, and trade-offs of our container hardening blueprint.

The Hard Truth of Container Security

No container runtime or base image is completely immune to security risks. True supply chain protection comes from verifying every claim yourself. ClearCutt provides the tools and blueprint so your team does not have to trust our assertions blindly.

Base OS Overlay & Bit Reproducibility

The Nix store closures generated by ClearCutt are bit-for-bit reproducible inside the Nix ecosystem. However, when these Nix layers are grafted/layered onto an arbitrary non-Nix base image (e.g. Red Hat UBI, Amazon Linux, or Ubuntu Pro), bit-for-bit reproducibility of the final OCI manifest is broken due to non-deterministic base OS filesystem configurations, file timestamps, and package manager updates.

Nix RPATH & Path Leakage

ClearCutt relies on Nix's RPATH configuration to isolate dynamic libraries from standard system directories. However, if your application runs inside a mixed environment or dynamically executes binaries that make hardcoded queries to `/lib64` or `/usr/lib`, it may inadvertently load dynamic libraries from the host OS, bypassing Nix runtime isolation entirely.

macOS Compilation Constraints

Nix developer shells can be executed on macOS for local inspection, verification, and orchestration. However, compilation of Linux OCI container layers cannot happen natively on macOS architecture. Cross-compilation to Linux matrices requires running either a native Linux build host, or provisioning a Linux VM/Docker backend linked to the macOS Nix daemon.

VEX, Shells, & RCE Mitigation

Removing shells (distroless) successfully mitigates typical exec() shell escapes and simple script injection attacks. However, it does not prevent direct interpreter exploits (e.g., executing arbitrary Python/Node code via standard dynamic evaluation endpoints in your app), nor does it prevent memory corruption vulnerabilities inside statically linked application binaries.

Nix Multi-Layering Overhead

To maximize dependency reuse and minimize download size in typical pipelines, Nix compiles applications into fine-grained store layers (often totaling 50 to 100 layers). While highly cache-efficient, this extreme layering introduces metadata download latency and manifest parsing overhead in air-gapped or cold-start Kubernetes clusters.

Credential Broker exposure

Our transient build-time credential helper mounts bootstrap credentials into environment variables during compilation. While ephemeral, this configuration creates potential risk if host process structures or /proc isolation boundaries are compromised, making environment blocks readable by other processes on the build node.

Admission Gating fail-closed risks

Enforcing fail-closed admission policies (using Kyverno or OPA Gatekeeper) blocks unsigned or altered containers. However, this introduces serious operational risks: if your admission webhook controller encounters outages, all deployment activities in the cluster will fail, even if the target container manifests are completely valid.

OpenShift SCC & Host-Group Exposure

Many enterprise systems (such as OpenShift) enforce strict Security Context Constraints (SCC) requiring runtimes to execute under high-UID random allocations, but default to root group permission (`runAsGroup: 0`). While standard in the distroless space, this permission makes files and directories writable by the root group, which can expose host mounts if misconfigured.

For the full, extensive discussion on our architecture decisions, see the Architectural Decisions Log (ADR) in the core codebase.