STIG Compliance for Containers: Docker and Kubernetes Guide

STIG compliance means configuring a system to meet a Security Technical Implementation Guide (STIG), a hardening standard published by the U.S. Defense Information Systems Agency (DISA) and required for systems that connect to Department of Defense networks. For containers there is no single "container STIG": you apply STIGs per layer, meaning the host OS STIG, the Kubernetes or platform STIG (for example Kubernetes, OpenShift or RKE2), and, for the images themselves, the DoD Container Hardening Process Guide. This guide maps each layer to the document that covers it and shows the tools and commands that produce audit-ready results, as of October 2026.

What is STIG compliance?

A STIG is a checklist of configuration rules for one product (RHEL 9, Kubernetes, PostgreSQL, and so on). Each rule has an ID, a check procedure, a fix procedure and a severity category:

Category	Meaning (DISA definition, paraphrased)	Typical handling
CAT I (high)	Exploiting it directly and immediately causes loss of confidentiality, integrity or availability	Must be fixed before an ATO; usually a blocker
CAT II (medium)	Has the potential to cause that loss	Fix, or document a mitigation in a POA&M
CAT III (low)	Degrades the measures that protect against that loss	Fix or document

STIGs are derived from NIST SP 800-53 controls. Being "STIG compliant" in practice means: you ran the checks, fixed what you could, and documented every remaining open finding with a justification. Auditors read your checklists (STIG Viewer files) and your scan results, not your claims.

You download STIGs for free from the DoD Cyber Exchange STIG library and view them with DISA's STIG Viewer. STIG Viewer 3 saves checklists as .cklb (JSON) instead of the older .ckl XML format.

Is there a Docker STIG? Which STIG applies to which layer

This is the part most guides get wrong. Here is what exists:

Layer	Applicable DISA guidance	Notes
Host OS	RHEL 8/9 STIG, Ubuntu STIG, Windows Server STIG, etc.	The foundation; most CAT I findings live here
Container engine	Docker Enterprise 2.x Linux/UNIX STIG (2019)	Written for Docker Enterprise, now owned by Mirantis. There is no STIG for Docker CE / Docker Engine; teams commonly use the CIS Docker Benchmark there
Orchestrator	Kubernetes STIG (covers Kubernetes 1.16.7 and newer), plus vendor STIGs: Red Hat OpenShift 4, RKE2, Rancher, Mirantis Kubernetes Engine	Use the vendor STIG if your distribution has one
Container platform (general)	Container Platform SRG (released December 2020)	A Security Requirements Guide: the requirements vendors build product STIGs from. Use it when no product STIG exists
Container images	DoD Container Hardening Process Guide, plus the OS STIG/GPOS SRG for the base image	As Docker's docs put it, DISA "has not published a STIG specifically for containers"
Your application	Application Security and Development STIG	Covers code-level and app config requirements

So the honest answer to "docker stig" is: if you run Docker Enterprise or Mirantis, there is a product STIG; if you run Docker Engine, harden the host with the OS STIG, apply the CIS Docker Benchmark, and harden images per the Container Hardening guide.

Step-by-step: hardening containers to STIG requirements

1. Inventory every layer and download the right STIGs

List the host OS and version, container runtime, Kubernetes distribution and version, base images and any databases or web servers in images. Download the matching STIGs and SRGs from the STIG library. Check the release (for example V2R5) on each, because DISA releases updates on a regular cycle and auditors expect the current release.

2. Harden the host OS with SCAP automation

For RHEL and its derivatives, the SCAP Security Guide ships a STIG profile you can scan and remediate with OpenSCAP (RHEL security hardening docs):

sudo dnf install -y openscap-scanner scap-security-guide
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml   # confirm the profile ID
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results host-results.xml --report host-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Remediate with the generated Ansible playbook or --remediate, test in staging first (some STIG rules, like FIPS mode and audit settings, change system behavior), then re-scan.

3. Harden container images

Images inherit most findings from their base OS. Practical rules that line up with the Container Hardening guide and what Iron Bank reviewers check:

• Start from a minimal, maintained base image and pin it by digest.
• Run as a non-root user; remove package managers, shells and SUID binaries you do not need.
• Patch on every build and keep the CVE list at zero critical/high, or justify each one.
• Do not bake secrets into layers.

FROM registry.access.redhat.com/ubi9/ubi-minimal@sha256:<pinned-digest>
RUN microdnf -y update && microdnf clean all
COPY --chown=1001:0 ./server /app/server
USER 1001
ENTRYPOINT ["/app/server"]

Scan the image against the OS STIG profile with oscap-podman (root required; available on RHEL 8.2 and later):

