Container Hardening

This section shifts our focus to the technical implementation work you can expect for ATO readiness. Crucially, implementation alone is never sufficient. Everything must be justified and well-documented. Rather than repeat installation documentation that already exists, we focus on the compliance-specific decisions, configurations, and gotchas we encountered.

We've included code examples throughout the following sections to help you on your ATO journey. to specifically address ATO requirements. For easy reference, they are also all in one GitHub repo: Edensoft-Labs/AtoReadinessCodeExamples. (You can use AI tools, like Claude Code, to help customize them to your use case.)

[CONT-1] Containerize your custom software using hardened base container images

Custom software backend components need to be containerized to support deployment in a secured Kubernetes cluster.

Even more importantly, your software must be able to operate correctly in these environments. “Authorization to operate” means little if your software crashes on startup, can’t integrate with ingress, or violates runtime policies. Testing early in a representative environment, like a Big Bang cluster, helps uncover those issues before you arrive at the authorization stage.

There is no hard-and-fast guide to containerizing your software, as there are too many hidden variables. However, keep these principles in mind:

Start from an approved, patchable base image. This is often Iron Bank or an organization-approved hardened base. (See the next section to learn about Iron Bank.)
Run as a non-root user inside the container by default. Drop capabilities unless you can justify them.
Use a repeatable, auditable build. This means pinned package versions, deterministic steps, and no curl | bash improvisation.
Separate build-time and runtime concerns into a multi-stage build process. Do not ship compilers, package managers, or secrets in your final container image.

You can see many of these principles in action in this example Dockerfile: AtoReadinessCodeExamples/ExampleDockerfile at main · Edensoft-Labs/AtoReadinessCodeExamples.

Leverage Iron Bank

If you already have containerized software, make sure it uses hardened container images from places like Iron Bank, Chainguard, Rapidfort, or Unicorn Delivery Service (UDS). We went with Iron Bank, as it was completely free and what the Department of War (DoW) currently often uses.

Iron Bank produces hardened building blocks that you can use to simplify and accelerate your own ATO process, but it does NOT confer that authorization automatically. Hardened containers do not themselves have “ATO,” because an image cannot be authorized. Only a system can be authorized.

There are numerous good choices for hardened base images on Iron Bank. Here are three you’re most likely to use:

Red Hat Universal Base Image (UBI) : The Red Hat Universal Base Image (UBI) is Red Hat’s way of making the core of RHEL (Red Hat Enterprise Linux) freely usable for containerized environments without requiring a subscription. In essence, UBI is a redistributable subset of RHEL, built from the same sources as official RHEL releases, but licensed to be shared publicly. It’s designed so that developers can build and distribute containers based on RHEL-compatible images, while still keeping compatibility with the RHEL ecosystem. UBI includes the same runtime environment and package set as RHEL (glibc, system libraries, etc.), but excludes anything that’s subscription-locked like certain management tools or proprietary drivers.

Ubuntu Pro: Canonical’s enterprise support and security subscription for Ubuntu. Functionally, it extends standard Ubuntu LTS by providing up to 10 years of security updates, including vulnerability patching for the core OS and also main package repositories, which are normally best-effort. From an ATO perspective, this matters because many widely used open-source dependencies would otherwise fall outside a defensible patching story. Ubuntu Pro also unlocks FIPS 140-2/3 validated cryptographic modules, which are frequently required for software deployments in DoW.

Debian 13: From a purely technical standpoint, Debian is exceptionally solid and widely respected as the upstream ancestor of many enterprise distributions (including Ubuntu). However, an Iron Bank Debian image is often acceptable for platform components, build tooling, or tightly scoped services, especially when paired with strong boundary controls and aggressive scanning. For anything handling CUI, mission data, or long-lived production services many AOs will still prefer a distribution with a commercial risk owner (RHEL, Ubuntu Pro) even if the raw technical security posture looks similar.

