Prepared for: ACF TDP Stakeholders Date: April 2026 Related Issue: raft-tech/TANF-app#5542
This document evaluates whether moving TDP deployments from Cloud.gov-managed buildpacks to team-managed Docker images would maintain or improve the current security posture while addressing known operational limitations in the current deployment model.
- Background on the original buildpack decision: ADR-011 documents that TDP leveraged Cloud.gov buildpacks in 2021 in part because they provided a faster path to ATO than the team's earlier DockerHub-based approach, which lacked sufficient security documentation for ACF review.
- What is changing: TDP would shift from Cloud.gov-managed buildpacks to Docker DHI hardened base images and TDP-managed Docker images for application deployment, while continuing to run the applications inside the same Cloud.gov platform and runtime environment.
- Why this is being considered now: Buildpacks continue to create operational pain points, including long deploy times, repeated dependency downloads, less predictable build behavior, and limited visibility into the full runtime stack. At the same time, Docker image security capabilities and documentation have matured, especially around hardened base images, SBOMs, provenance, signing, and vulnerability management.
- Security responsibility impact: This change shifts responsibility for selecting approved base images, maintaining TDP's derived application images, and applying updated DHI releases into the deployment lifecycle from Cloud.gov to the TDP application team. It does not mean TDP becomes responsible for remediating CVEs in DHI base images themselves; that remediation remains with the DHI provider. TDP is responsible for rebuilding, validating, and redeploying downstream images after remediated base image versions are published. Based on the current architecture, this does not change the Cloud.gov hosting model or the ATO boundary, because the workloads would still run inside the same FedRAMP-authorized Cloud.gov environment and retain the same inherited platform controls.
- Key tradeoffs: The main tradeoff is greater operational and security ownership by the TDP team in exchange for better supply chain visibility, reproducibility, auditability, and deployment control. In practice, that means TDP must monitor for remediated DHI releases and update its derived images on an appropriate timeline, and ACF may need to evaluate whether Docker Hardened Images' enterprise tier or similar vendor support is needed if contractual remediation timelines such as a 7-day high/critical CVE response target are required.
- Registry note: TDP will store and distribute deployment images through GitHub Container Registry (GHCR). GHCR should be treated as part of the implementation architecture because it affects image access control, retention, provenance, and scanning workflows. Its use does not by itself change the ATO boundary analysis, but SSP and supporting documentation should reflect GHCR as the private registry of record and describe the associated access and monitoring controls.
TDP currently deploys frontend and backend applications to Cloud.gov using standard buildpacks. While functional, this approach introduces:
| Challenge | Impact |
|---|---|
| Extended deployment times | 15–30+ minute deployment windows |
| Transient network failures | Dependencies re-downloaded from scratch on every deploy, increasing failure risk |
| Supply chain volatility | Upstream package changes can introduce regressions without warning |
| Environment inconsistency | No guarantee of identical behavior across dev, staging, and production |
| Limited control | Inability to pin or audit the full dependency tree of the runtime environment |
Cloud.gov holds FedRAMP Moderate Authorization, covering over 60% of the 323 NIST SP 800-53 Rev 5 controls at the infrastructure and platform level.
The following platform-level controls are fully inherited by tenant applications regardless of whether buildpacks or Docker images are used:
| Control Family | Cloud.gov Responsibility | Affected by Deployment Method? |
|---|---|---|
| Physical Security (PE) | AWS GovCloud data centers | No |
| Infrastructure Security | AWS GovCloud services & configuration | No |
| Platform Security | Cloud Foundry, container runtime, networking | No |
| Container Isolation | garden-runc runtime with cgroups, process namespaces, user namespaces | No |
| Network Security | Platform networking, TLS termination, routing | No |
| Continuous Monitoring | FedRAMP continuous monitoring, annual assessments | No |
| CM-2 (Baseline Config) | Platform configuration baseline | No — platform portion unchanged |
| AU-12 (Audit Generation) | Platform event logging | No |
Critical point: Cloud.gov does not use Docker's runtime. All applications—whether deployed via buildpacks or Docker images—run under garden-runc, built on the Open Container Initiative's runc specification. Both deployment methods receive identical container isolation: cgroups for resource limiting, process namespaces for isolation, and user namespaces to prevent privilege escalation.
The primary compliance difference between buildpacks and Docker is who maintains the base image layer:
| Responsibility | Standard Buildpacks | Docker (with DHI) |
|---|---|---|
| OS-level patching | Cloud.gov (on restage) | TDP team via DHI automated patching |
| Language runtime updates | Cloud.gov | TDP team via Dockerfile version pinning |
| Dependency management | Re-downloaded each deploy (uncontrolled) | Locked in image layers (controlled, auditable) |
| Vulnerability scanning | Limited visibility | Full SBOM + automated CVE scanning |
| Configuration hardening | Opaque buildpack defaults | CIS-benchmarked, STIG-scanned base images |
This shift in responsibility is not a net loss—it is a trade of opaque, automatic updates for transparent, auditable, and controlled updates backed by industry-recognized security benchmarks.
Docker provides CIS-validated Hardened Images that are free to use, share, and build on under the Apache 2.0 license.
| Feature | Detail |
|---|---|
| Near-zero CVEs | Continuously scanned and patched to maintain minimal known exploitable vulnerabilities |
| CIS Benchmark Compliance | Images validated against CIS Docker Benchmark v1.8.0 |
| Distroless Variants | Reduce attack surface by up to 95% compared to standard images |
| Non-root Execution | Default least-privilege configuration (FIPS & STIG variants only) |
| SLSA Build Level 3 Provenance | Tamper-resistant, verifiable build chain |
| Signed SBOMs | Complete Software Bill of Materials for every component |
| VEX Statements | CVE exploitability context for accurate risk assessment |
| Cryptographic Signatures | Every package and image cryptographically signed and verified |
| Source-built Packages | Built from upstream source by Docker, not pulled from third-party repos |
| Automatic Patching | Rebuilt when upstream security updates are available |
| Feature | Detail |
|---|---|
| 7-day CVE SLA | Critical/high severity vulnerabilities remediated within 7 days |
| FIPS-enabled Variants | For cryptographic module compliance |
| STIG-ready Images | Meet Department of Defense security requirements |
| Custom Modifications | Tailored images for specific compliance needs |
| Extended Lifecycle Support | Post-EOL security patches |
| Security Dimension | Buildpacks | Docker Hardened Images |
|---|---|---|
| Vulnerability visibility | Limited; opaque stack | Full SBOM with every component listed |
| CIS compliance | Not CIS-benchmarked | CIS Benchmark v1.8.0 validated |
| Supply chain integrity | Dependencies fetched at deploy time from public repos | SLSA Level 3 provenance, cryptographic signatures |
| Attack surface | Full OS with all default packages | Distroless variants reduce surface by up to 95% |
| Patch transparency | Automatic but opaque; requires restage | Automatic with full audit trail |
| Runtime privilege | Varies by buildpack | Non-root by default |
| Audit artifacts | None provided | SBOMs, VEX statements, provenance attestations |
The following table maps relevant NIST controls to how they are addressed under the proposed Docker deployment model:
| Control | Description | How Addressed |
|---|---|---|
| CM-2 | Baseline Configuration | CIS-benchmarked DHI base images provide a documented, hardened baseline |
| CM-6 | Configuration Settings | Dockerfile and image layers provide version-pinned, reproducible configuration |
| CM-7 | Least Functionality | Distroless DHI variants eliminate unnecessary packages and services |
| RA-5 | Vulnerability Scanning | DHI continuous scanning + CI/CD pipeline scanning (e.g., Trivy, Grype) |
| SA-10 | Developer Configuration Management | SLSA Level 3 provenance ensures tamper-resistant build pipeline |
| SA-11 | Developer Testing & Evaluation | Automated security scanning integrated into image build process |
| SI-2 | Flaw Remediation | DHI automatic patching; Enterprise tier offers 7-day SLA |
| SI-7 | Software & Information Integrity | Cryptographic signatures on all images and packages |
| SC-28 | Protection of Information at Rest | Unchanged — Cloud.gov platform control |
| AU-12 | Audit Record Generation | SBOMs and provenance attestations provide audit artifacts not available with buildpacks |
Cloud.gov's Docker deployment documentation notes that Docker is "not a recommended path" and that users "lose a large set of features." This language warrants context:
-
The caveat is about operational convenience, not security. Cloud.gov recommends buildpacks because they reduce the maintenance burden on tenants. With DHI's automated patching and CI/CD integration, this burden is manageable and well-understood.
-
The "lost features" are buildpack-specific automation. Specifically, automatic language runtime updates on restage. With Docker, we gain explicit control over when and how these updates occur—improving change management (CM-3) and reducing the risk of unplanned regressions.
-
Cloud.gov fully supports Docker deployments. The
cf push --docker-imageworkflow is a first-class deployment method. The samegarden-runccontainer runtime, the same network isolation, and the same platform security controls apply.
Beyond maintaining compliance, Docker deployments actively improve our security operations:
Each deployment uses a specific, tagged image digest. If a vulnerability is discovered, we can identify exactly which deployments are affected and roll back to a known-good image instantly.
The same image runs in development, staging, and production. Environment-specific bugs are eliminated, reducing the risk of security issues that only manifest in production.
Dependencies are locked at build time, not fetched from public repositories during each deployment. This eliminates an entire class of supply chain attacks where a compromised upstream package could be pulled into production during a routine deploy.
SBOMs, provenance attestations, and VEX statements provide audit artifacts that buildpack deployments simply cannot produce. This strengthens our posture for RA-5 (Vulnerability Scanning) and AU-12 (Audit Generation).
To address the additional responsibilities that come with Docker deployment, we propose:
| Responsibility | Mitigation |
|---|---|
| Base image maintenance | Use DHI images with automated patching; pin to specific digests in CI/CD |
| OS-level security updates | DHI continuous scanning and automatic rebuilds on upstream updates |
| Vulnerability management | Integrate container scanning (e.g., Grype) into CI/CD pipeline for TDP frontend/backend containers; block deployment on critical/high CVEs |
| Configuration hardening | DHI images are pre-hardened to CIS benchmarks; no manual hardening required |
| Incident response | Immutable images simplify forensics; roll back by redeploying a previous digest |
| SSP documentation updates | Update relevant control narratives to reflect Docker deployment model and DHI security features |
- Container image scanning must be added to the vulnerability management scanning tools table (currently lists OWASP ZAP, Dependabot, and Webinspect — needs a container scanner like Trivy/Grype with defined frequency)
- Dockerfiles and container image digests must be added as configuration management artifacts in the CM tools and CM library sections
- CI/CD pipeline description must be rewritten to include Docker image build, container scanning, image registry, and
cf push --docker-imagedeployment flow - Shared responsibility boundary must be updated to document TDP team ownership of container runtime environment (base image OS packages, system libraries) vs. cloud.gov ownership of host OS and platform
- Container image baselines (Dockerfiles, pinned base image versions) must be added as a distinct baseline type in the configuration baselining section
- Risk summary may need new entries for container image supply chain risks and their mitigations (DHI, image signing, SLSA provenance)
- CM-7 (Least Functionality) — no standalone section exists in the SSP; needs language about minimizing attack surface via slim/distroless base images
- SI-7 (Software & Information Integrity) — no standalone section exists in the SSP; needs language about Docker image signing, digest verification, and SLSA Level 3 provenance
- SC-28 (Protection of Information at Rest) — only briefly mentioned; may need a note about container images at rest in a registry
- Cloud.gov's FedRAMP package (F1607067912) and all inherited controls remain unchanged.
- The platform's container runtime, network security, and isolation guarantees are identical.
- The authorization boundary does not change — applications still run within Cloud.gov's FedRAMP-authorized environment.
This transition can likely be handled as a significant change request rather than a full ATO reassessment, since:
- The authorization boundary is unchanged
- Inherited controls are unaffected
- The deployment method is a supported Cloud.gov capability
- The security posture is demonstrably maintained or improved
Transitioning from buildpacks to Docker containers built on CIS-validated Hardened Images maintains our security posture through Cloud.gov's unchanged inherited controls and strengthens it through:
- CIS-benchmarked, continuously scanned base images with near-zero CVEs
- SLSA Level 3 supply chain integrity with cryptographic verification
- Complete SBOMs and audit artifacts that buildpacks cannot provide
- Reduced attack surface through distroless image variants
- Immutable, reproducible deployments that eliminate environment drift
The additional responsibility for base image maintenance is mitigated by DHI's automated patching, continuous scanning, and (if needed) enterprise SLA-backed remediation. Meaning the TDP team is only responsible for monitoring new patches, verifying the patches, and applying them instead of managing the full supply chain and remediations surrounding the base images.
- Cloud.gov Compliance Overview
- Cloud.gov ATO Process
- Cloud.gov Docker Deployment
- Cloud.gov Shared Responsibilities
- Docker Hardened Images Catalog
- Docker Hardened Images Features
- Docker Hardened Images — Free for Everyone
- FedRAMP Compliance with Hardened Images
- CIS Docker Benchmark v1.8.0
- NIST SP 800-190: Application Container Security Guide
- Docker Hardened Images — 2026 Architect's Guide