A platform team at a defense contractor spends six weeks migrating its build pipeline from Red Hat UBI base images to Chainguard's distroless images, cutting its median image CVE count from 47 to 0 almost overnight. Then it hits Iron Bank onboarding. The Anchore Enterprise scan the team has relied on for two years to generate DISA STIG checklists comes back with dozens of "unable to evaluate" and "open" findings — not because the image is insecure, but because there is no shell, no rpm database, and no /bin/sh for the scanner to exec into. The image that is objectively the most hardened one the team has ever shipped looks, on paper, the least compliant. This is now a routine failure mode as federal and regulated teams adopt minimal, distroless images while their compliance tooling still assumes a full Linux userland underneath.
What does "STIG compliance" actually mean for a container image?
STIG compliance means an image's configuration and packages satisfy the checks published in DISA's Security Technical Implementation Guides, most relevantly the Container Platform SRG and the Kubernetes STIG (currently V2R2, released October 2023, with 105 individual findings). These guides originated for full operating systems — the RHEL 8 STIG alone carries roughly 230 checks covering everything from password complexity to auditd rules — and DoD's Container Hardening Guide adapted a subset of that logic for container images and the platforms that run them. Iron Bank, the DoD's centralized hardened-container repository operated under Platform One, requires every image to pass a hardening pipeline that includes CIS Docker Benchmark controls and STIG-derived checks before it can be labeled "Approved" and consumed downstream by mission systems. For any vendor selling into federal or defense-adjacent markets, "STIG compliant" is not a marketing phrase — it is a literal gate in front of an Authority to Operate (ATO).
Why do traditional scanners like Anchore struggle with hardened Chainguard images?
Anchore's STIG and compliance tooling was built around the assumption that a container is a lightweight VM: it has a package manager, a shell, and a filesystem layout SCAP content can walk. Anchore Enterprise's compliance policy packs, and the OpenSCAP and SCC-based workflows many federal teams pair with it, evaluate rules by querying rpm/dpkg databases, reading config files like /etc/pam.d or /etc/ssh/sshd_config, or in some deployment modes actually executing commands inside a running container. Chainguard images, and Safeguard's own hardened base images, are built on Wolfi and deliberately strip all of that out: no shell, no package manager, no compiler, often no /etc/passwd beyond a single non-root entry. That is precisely what drives Chainguard's images to publish near-zero known CVEs — Chainguard's own dashboards routinely show 0 CVEs across its Python, Node, and Go base images versus dozens on the equivalent Debian-slim or Ubuntu images. But a scanner that can't find /bin/bash to check its permissions doesn't conclude "not applicable" — it throws an error, and that error gets recorded as an open finding in the checklist Anchore hands to an Authorizing Official.
How many STIG controls are even applicable to a minimal image?
In practice, somewhere between 55% and 70% of a full-OS STIG's checks don't apply to a distroless or Wolfi-based image at all, and the remaining ones require re-mapping rather than re-running the original check logic. Take the Docker Enterprise 2.x STIG (V2R7): of its roughly 200 findings, a large share govern daemon-level configuration (Docker socket permissions, TLS on the daemon API, live-restore settings) that belong to the runtime, not the image. Of the checks that are image-scoped, several assume the presence of things a minimal image never ships — cron, telnet clients, setuid compilers, default shells for service accounts. When those components are absent by design, the correct compliance answer is "Not Applicable," not "Open." Anchore's default policy bundles were written for RHEL- and Debian-family images and don't ship an N/A determination path for "component absent because the image is distroless" — so teams either manually annotate dozens of exceptions per image, per release, or they inherit a permanently red compliance dashboard that nobody trusts enough to act on.
What happens when this mismatch reaches an ATO review?
It produces exactly the outcome that should never happen in a compliance program: a false negative that looks like a false positive to the reviewer. A December 2023 Platform One community discussion on Iron Bank onboarding for distroless images is a good real-world example — teams reported that images passing every actual security bar (no known CVEs, minimal attack surface, non-root by default) were stuck in review queues because automated STIG checklists returned unresolved or inapplicable-but-unmarked findings that an Authorizing Official's staff had to manually adjudicate line by line. Each manually adjudicated finding adds review cycles measured in days, and a checklist with 40+ ambiguous findings instead of 5 explained N/As can add weeks to an ATO timeline. The security posture didn't get worse; the paperwork got slower, which in a compliance-driven procurement process is functionally the same as failing.
Does switching to Chainguard mean giving up STIG evidence entirely?
No — it means the evidence has to be generated differently, from the SBOM and build provenance rather than from live shell execution inside the image. Every Chainguard and Wolfi-based image ships a complete SBOM (in SPDX or CycloneDX) at build time that enumerates every package, version, and file present. STIG and CIS controls can be evaluated statically against that SBOM and the image's declared configuration (entrypoint, user, exposed ports, layer metadata) without ever needing to exec a command. A control like "the container must not run as root" is answerable from the image manifest's USER directive alone; "the container must not contain a compiler" is answerable from the SBOM package list alone. Neither requires a shell. The gap isn't a security gap in the image — it's a methodology gap in scanners still wired for exec-based OpenSCAP-style evaluation.
How Safeguard Helps
Safeguard's compliance engine was built for this exact transition, treating minimal and distroless images as the default case rather than an edge case. Instead of falling back to exec-based checks, Safeguard evaluates STIG and CIS controls directly against SBOM data, image manifests, and build attestations, so a Chainguard or Wolfi-based image gets an accurate "Not Applicable" determination — with the reasoning attached — for every control that doesn't apply to a shell-less, package-manager-less image, instead of an unresolved "Open" finding. That reasoning ships as machine-readable justification alongside each result, so a security team preparing an Iron Bank submission or an ATO package hands reviewers a checklist that's already adjudicated rather than one that needs 40 manual exceptions written by hand.
Safeguard also tracks the same image across its full lifecycle: when a Chainguard base image is rebuilt (Chainguard rebuilds most of its catalog daily), Safeguard re-evaluates the STIG mapping automatically and flags any control whose applicability changed, rather than requiring a manual re-audit on every rebuild. For teams migrating off Anchore-driven pipelines, Safeguard imports existing STIG checklists and maps prior "Open" findings against distroless images to their correct N/A status in bulk, so a backlog of stale findings doesn't have to be re-litigated one Iron Bank ticket at a time. The result is a compliance posture that reflects what the image actually is — the most hardened option available — instead of what a shell-dependent scanner assumes it should look like.