Pulling Iron Bank images

Anyone can view Iron Bank’s image repository at https://ironbank.dso.mil/repomap, but you must create a Platform One Single Sign On (SSO) account at https://login.dso.mil/ to do so.

Once you log in with docker login, you can also pull Iron Bank images from the command line. The credentials for docker login are NOT your Platform One SSO credentials. Here’s how to get the right credentials:

Log in to Registry1 with your Platform One SSO.
Click your username in the upper right corner, then click “User Profile”.

3. In the window that appears, copy the CLI secret. First generate it if it doesn’t exist.

Now, in docker login, use the username shown for your Docker username and the CLI secret as the Docker password. Once you are logged in, you can pull images directly from the command line. They even provide a copyable pull command for you, as shown below:

To use the new image, you just have to change the base image in your Dockerfile.

For example,

FROM debian:13 would become FROM registry1.dso.mil/ironbank/opensource/debian/debian:13.

Iron Bank caveats

Although Iron Bank provides a great starting point, you need to be aware of a few caveats.

First, not all Iron Bank images are magically free of vulnerabilities. You can see the exact hardening performed by looking at the source repo for each and every Iron Bank image. This information can be accessed by clicking “View Source Code” on the Iron Bank repo page:

This links directly to the repo containing the Dockerfile and other code for the container, for example, Iron Bank Containers / Opensource / Debian / debian11.x / debian-11.x · GitLab. For more information on Iron Bank, see the official FAQ.

Next, deployment into CUI or classified environments often requires a Federal Information Processing Standards (FIPS)-compliant Linux kernel on the host and FIPS-validated cryptographic modules wherever cryptography is actually performed. FIPS compliance does not come automatically with Iron Bank images or Big Bang. For example, Ubuntu provides FIPS support only via an Ubuntu Pro subscription. While Ubuntu Pro–based containers are in Iron Bank, Iron Bank does not confer the subscription itself; your organization must supply it if FIPS is required.

Where the FIPS boundary must exist depends on your architecture. If your application delegates TLS to an ingress controller, sidecar, or other platform component, that is where the validated crypto module must live. If, however, your application performs application-layer cryptography (JWT signing, envelope encryption, client-side TLS, or direct use of KMS libraries) you may need a FIPS-validated module inside the application runtime itself. This is an architectural decision, not a simple library swap.

[CONT-2] Implement Application Security and Development (ASD) Security Technical Implementation Guide (STIG) requirements for containers

Security Requirements Guides (SRGs) define the policy-level requirements for a class of technologies and express what must be true to meet DoW cybersecurity expectations, mapped to higher-level controls such as those in NIST SP 800-53. Security Technical Implementation Guides (STIGs) translate those requirements into concrete, testable configuration rules for specific products or platforms, answering how a particular system is configured to satisfy the requirement.

STIGs are associated to controls by specific by CCIs (Control Correlation Identifiers), all of which can be viewed with the official DISA STIG Viewer application or at an unofficial website that we’ve found to provide a better browsing experience: STIG Viewer.

If you are deploying custom application containers onto a DoW-managed Big Bang Kubernetes cluster, you are most likely not expected to STIG everything yourself. You are responsible for your container images and the software running inside them. But the platform (Kubernetes, nodes, service mesh, networking) is mostly likely STIG’ed by the platform owner, and your SSP must confirm this explicitly.

There is no single “Container Image STIG.” Instead, container compliance is most often assembled from the Application Security and Development (ASD) STIG and Container Platform Security Requirements Guide (SRG). Your software might also be required to implement the DevSecOps Enterprise Container Hardening Guide.

At its core, the ASD STIG asks whether an application authenticates correctly, authorizes correctly, records what happened, protects data, and fails safely under DoW policy. Almost everything falls into the following buckets:

Identity, Authentication, and Session Control. How users and devices prove who they are, and how long that trust lasts. This includes MFA (CAC/PIV), PKI, password policy, session lifecycle, re-authentication, cookie security, and replay resistance.
Authorization and Account Governance. What authenticated identities are allowed to do, and how accounts are managed over time. RBAC, least privilege, account lifecycle, inactive account cleanup, emergency and temporary accounts, and administrative notifications live here.
Auditability and Accountability. Whether the system can reliably explain itself after the fact. Comprehensive audit events, required log content, centralized logging, retention, integrity protection, alerting, and reporting.
Cryptography and Trust Infrastructure. How trust is enforced technically rather than socially. FIPS-validated crypto, TLS, mutual authentication, key management, hashing, signatures, and approved certificate authorities.
Data Protection and Information Flow. How sensitive data is handled everywhere it exists. Classification, labeling, marking, protection in transit/at rest/in use, secure destruction, and prevention of unauthorized aggregation or mining.
Input Handling and Application Hardening. Whether hostile input can coerce unintended behavior. Input validation, injection defenses (SQL, XSS, command, XML), CSRF protection, and canonicalization.
Failure Behavior and Resilience. What happens when things go wrong or are stressed. Fail-secure behavior, error handling, race condition avoidance, DoS protections, resource monitoring, and graceful degradation.
Secure Configuration and Change Control. How the system is kept in a known-good state. Configuration baselines, patching, vulnerability scanning, Ports, Protocols, and Services Management (PPSM) compliance, interface separation, and change auditing.
Service Interfaces and Protocol Security. How structured machine-to-machine trust is enforced. SAML, SOAP/WS-Security, message integrity, timestamps, expiration, and encryption.
Secure Development and Operational Governance. How security is sustained over the system’s lifetime. Secure SDLC practices, testing, threat modeling, incident response, backups, training, documentation, and decommissioning.

[CONT-3] Implement Container Security Requirements Guide (SRG)

Most of the Container Platform SRG talks about the platform, not your image. However, a small but important subset applies directly to containers. These requirements include common-sense practices like the following:

No unnecessary binaries
No embedded credentials
Running as non-root
Controlled privilege escalation

[CONT-4] Remediate container vulnerabilities identified by static scanning

As described in a later section, vulnerability scanning of third-party dependencies provides essential evidence for ATO.

Usually, these vulnerabilities are addressed by upgrading the affected third-party packages. If no upgrade is available, the vulnerability should be documented in the Plan of Actions & Milestones (POA&M).

[CONT-5] Address runtime security findings

NeuVector is a runtime security package supported by Big Bang. Any issues identified for your custom software (not DevSecOps platform infrastructure) should be addressed, either by fixing the issues or recording why they're not yet fixed in the POA&M.

NeuVector provides web-based dashboards but can also export reports from the following, which should likely be included in an ATO package:

Security Event and Risk Report (per namespace PDFs from the main dashboard)
Ingress and Egress Exposure Report (CSV from the main dashboard; likely should be filtered just to our software)
Policy → Groups (YAML policy files for your specific groups)
Policy → Network Rules (PDF/CSV files for your specific software)
Security Risks → Vulnerabilities (PDFs/CSVs for your specific software)
Notifications → Security Events (PDFs/CSVs for your specific software)
Notifications → Risk Reports (PDFs/CSVs for your specific software)

[CONT-6] Address policy enforcement findings

Kyverno is a policy engine supported by Big Bang. Any issues identified for your custom software (not DevSecOps platform infrastructure) should be addressed, either by fixing the issues or recording why they're not yet fixed in the POA&M.

Kyverno contains a web-based "policy reporter" dashboard that can also be used to export reports. Appropriate web-based printouts or specific exported reports (scoped as best as possible to our software) should be included in the ATO package. Some specific things include:

Overall policy report (from main dashboard; can be scoped to namespaces)
Overall namespace report (from main dashboard; can be scoped to namespaces)

Mentioning specific Kyverno policies in the System Security Plan is recommended.