sudo oscap-podman <image-id> xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --report image-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Expect some host-only rules (bootloader, partitions, auditd) to fail or not apply inside a container. Mark those Not Applicable with a justification rather than "fixing" them.

Pre-hardened sources: Iron Bank, Platform One's repository of hardened images accredited for DoD use, is the usual source for DoD programs. Commercially, Docker Hardened Images offers STIG variants (paid Select/Enterprise tiers) that ship with a signed STIG scan attestation, retrievable with docker scout attest get --predicate-type https://docker.com/dhi/stig/v0.1 --verify --predicate dhi.io/<image>:<tag>. Docker states its profiles are based on the GPOS SRG and the Container Hardening guide, so treat them as evidence, not as a DISA certification.

4. Apply the Kubernetes STIG

The Kubernetes STIG covers the API server, controller manager, scheduler, etcd and kubelet: TLS 1.2 minimum, no anonymous access, audit logging, disabled insecure and read-only ports, and file permissions on certificates and manifests. A kubelet config fragment showing the kind of settings it checks:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
readOnlyPort: 0
tlsMinVersion: VersionTLS12
authentication:
  anonymous:
    enabled: false
authorization:
  mode: Webhook

For workloads, enforce least privilege with Pod Security Admission at the restricted level, which requires settings like these:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

On OpenShift, the Compliance Operator runs OpenSCAP-based STIG scans across the cluster and can auto-remediate many rules. RKE2 publishes STIG guidance and defaults for its own distribution.

5. Record results in checklists

Import SCAP results (XCCDF) into STIG Viewer 3, review the manual checks that automation cannot do, and set every rule to Open, Not a Finding, or Not Applicable with comments. Open findings go into a POA&M (Plan of Action and Milestones) with a fix date or a risk acceptance.

6. Make it continuous

Rebuild and re-scan images on every base image update, run the OS and cluster scans on a schedule, and keep results per release. Container images change weekly; a one-time STIG scan goes stale fast.

STIG compliance tools compared

Tool	Free?	What it does
DISA STIG Viewer 3	Yes	Read STIGs, fill in checklists (.cklb)
OpenSCAP + SCAP Security Guide	Yes	Automated scans and remediation for Linux hosts and images (oscap, oscap-podman)
MITRE SAF	Yes	InSpec validation profiles, Heimdall for viewing results, SAF CLI to convert scanner output
Evaluate-STIG (NAVSEA)	DoD distribution	PowerShell-based scanner that produces STIG checklists for many products
OpenShift Compliance Operator	Included with OpenShift	In-cluster STIG scanning and remediation
Commercial CNAPPs (Prisma Cloud, Sysdig, Anchore, etc.)	Paid	Image and cluster scanning with STIG-mapped policies and reporting

Avoid downloading STIGs or STIG Viewer from mirror sites; stigviewer.com, for example, says it is not affiliated with DISA. Use cyber.mil. For broader tooling, browse DevHunt's security tools and DevOps tools, and if you are still picking an orchestrator, read evaluating container orchestration tools.

Limitations to plan for

• Many STIG rules assume a full VM. Inside containers, mark host-level rules Not Applicable with a written reason; do not install auditd in every image.
• Automation covers most but not all rules. Some checks are manual (documentation, procedures) and need a human reviewer.
• A STIG-hardened image on a non-hardened host or cluster is not compliant. Auditors assess the whole stack.
• STIG releases change. Pin which release you assessed against in every report.

FAQ

What is STIG compliance?

It means a system is configured according to the applicable DISA Security Technical Implementation Guides, with every rule checked and every open finding documented. It is mandatory for DoD systems and common in federal contracts and for vendors selling to the DoD.

Can you STIG a Docker container?

Yes, in practice. There is no DISA STIG for container images, so you harden the image against its base OS STIG profile (for example with oscap-podman), follow the DoD Container Hardening Process Guide, and run the container on a STIG-hardened host and cluster. Iron Bank images and Docker Hardened Images STIG variants give you a hardened starting point.

Is there a STIG for Docker CE?

No. DISA's Docker STIG covers Docker Enterprise 2.x (now Mirantis). For Docker Engine (CE), teams typically apply the host OS STIG plus the CIS Docker Benchmark, and use the Container Platform SRG to cover remaining requirements.

What are the best STIG compliance tools?

For free: DISA STIG Viewer for checklists, OpenSCAP with the SCAP Security Guide for automated Linux scans, and MITRE SAF for InSpec profiles and reporting. In Kubernetes, the OpenShift Compliance Operator or a commercial scanner automates cluster-wide checks.

What is the difference between a STIG and an SRG?

An SRG (Security Requirements Guide) describes requirements for a whole technology class, such as container platforms or general-purpose operating systems. A STIG turns those requirements into specific check and fix steps for one product, such as RHEL 9 or Kubernetes.