Hardened vs Locked images

ARMORRED publishes each image in two security tiers: hardened and locked. Both tiers are built FROM scratch using Nix, signed with cosign, and shipped with full SBOMs. Both tiers apply the same maximum security posture: all binary hardening flags, CFI, LTO, SafeStack, FORTIFY_SOURCE=3, and all dependencies rebuilt with hardened compiler flags. They differ only in the tradeoff between compatibility and feature reduction.

Hardened Tier

Hardened images are guaranteed drop-in replacements for their upstream equivalents. All upstream features are retained. The security hardening is the maximum possible: CFI, LTO, SafeStack, FORTIFY_SOURCE=3, hardened dependencies, and all available binary protections.

The hardened tier is the recommended starting point for all users. Existing configurations, orchestration scripts, and deployment patterns should work without modification.

Locked Tier

Locked images apply the same maximum security hardening as the hardened tier but are not guaranteed to be 100% drop-in replacements. They additionally drop rarely-used features at compile time – such as scripting engines, optional protocol support, plugin systems, or non-essential backends – to further reduce attack surface. The specific features removed vary per image and per version.

Users should test the locked tier in a staging environment before production deployment. If your workload depends on a feature that was removed, use the hardened tier instead.

What Varies Per Image

The specific implementation details of each tier – which compilation flags are enabled, which modules are included or excluded, whether a shell is present, which coreutils are available – depend on the image and may change between builds. These are not defining properties of the tier model.

For example, in the current nginx 1.26 build:

PropertyHardenedLocked
Image size121 MB72 MB
Components19 packages20 packages
Clang CFIDisabledEnabled
SafeStackEnabledEnabled
Perl moduleIncludedExcluded
ShellAbsentPresent

These details are specific to this image and version. Other images may make different tradeoffs. Always consult the image analysis pages under Images for the exact comparison of a specific image.

Which Tier Should I Choose?

Start with Hardened if:

  • You need a guaranteed drop-in replacement with zero configuration changes
  • You cannot risk breaking any upstream functionality
  • You want to adopt ARMORRED with minimal testing effort

Use Locked if:

  • You want the most aggressive hardening posture available
  • You are willing to test and accept that some edge-case features may be absent
  • Your deployment does not depend on rarely-used features of the upstream image

Migration Path

Start with the hardened tier to confirm ARMORRED images work in your environment. Once validated, evaluate the locked tier in staging. If everything works, the locked tier provides a stronger security posture at no compatibility cost to your specific workload.

Verify which tier you are running:


$ podman inspect ghcr.io/armorred/nginx:1.26-hardened \
| jq -r '.[0].Config.Labels["org.armorred.tier"]'
hardened

$ podman inspect ghcr.io/armorred/nginx:1.26-locked \
| jq -r '.[0].Config.Labels["org.armorred.tier"]'
locked

For detailed information on what protections are applied at build time, see the Application Build-time Techniques page. For image-specific analysis including checksec results, SBOM comparisons, and vulnerability counts, see the Images section.