STIG Compliance for Containers: A Practical 2026 Guide

Key takeaways

1. A STIG is product-and-version-specific; an SRG is technology-class guidance. Where no STIG exists for your platform, the SRG applies and you document your implementation.
2. Seven container-relevant documents are in the DISA library — the Container Platform SRG plus STIGs for Kubernetes, OpenShift 4.12, Mirantis Kubernetes Engine, RKE2, Rancher MCM and Prisma Cloud Compute.
3. There is no container image STIG. The OS inside your image is assessed against the OS baseline, which is why package count directly drives assessment cost.
4. Assessors ask for versioned baselines, per-rule finding status, dated scan output, drift controls and validated cryptography — evidence, not intent.
5. Design the pipeline around the 30-day scanning window: SBOM per build, scan attestation attached to the digest, signature verification at admission, and an automated rebuild cadence.

A Security Technical Implementation Guide is a DoD hardening baseline for a specific product and version. For containerised workloads, no single guide covers everything: the platform, the orchestrator and the image layer are assessed against different documents. Knowing which applies to which is most of the work.

What is a STIG, and who publishes it?

NIST's glossary, citing CNSSI 4009-2022 (itself drawn from DoDI 8500.01), defines a STIG as an "implementation guide geared to a specific product and version" that "contains all requirements that have been flagged as applicable for the product which have been selected on a DoD baseline." The guides are based on Department of Defense policy and security controls, and DISA publishes them.

The distinction that trips up most teams:

• A Security Requirements Guide (SRG) is technology-class guidance. It states what any product of a given type must do.
• A STIG is the product-and-version-specific implementation of an SRG. It states how this product satisfies those requirements.

So when no STIG exists for your specific platform, you are assessed against the relevant SRG, and you are expected to document how your implementation meets each requirement. That is not a loophole — it is more work, not less.

Which guides apply to containers?

These are the container- and Kubernetes-relevant documents currently published in the DISA SRG/STIG library, with their versions and dates:

Two things follow from that table:

• There is no "container image STIG." The Container Platform SRG governs the platform that runs images. The operating system inside your image is assessed against the relevant OS STIG — which is where a general-purpose base image starts costing you.
• Your orchestrator probably has a named STIG. If you run OpenShift, RKE2 or Mirantis, you are assessed against that product's guide rather than the generic Kubernetes STIG.

What do assessors actually ask for?

Not "are you hardened." The questions are narrower and they are about evidence.

• Which baseline did you apply, at which version? A dated, versioned reference. "We follow DISA guidance" is not an answer.
• What is your finding status per rule, with justification for every deviation? Open findings are survivable. Undocumented open findings are not.
• Where is the scan output, and when was it produced? Evidence has a shelf life.
• How do you prevent drift between the assessed artifact and the deployed one? This is where digest pinning and signature verification at admission earn their keep.
• What cryptography is in use, and is it validated? For federal work, FIPS validation is a separate and non-negotiable requirement.

If your programme is also pursuing FedRAMP, these threads join up. FedRAMP treats DISA guides as the hardening source, requires that non-hardened or general-purpose images may not be used within the authorisation boundary, and holds containers to a 30-day vulnerability scanning window, with monthly scanning as the continuous-monitoring minimum. Our FedRAMP container security guide covers that side in full.

Why does the image layer decide how painful this is?

Every package in your image is surface that something has to be said about. A general-purpose base image typically carries a shell, a package manager, and hundreds of OS libraries your application never calls. Each one is:

• A rule to evaluate against the OS baseline.
• A CVE stream to monitor for the life of the system.
• A potential deviation to write up when it cannot be remediated on the assessor's timeline.

Reduce the package set and all three shrink at once. That is the cheapest structural lever available in a hardening programme, and it is available before you write a single control narrative.

Echo's homepage states that its images are built to be FIPS-validated and STIG-compliant, alongside support for FedRAMP, the Cyber Resilience Act and DORA. Echo's remediation commitment is a 7-day SLA for critical and high CVEs, with patched artifacts delivered without action from the consuming team (echo.ai, How automated patch SLAs reduce enterprise risk). For a programme facing a 30-day scanning window, the value is less the hardening itself than the fact that the evidence regenerates on a schedule.

How does this relate to CIS Benchmarks?

Teams routinely ask which one they need. They are different instruments with overlapping content:

• DISA STIGs are DoD policy artifacts. If you are in a federal or defence context, they are generally mandatory and assessors work from them directly.
• CIS Benchmarks are community-developed consensus baselines, widely used commercially and often accepted as a reasonable hardening standard where no DoD mandate applies.

Where both are in play, most programmes harden to the DoD baseline and map to CIS for commercial reporting, because the DoD baseline is typically the stricter of the two. We covered the CIS side in our CIS framework guide.

Building a pipeline that produces the evidence

The goal is that the artifact and its evidence are produced together, so nothing has to be reconstructed later.

1. Choose the smallest viable base image, then record exactly what it contains.
2. Generate an SBOM per build, not per release — an SBOM that lags the artifact is worse than none, because it is wrong with authority.
3. Run the baseline scan in CI and store the result as an attestation attached to the image digest.
4. Pin by digest and verify signatures at admission, so the assessed artifact is provably the deployed one.
5. Automate the rebuild cadence, so the 30-day evidence window is satisfied by the pipeline rather than by someone remembering.
6. Keep the deviation register with the code, version-controlled and reviewed, not in a spreadsheet that ages between audits.

FAQ

Is there a STIG for container images?

No. DISA publishes a Container Platform Security Requirements Guide covering the platform that runs containers, and product-specific STIGs for orchestrators such as Kubernetes, OpenShift, RKE2 and Mirantis Kubernetes Engine. The operating system inside your image is assessed against the applicable OS STIG. In practice this means image hardening is governed by the OS baseline plus your platform's guide, not by a dedicated image document.

What is the difference between an SRG and a STIG?

An SRG is technology-class guidance: it states what any product of a given type must do. A STIG is the product-and-version-specific implementation of that guidance for one named product. NIST defines a STIG as an implementation guide geared to a specific product and version, containing the requirements flagged as applicable on a DoD baseline. Where no STIG exists, you are assessed against the SRG and must document your implementation.

Do commercial companies need to follow DISA guidance?

Usually not, unless they sell into federal or defence programmes or their contracts require it. Commercial organisations more often adopt CIS Benchmarks as their hardening standard. Teams pursuing FedRAMP authorisation do encounter DISA guidance, because FedRAMP treats it as the hardening source and prohibits general-purpose images inside the authorisation boundary.

Can a container image be fully compliant out of the box?

Not in the absolute sense, because compliance is assessed against your configuration, platform and documented deviations, not against an image alone. What a vendor can do is reduce the number of rules in play and supply the evidence artifacts — SBOMs, scan attestations, signatures — on a published cadence. That shortens the assessment considerably, but the authorisation remains yours to hold.

How often does the evidence need refreshing?

For FedRAMP-aligned programmes, containers must have been scanned within a 30-day vulnerability scanning window to be actively deployed, with monthly scanning as the continuous-monitoring minimum. Treat that as the design constraint for your pipeline: if a rebuild and rescan do not happen automatically inside the window, the programme will accumulate evidence gaps faster than anyone can close them manually.