Methodology
ARMORRED employs a systematic approach to building security-hardened container images with complete transparency into the hardening process. Every image is built from source using reproducible builds, scanned with industry-standard tools, and signed cryptographically. The methodology ensures that users can verify what protections are applied, audit the changes made, and trust the supply chain.
Build Pipeline
ARMORRED images are built using NixOS, a purely functional package manager that enables fully reproducible builds. Unlike traditional container builds that inherit uncertainty from base images and package repositories, Nix builds are deterministic and reproducible from source.
Reproducible Builds from Scratch
Each ARMORRED image is built FROM scratch rather than inheriting from Debian, Alpine, or other distribution base images. This eliminates inherited vulnerabilities and reduces the attack surface to only the components explicitly required for the application to function.
The Nix build process:
- Declares all dependencies explicitly with cryptographic hashes
- Compiles software from source with hardening flags enabled
- Produces bit-for-bit reproducible artifacts
- Creates minimal filesystem hierarchies containing only required components
- Generates OCI-compliant container images
This approach aligns with SLSA (Supply-chain Levels for Software Artifacts) Level 3 requirements for build platform integrity and reproducibility.1
Hardening Compilation
During the build phase, C/C++ software is compiled with comprehensive hardening flags:
| Flag | Purpose |
|---|---|
-fstack-protector-strong | Stack canary protection against buffer overflows |
-fPIE -pie | Position Independent Executable for ASLR |
-Wl,-z,relro,-z,now | Full RELRO (Read-Only Relocations) |
-D_FORTIFY_SOURCE=2 | Fortified libc functions with runtime bounds checking |
-fsanitize=safe-stack | SafeStack separation of safe and unsafe stack objects |
-fsanitize=cfi | Control Flow Integrity (locked tier only) |
These flags are applied systematically across all compiled components, providing defense-in-depth against memory corruption vulnerabilities.
Scanning and Analysis
Each built image undergoes comprehensive security analysis before publication. The scanning pipeline uses open source tools maintained by Anchore, OWASP, and the security community.
SBOM Generation with Syft
Syft analyzes the container image and generates a complete Software Bill of Materials in CycloneDX 1.6 format:
Syft identifies all packages, libraries, and dependencies with their versions, package URLs (purls), and cryptographic checksums. The SBOM enables vulnerability correlation, license compliance verification, and incident response.2
Vulnerability Scanning with Grype
Grype consumes the generated SBOM and cross-references components against multiple vulnerability databases:
Vulnerability sources include:
- National Vulnerability Database (NVD)
- GitHub Security Advisories
- OSV (Open Source Vulnerabilities)
- Vendor-specific security feeds
This multi-source approach reduces false negatives by ensuring coverage across ecosystems.
Binary Security Analysis with checksec
The checksec tool verifies that compiled binaries have hardening features enabled:
checksec output confirms the presence of:
- Full RELRO: prevents GOT (Global Offset Table) overwrite attacks
- Stack canaries: detects buffer overflows before exploitation
- NX (No eXecute): prevents code execution on the stack
- PIE: enables ASLR for the executable itself
For advanced hardening, checksec also detects SafeStack and Control Flow Integrity when enabled (locked tier).
Dual-SBOM Comparison
ARMORRED provides transparency into the hardening process by generating SBOMs for both the hardened image and the upstream reference image. This dual-SBOM approach enables users to audit exactly what changed during hardening.
Upstream SBOM
The upstream SBOM documents the official container image from Docker Hub or the vendor's registry as it exists before ARMORRED modifications:
Comparison Metrics
The build pipeline calculates reduction metrics by comparing the hardened image against upstream:
| Metric | Calculation |
|---|---|
| Size reduction | (upstream_bytes - armorred_bytes) / upstream_bytes |
| Component reduction | (upstream_packages - armorred_packages) / upstream_packages |
| Vulnerability reduction | (upstream_vulns - armorred_vulns) / upstream_vulns |
For nginx 1.26, the hardened tier achieves:
- 38.5% size reduction (196 MB to 121 MB)
- 87.3% component reduction (150 to 19 packages)
- 99.1% vulnerability reduction (117 to 1 CVE)
The locked tier achieves even greater reductions:
- 63.1% size reduction (196 MB to 72 MB)
- 86.7% component reduction (150 to 20 packages)
- 99.1% vulnerability reduction (117 to 1 CVE)
Cryptographic Signing
After building and scanning, images are signed using Sigstore cosign.3 This provides:
- Authenticity: Images are cryptographically bound to the ARMORRED project
- Integrity: Any tampering after signing is detected during verification
- Verification: Users verify signatures using the public key published at
https://armorred.org/cosign.pub
The signing process integrates with the container registry to attach signatures as OCI artifacts alongside the image:
Users verify signatures before deployment using the public key:
Continuous Monitoring
Images are rescanned daily against updated vulnerability databases. When new CVEs are published:
- The scanning pipeline automatically detects affected components
- Impact assessment determines if the vulnerability is exploitable in the ARMORRED context
- If exploitable, a new hardened build is published within 24 hours
- Users are notified through GitHub releases and security advisories
This continuous monitoring ensures that ARMORRED images remain protected against emerging threats.
References
SLSA (Supply-chain Levels for Software Artifacts). https://slsa.dev/spec/v1.0/
Anchore. "Syft SBOM Generator." https://github.com/anchore/syft
Sigstore. "Cosign: Container Signing." https://docs.sigstore.dev/signing/overview/