STIG hardening for container images: what assessors check in FedRAMP and DoD stacks (2026)

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.

Key Takeaways

There is no DISA-published container-specific STIG. Container hardening for regulated environments is governed by four DISA artifacts: the Container Platform Security Requirements Guide (SRG) V2R4 (188 findings: 8 CAT I, 177 CAT II, 3 CAT III), the Kubernetes STIG V2R6 (92 findings: 18 CAT I, 74 CAT II), the General Purpose Operating System (GPOS) SRG, and the DoD DevSecOps Enterprise Container Hardening Process Guide v1.2.

Per the DoD Container Hardening Process Guide §5, "with a properly locked down hosting environment, containers inherit most of the security controls and benefits from infrastructure to host OS-level remediation requirements." In practice, that means most CAT II findings on a host-OS STIG scan against a container image are false positives. The 3PAO needs to be walked through the inheritance with a control-allocation table.

FedRAMP makes STIG hardening contractual via SSP CM-6 (a) Requirement 1: "The service provider shall use the DoD STIGs to establish configuration settings; CIS Level 2 guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available." That clause flows into seven NIST SP 800-53 control families (CM-6, RA-5, SC-2, SC-3, SC-4, SC-28, SC-39) every container artifact in the boundary has to satisfy.

Validating STIG compliance in production is a four-artifact stack: a build-time OpenSCAP scan against the GPOS SRG XCCDF profile, a signed STIG-scan in-toto attestation attached to the image, an admission-controller policy (Kyverno, OPA Gatekeeper, Ratify) that rejects images without that attestation, and continuous re-scan and re-attest on the vendor's CVE remediation SLA (typically 7 days for critical, 14–30 for high, medium, and low).

What This Guide Covers

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.

1. What STIGs Actually Require for Containerized Environments

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.

Severity Category Codes (CAT I / II / III)

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 Container-Specific STIG and SRG Inventory (CY2026)

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.

Deprecated Artifacts You Will Run Into

Three artifacts surface in older guidance and audit packs and should be ignored in CY2026:

• DKER-EE-XXXX (Docker Enterprise 2.x STIG) is deprecated. Tenable marked the corresponding audit file deprecated in August 2024.
• Earlier Container Platform SRG releases (V1Rx, V2R1 to V2R3) are superseded by V2R4.
• Generic "container STIG" downloads from third-party sites are not authoritative. Only DISA artifacts under public.cyber.mil/stigs are.

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.

2. Inherited vs. Container-Level Controls: Where the Real Work Happens

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.

The 4-Plane Control Allocation Table

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.

What This Means for Your Scan Results

A host-OS STIG (RHEL 9 STIG, Ubuntu 22.04 STIG) scanned against a container image will produce CAT II and CAT III false positives for any control marked "Inherits" in the table above. These may be expected inherited controls rather than image-level findings, but the rationale should be documented clearly for the assessor.

The DoD Container Hardening Process Guide §6 explicitly sanctions marking these as false positives in the audit record, provided the rationale ("inherited from host") is documented.

Findings on rows where the image is "Owns" or "Surface" are not false positives. Treat them as real, remediate at the image (or in the orchestrator's PodSecurity policy), and re-scan.

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.

3. How Minimal, Hardened Images Satisfy STIG Requirements at the Base

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.

The STIG → NIST 800-53 → Image-Level Artifact Mapping

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.

How Minimization Satisfies CAT I Findings

No shell means no /bin/sh-based privilege escalation findings. A distroless or scratch-based hardened image has nothing for Container Platform SRG or GPOS SRG findings on shell-banner, MOTD, and login-program controls to attach to. The findings evaluate as not applicable, not as failures.

No package manager means no installed-but-unused-package findings. Container Platform SRG and CIS Docker Benchmark both penalize unused packages. A from-source-built minimal image typically ships 5–30 system packages instead of 200–300, which removes the bulk of "package not required" findings before the scan runs.

No compiler, no debugger, no curl or wget means no MITRE ATT&CK T1611 toolkit on disk. Post-compromise tooling (T1611 Escape to Host) assumes the attacker reuses what is already on the image. Minimization caps the toolkit at zero.

Build-from-Source vs. Strip-After-the-Fact

Build-from-source hardened images compile each system package directly from upstream source. Echo is one example, building its entire catalog from source.

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. Echo compiles its Alpine- and Debian-based system packages from source under a SLSA Build Level 3 pipeline.

Production-Grade Hardened-Image Options for STIG-Aligned Environments (CY2026)

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.

4. Validating STIG Compliance for Container Images in Production

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.

4.1 Run an OpenSCAP Scan Against the GPOS SRG XCCDF Profile

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 the SCAP Security Guide (SSG) project, or your vendor's profile).
# See https://github.com/ComplianceAsCode/content for released datastreams.

# 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 \
 <your-openscap-image>:latest <<'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-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). With Echo, the equivalent STIG-scan attestation ships pre-built with every image, so teams can verify it with Cosign rather than running the scan themselves.

4.2 Attach the Scan Results as a Signed in-toto Attestation

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"]
}


Echo ships a full set of signed attestations with every image, including the STIG scan, FIPS compliance, CycloneDX and SPDX SBOMs, SLSA provenance, and VEX. 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.

4.3 Enforce the Attestation at Admission Time

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: <your-vendor-stig-predicate-type>
             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.

4.4 Re-Scan and Re-Attest on the Vendor's CVE Remediation SLA

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. Echo, for example, triages new CVEs within 24 hours and remediates critical and high-severity findings within 7 days — well inside the 21-day window FedRAMP allows for high-severity CVEs.

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.

How Echo Approaches STIG Hardening

Echo, which recently acquired 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 7-day critical- and high-severity 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.

For more on operationalizing compliance in regulated environments, see how to automate FedRAMP container scanning for faster, continuous compliance and which container images are pre-approved for FedRAMP workloads.

See how Echo supports FedRAMP and public sector compliance, or book a demo to walk through your STIG attestation chain with our team.

Frequently Asked Questions

Is There a STIG for Containers?

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.

What Is the Difference Between an SRG and a 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.

Which STIG Controls Apply Inside the Container vs. on the Host?

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.

How Do Hardened Container Images Help with STIG Compliance?

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.

How Do I Scan a Container Against a STIG?

Run OpenSCAP with the oscap-docker image subcommand against the GPOS SRG XCCDF datastream (or a vendor-published container 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.