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

While containerization may not strictly be required in all environments, it provides many benefits such that it is worth containerizing your custom software components. Containerization provides a stronger isolated security baseline compared to other software deployment techniques, and containers support deployment into secured Kubernetes clusters, which can speed up deployments in environments where that is already the standard model.

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, least-privilege 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.

Treat the "hardened base image" as a starting point, not a finished hardening solution. A curated base inherits OS-level hardening, but application-layer hardening — input validation, secrets handling, audit content, dependency hygiene — remains yours, and base images deprecate as their upstream ages.

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.

A common theme you will also likely see across many base images is trying to reduce the number of software packages installed. This is important for reducing attack surface and having a good security posture. Few base images will be completely free of vulnerabilities, and if you install additional software packages, that opens up the possibility for more vulnerabilities. If you are able to have your software run with as minimal underlying dependencies as possible, that improves overall security posture and reduces your ATO preparation work as well.

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.

Even within a given SRG or STIG, not all rules may be applicable to your software, and there may not be a STIG for every specific technology you use. Therefore, unless told you need to address specific SRGs or STIGs, be smart about selecting which guides and rules you spend time addressing and documenting. Recognizing connections and overlap between high-level NIST SP 800-53 controls and SRG or STIG rules can help save effort.

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

State your hardening posture as concrete, enforceable properties rather than vague assurances, because these are exactly the properties admission policies (see Address policy enforcement findings below) actually check:

A single unprivileged user, declared via the image's USER directive so it is baked into the image rather than relying solely on a runtime drop (the default user is root, so a container escape from a root container can become host root)
All Linux capabilities dropped
Privilege escalation disabled
CPU and memory limits set on every container
No baked-in secrets — injected at runtime from the platform

Pair what the image is (the vendor's hardening posture) with what the platform enforces at admission (inherited policy-as-code). Citing both for the same property gives you defense in depth: the image ships hardened, and admission control refuses to run it if it isn't.

[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).

For many applications that rely on operating system features or third-party packages, it's unlikely that you'll be able to get to 0 vulnerabilities easily. Some vulnerabilities may also be disputed or not-applicable to your software system. If you are able to have your software run using a base container image with minimal third-party packages, that is likely a quicker path to a low-to-no vulnerability container image.

[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.