STIG compliance for containerized LLM workloads

Which STIGs apply to an LLM serving stack

Security Technical Implementation Guides (STIGs) are DISA's hardening baselines. For a typical containerized LLM serving stack, several apply simultaneously.

Layer	STIG	Approximate item count
Host OS (RHEL 9)	Red Hat Enterprise Linux 9 STIG	~395 checks
Container platform	Docker Enterprise STIG or Podman; Kubernetes STIG for orchestration	~230 checks combined
Kubernetes	Kubernetes STIG	~100 checks
Application	Application Security and Development STIG (general)	~260 checks
Web server (if applicable)	NGINX or Apache STIG	~80-150 checks

The item counts shift as STIGs are revised. The point is that a non-trivial LLM serving stack carries 700+ STIG checks across the layers. Automation is not optional.

Host OS: RHEL 9 key items

High-impact items from the RHEL 9 STIG that LLM serving stacks commonly trip on:

• FIPS mode enabled system-wide (fips-mode-setup --enable).
• SSH restricted to key-based, FIPS-approved algorithms, no root login.
• SELinux in enforcing mode.
• Audit daemon running, audit log retention configured, rules for privileged commands.
• Kernel parameters hardened (sysctl entries for network stack, dmesg restriction, kernel.kptr_restrict).
• Mount options (noexec, nosuid, nodev) on /tmp, /var, /home.
• USBGuard enabled or USB fully disabled.
• Passwords and lockout policies per the STIG, if local accounts exist.

Most LLM workloads do not want humans logged in. Aim for zero interactive accounts on production hosts; all access via SSM/Session Manager, audited.

Kubernetes STIG: high-leverage items

• API server audit policy enabled with meaningful rules (not the default no-op).
• RBAC enforced, no wildcard permissions, no default service accounts in privileged roles.
• Pod Security Standards enforced — restricted profile for workloads that do not need elevated caps.
• No privileged containers in production namespaces. No host-path mounts unless explicitly justified.
• Network policies default-deny, with explicit allow rules per workload.
• etcd encrypted at rest.
• Kubelet configured with --anonymous-auth=false, authorization-mode=Webhook.
• Controller-manager and scheduler flags per STIG (--profiling=false, bind-address restricted).

Container image hygiene for LLM workloads

The LLM serving container is where application-layer STIG pressure concentrates. Hardening checklist:

• Minimal base image — UBI minimal, distroless, or Chainguard image.
• Non-root user with specific UID, no shell.
• Read-only root filesystem at runtime, writable volumes only where needed (model cache, log buffer).
• No package manager in the final image.
• All Python dependencies pinned in requirements.txt with hashes; pip install --require-hashes.
• Binary model weights hashed and verified at load; never fetched at runtime from untrusted sources.
• Health and readiness probes configured.
• Resource limits set (CPU, memory, GPU).
• No embedded credentials; all secrets via Kubernetes Secrets or an external KMS/Vault.
• Image signed with cosign, signature verified at admission (Kyverno or sigstore policy-controller).

LLM-specific additions

The STIGs pre-date LLMs. A few additional hardening patterns specific to LLM serving that mature programs treat as required even though they are not in the STIG yet:

• Model-weight integrity verification. Every model load verifies a SHA256 against an allow-list of authorized hashes. A changed hash fails loudly.
• No outbound internet from the serving pod. Egress network policy denies all outbound except to the KMS, metrics endpoint, and log aggregator.
• Prompt/response logging at the ingress. Application emits a structured log event for every inference including user ID, model version, prompt hash or content, response hash or content.
• Rate limiting per user and per tool. Protects against extraction attacks and runaway agentic loops.
• Admission control on model-version changes. Policy gates promotion to production.

Automation: SCAP, Ansible, CIS

STIG compliance is an automation exercise, not a manual one.

A well-instrumented program runs SCAP on every host daily, emits findings to the SIEM, and treats a STIG regression as a CM-3 change event.

Common failure patterns

• Running LLM containers as root because "GPU access needs it." Use nvidia-container-toolkit configured for non-root; no valid reason to run as root.
• Leaving default Kubernetes RBAC in place. The default service account has more than it needs in many distributions.
• No network policy. Every pod can reach every pod by default.
• Model weights downloaded at container start from an internet URL. Bake them into the image or pull from an internal, authenticated registry.
• No image signing. Any image from the registry runs.
• Audit logs going to local disk with no retention. They must ship to a central aggregator.

Bottom line

STIG compliance for LLM workloads is the RHEL STIG plus the Kubernetes STIG plus the container platform STIG plus application-level hardening, plus LLM-specific additions that the STIGs have not yet caught up to. Automate with SCAP and Ansible. Sign images. Enforce admission policy. Treat STIG regressions as change events. The paperwork is a byproduct of the engineering.

Frequently asked questions