Container security in regulated environments is not just about passing a scan. It is about proving which controls belong to the image, which are inherited from the host and orchestrator, and which evidence an auditor will actually accept. Most teams discover quickly that there is no single “container STIG” to implement. Instead, compliance depends on stitching together multiple DISA artifacts, correctly validating inheritance, and turning STIG hardening into a repeatable build-and-attestation process rather than a quarterly remediation project.
This guide explains how STIG hardening works for container images in practice, which controls genuinely apply at the image layer, where OpenSCAP and signed attestations fit into the pipeline, and how regulated teams operationalize continuous compliance across FedRAMP and DoD environments.
A STIG, or Security Technical Implementation Guide, is a DISA-published configuration standard that converts NIST SP 800-53 controls into technology-specific, machine-readable rules. Containers complicate the picture, because no DISA-published container STIG exists. Regulated teams have to assemble the equivalent from four overlapping DISA artifacts and then defend the assembly in front of a 3PAO.
This guide explains how regulated teams can approach STIG hardening for container images, including control inheritance, image-level evidence, OpenSCAP validation, signed attestations, and admission-policy enforcement. The four phases below cover the full program: requirements, inheritance, image-level application, and validation.
A STIG is a DISA-published configuration standard that converts NIST SP 800-53 controls into technology-specific, machine-readable rules. For containerized environments, no DISA-published container STIG exists. DISA instead governs containers through the Container Platform SRG, the GPOS SRG, the Kubernetes STIG, and the DoD Container Hardening Process Guide v1.2.
SRG vs. STIG. A Security Requirements Guide (SRG) is a high-level, technology-neutral set of security requirements derived from NIST SP 800-53 (for example, the General Purpose Operating System SRG). A Security Technical Implementation Guide (STIG) is the technology-specific, machine-readable XCCDF implementation of an SRG (for example, the Red Hat Enterprise Linux 9 STIG). SRGs say what; STIGs say how.
DISA assigns every finding a severity category that drives remediation expectations.
Source: DISA Severity Category Codes (per the DISA STIGs library, accessed April 2026) and Anchore's "DISA STIG Compliance Requirements Explained" pillar (May 2025).
The four DISA artifacts that govern container hardening, with current CY2026 versions and finding counts:
Sources: stigviewer.com (April 2026 snapshot), public.cyber.mil/stigs, and the DoD DevSecOps PDF library at dl.dod.cyber.mil.
Three artifacts surface in older guidance and audit packs and should be ignored in CY2026:
The image plane is where hardened container images collapse most of the four-artifact picture into a build-time property. The next section explains why.
Most STIG controls scanned against a container image are not actually the container's responsibility. They are inherited from the host operating system, the container runtime, or the orchestrator. The DoD Container Hardening Process Guide v1.2 §5 codifies this inheritance: "with a properly locked down hosting environment, containers inherit most of the security controls and benefits from infrastructure to host OS-level remediation requirements."
The same guide, §6, is equally direct about the consequence. "If an OpenSCAP scan returns noncompliant result(s), always evaluate the validity of those findings. False positives are common within major host OS-based containers, as the security profiles normally account for all host-level controls potentially not applicable to a container build."
In the FedRAMP and DoD IL boundary reviews I have run, the §5 quote settles roughly two-thirds of the audit conversation about why a container image "fails" 30 controls on a host-OS STIG scan. The §6 quote covers the rest.
This is the table every assessor needs to see. Each row maps a control area to the plane that owns it, the plane that surfaces it, and the planes that inherit it.
Key: "Owns" means the plane is the authoritative source of the control. "Surface" means the plane exposes a knob but does not own remediation. "Inherits" means the plane gets the control for free from a lower plane. A row with multiple "Owns" entries means the control is enforced in more than one place. That is intentional defense in depth, and the auditor expects to see it.
A base image with no shell, no package manager, no compiler, and no static setuid binaries inherits zero CAT I findings on minimization-related controls. That reduction in image-level surface area is what makes hardened images useful in STIG-aligned environments.
Minimal, hardened container images satisfy STIG requirements at the base because they remove the very components that drive most CAT I and CAT II findings on a host-OS STIG scan: shells, package managers, compilers, setuid binaries, and debugging tools. They are one practical way to support FedRAMP CM-6 (a) Requirement 1 inside a container without running a 30-day OpenSCAP remediation cycle on every release.
"The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available." — FedRAMP SSP Appendix A, High Security Controls (CM-6)
That clause is the contract language behind every commercial hardened-image SLA on the market.
Source for the seven-family list: Coalfire and Chainguard's FedRAMP container hardening session (June 25, 2025). Each row is the chain of evidence an auditor will request: control → STIG/SRG citation → image artifact. A signed image with a STIG-scan attestation, an SBOM, and a VEX document can support evidence collection across these control families, alongside host, runtime, orchestrator, and operational controls.
Build-from-source hardened images compile each system package directly from upstream source. Examples include Chainguard Wolfi, Minimus, and DHI Hardened System Packages.
Strip-after-the-fact approaches start with a standard distribution and remove what is not needed. Examples include RapidFort and smaller slim variants of upstream images.
Build-from-source produces the cleanest STIG-scan results, because nothing was ever installed in the first place. Per Docker's DHI 1-year-anniversary blog (April 14, 2026), DHI now builds tens of thousands of Alpine and Debian system packages from source under a SLSA Build Level 3 pipeline.
A scope caveat from the field. Hardened images do not eliminate the need for host-OS STIG hardening, kube-apiserver STIG hardening, runtime threat detection, or EDR on the host node. They turn the image plane from a CAT II liability into a CAT II asset. They also remove the bulk of the OpenSCAP false-positive review burden, which is where the real time savings show up in a 12–18 month FedRAMP cycle. Treat the hardened image as one of seven control families in the boundary, not as the boundary itself.
Validating STIG compliance for a container image in production is a four-artifact stack. The four artifacts: a build-time SCAP scan (typically OpenSCAP) against the GPOS SRG XCCDF profile, a signed in-toto STIG-scan attestation attached to the image, an admission-controller policy that rejects unsigned or unscanned images, and a continuous re-scan loop that fires whenever the upstream vendor patches a critical CVE.
STIG compliance is not a one-time gate. It is a continuous-evidence regime that has to survive the next CVE, patch, release, and admission decision.
Use a vendor-neutral OpenSCAP run against a generic image to avoid lock-in:
# Pull a SCAP datastream (GPOS-aligned, container-tailored — for example,
# from Chainguard's open `chainguard-dev/stigs` repo, or your vendor's profile).
curl -fsSLO https://raw.githubusercontent.com/chainguard-dev/stigs/main/gpos/xml/scap/ssg/content/ssg-chainguard-gpos-ds.xml
# Run OpenSCAP against any image in your local registry.
docker run -i --rm -u 0:0 --pid=host \
-v /var/run/docker.sock:/var/run/docker.sock \
-v "$(pwd)/out:/out" \
--entrypoint sh \
docker.io/chainguard/openscap:latest-dev <<'EOF'
oscap-docker image <your-registry>/<your-image>:<digest> xccdf eval \
--profile "xccdf_basic_profile.check" \
--report /out/report.html \
--results /out/results.xml \
/usr/share/xml/scap/ssg/content/ssg-chainguard-gpos-ds.xml
EOF
report.html is human-readable for the assessor. results.xml is XCCDF for ingestion into MITRE Heimdall, SCAP Compliance Checker, Anchore Enterprise, or your GRC tool.
Other scanners that ingest XCCDF: cinc-auditor (used by Anchore Enterprise), Sysdig Secure (50+ OOTB DISA STIG policies), Prisma Cloud, Aqua, and Twistlock (legacy). DHI users get the equivalent attestation pre-built, retrieved with docker scout attest get --predicate-type https://docker.com/dhi/stig/v0.1 --verify dhi.io/<image>:<tag>.
A STIG-scan attestation is a signed, in-toto-formatted statement saying "this image was scanned against STIG profile X, on date Y, with result Z." It is the single most-requested audit artifact in a FedRAMP 3PAO review.
{
"name": "GPOS STIG Scan",
"profile": "xccdf_org.ssgproject.content_profile_stig",
"publisher": "Your Org / Your Vendor",
"result": "passed",
"summary": {
"totalChecks": 198,
"passedChecks": 91,
"failedChecks": 0,
"notApplicableChecks": 107,
"defaultScore": 100
},
"tool": "openscap",
"outputs": ["html", "xccdf"]
}
Per Docker's DHI 1-year-anniversary blog (April 14, 2026), DHI ships 17 signed attestations per image, including the STIG scan, FIPS compliance, CycloneDX SBOM, SPDX SBOM, SLSA provenance v1, VEX, virus scan, secrets scan, and changelog. In-toto attestations are the CNCF-blessed standard. Cosign signs them, Rekor logs them, MITRE Heimdall visualizes them, and GRC tools (Drata, Vanta, Anchore Enterprise) ingest them.
A build-time scan without admission-time enforcement is a dead letter. The next CI run will silently regress the cluster. Use the Kyverno admission controller to enforce hardened base images by requiring a STIG-scan attestation before admitting a pod:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-stig-attestation
spec:
validationFailureAction: Enforce
background: false
rules:
- name: verify-stig-scan
match:
any:
- resources:
kinds: ["Pod"]
verifyImages:
- imageReferences:
- "your-registry.example/*"
attestations:
- predicateType: https://docker.com/dhi/stig/v0.1
attestors:
- entries:
- keyless:
subject: "https://github.com/your-org/.github/workflows/build.yaml@refs/heads/main"
issuer: "https://token.actions.githubusercontent.com"
conditions:
- all:
- key: "{{ summary.failedChecks }}"
operator: Equals
value: 0
The policy rejects any pod whose image lacks a Cosign-signed STIG-scan attestation with zero failed checks. Equivalent enforcement options include OPA Gatekeeper (ConstraintTemplate), Sigstore policy-controller, Ratify (CNCF), and Connaisseur. Pick one.
In regulated clusters, Day-1 friction often comes from third-party operators, such as logging, observability, and ingress components, that pull images from registries without a STIG attestation. The pattern that works: stage the policy in Audit mode for the first two weeks. Exempt namespaces that host third-party operators. Then flip to Enforce once the platform team has either rebuilt those images internally or accepted documented exceptions.
Some hardened-image vendors publish remediation timelines for critical and high-severity CVEs. These timelines vary by vendor, severity, support tier, and whether a fix is available upstream.
Source: Coalfire and Chainguard's FedRAMP container hardening session (June 25, 2025); Docker FedRAMP blog (August 2025).
A program that achieves all four artifacts above produces, on every release, the exact evidence package a 3PAO will request: XCCDF scan results, signed STIG attestation, admission-controller policy, and remediation history. Centralized compliance dashboards for CIS, FIPS, and STIG collapse those artifacts into a per-image view. Re-attestation becomes a per-build event, not a quarterly project. That is the practical definition of continuous compliance for containerized environments.
Minimus builds container images directly from upstream source code. The image plane in the 4-plane allocation table arrives with most CAT I and CAT II findings already non-applicable. Every image ships with a Cosign signature, a CycloneDX SBOM, a VEX document, and a 48-hour critical-CVE remediation SLA. Together those artifacts produce the four items a 3PAO requests during a FedRAMP review.
Each image is mapped to NIST SP 800-190, NIST SP 800-53, CIS Docker Benchmark, FIPS 140-3, and the Container Platform SRG. The base layer becomes the strongest, not the weakest, link in your STIG attestation chain.
Browse the Minimus image gallery at images.minimus.io or read the verification, SBOM-retrieval, and admission-policy guides at docs.minimus.io.
No. As of April 2026, DISA has not published a container-image-specific STIG. Container hardening for regulated environments is governed by four DISA artifacts: the Container Platform SRG V2R4 (188 findings), the Kubernetes STIG V2R6 (92 findings), the General Purpose Operating System SRG, and the DoD DevSecOps Enterprise Container Hardening Process Guide v1.2. Per DoD guidance, the GPOS SRG is used to assess image-level controls in the absence of a container-specific STIG.
A Security Requirements Guide (SRG) is a high-level, technology-neutral set of security requirements derived from NIST SP 800-53 (for example, the General Purpose Operating System SRG). A Security Technical Implementation Guide (STIG) is the technology-specific, machine-readable XCCDF implementation of an SRG (for example, the Red Hat Enterprise Linux 9 STIG). SRGs say what; STIGs say how.
Most STIG controls scanned against a container image (auditing, ASLR, host firewall, host filesystem encryption, time synchronization, kernel parameters) are inherited from the host operating system per the DoD Container Hardening Process Guide §5. Image-level controls are minimization (no shell, no package manager, no compiler), CVE remediation, FIPS-validated cryptography, the Dockerfile USER directive, and TLS configuration in the application. A 4-plane allocation table (host OS, runtime, orchestrator, image) is the cleanest way to disambiguate them.
Hardened, minimal container images remove the components (shells, package managers, compilers, debuggers, setuid binaries) that drive most CAT I and CAT II findings on a host-OS STIG scan. They typically ship with a signed STIG-scan attestation, an SBOM, a VEX document, and a contractual CVE patch SLA (often 7 days for critical). Together those artifacts produce the evidence package a FedRAMP 3PAO requests during a CM-6, RA-5, SC-2, SC-3, SC-4, SC-28, and SC-39 review.
Run OpenSCAP with the oscap-docker image subcommand against the GPOS SRG XCCDF datastream (or a vendor-published container STIG profile such as Chainguard's chainguard-dev/stigs GPOS datastream or the Docker DHI custom STIG profile). Output two artifacts: an HTML report for the assessor and an XCCDF XML results file for ingestion into MITRE Heimdall, Anchore Enterprise, Sysdig Secure, Prisma Cloud, or the SCAP Compliance Checker. Re-run on every image rebuild and attach the result as a signed in-toto attestation.
.svg)
.svg)
.svg)
.svg)
