Waterfall to Warp Speed: How the DoD Went From 10-Year Cycles to 31 Deploys a Day

Three to Ten Years

That's how long it took the Department of Defense to deliver software for weapons systems. Three to ten years. Not a typo. Not an exaggeration. That's the number from the CNCF's own case study on the DoD — the baseline against which every improvement in this story is measured.

Think about that timeline. When a program started building software for a fighter jet in 2012, the code might ship in 2022. By then, the threat landscape had changed, the hardware had been revised twice, and the developers who wrote the original requirements had probably moved to different agencies. The software was legacy before it ever reached the flight line.

The waterfall model didn't just slow things down — it made software delivery fundamentally incompatible with how modern conflicts actually unfold. You can't respond to a new electronic warfare threat with a 36-month requirements gathering phase.

This is the story of how that changed. Not gradually. Abruptly.

The Programs That Broke the Mold

Kessel Run: 124 Days from Zero to MVP

In 2017, the U.S. Air Force's Kessel Run program did something the Pentagon's acquisition system wasn't built to handle. They went from concept to a working Minimum Viable Product in 124 days. The traditional timeline for an equivalent capability was north of three years (Air & Space Forces Magazine).

Kessel Run didn't just ship fast — it stayed fast. The program achieved a deploy cadence of every 11.2 hours, saving the Air Force an estimated $13 million and 1,100 man-hours per month (Rise8 post-mortem analysis).

The proof came under pressure. When the U.S. evacuated 123,000+ people from Afghanistan in August 2021, the Slapshot mission planning application — built and maintained by Kessel Run — scaled to support one of the largest airlifts in history. That application was built with modern DevSecOps practices, running on Kubernetes, continuously delivered by a team that could push updates in hours instead of quarters.

Try pulling that off with an 18-month ATO renewal and a waterfall release train.

SoniKube: Kubernetes on an F-16

If Kessel Run proved DevSecOps worked for mission planning software, SoniKube proved it worked at the tactical edge — literally on a fighter jet.

In 2020, a team at the DoD stood up three simultaneous Kubernetes clusters running on an F-16 in 45 days. Three clusters. On a jet. In a month and a half. The CNCF covered this in detail, and the implications are hard to overstate.

This isn't a Kubernetes cluster humming in some climate-controlled data center. It's containers orchestrated on hardware that pulls 9Gs, operates in contested electromagnetic environments, and has intermittent or zero connectivity to any network. If your argument against Kubernetes is "it's too complex for production," the Air Force would like a word.

Platform One: The Factory Behind the Factory

While Kessel Run and SoniKube grabbed headlines, the program that arguably changed the most across the entire DoD was Platform One, led by Nicolas Chaillan (the Air Force's first Chief Software Officer).

The numbers speak for themselves:

• 200+ teams across the DoD using DevSecOps through Platform One
• 31 releases per day across the platform
• $12.5 million saved per year per application versus traditional approaches
• 1,500-person community of practice sharing patterns, configs, and lessons learned
• 650+ software containers deployed, with 900+ hardened containers in Iron Bank

(ExecutiveGov, Breaking Defense)

Platform One didn't just build a pipeline — it built a pipeline factory. A set of shared tools, hardened images, compliance automation, and deployment patterns that any DoD program could adopt instead of reinventing the wheel from scratch.

The Stack: Iron Bank + Big Bang + cATO

Understanding the DoD DevSecOps revolution requires understanding three components that work together like layers of a cake. Each one solves a specific problem that traditionally ate months of schedule and millions of dollars.

Iron Bank: Hardened Containers for Everyone

The DoD's first problem was base images. Commercial teams pull from Docker Hub and move on. DoD teams need containers hardened to DISA STIG standards — Security Technical Implementation Guides that specify hundreds of configuration requirements for every piece of software.

Iron Bank is the DoD's centralized repository of hardened container images. It currently hosts 1,000+ container images, all hardened to DISA STIG standards (RHEL 8/9 baselines), and freely available to all DoD users. At IL2 (Impact Level 2), the repository is publicly accessible at repo1.dso.mil/dsop.

Here's what a hardened Dockerfile from Iron Bank actually looks like in practice:

# Iron Bank hardened base — DISA STIG compliant
ARG BASE_IMAGE=registry1.dso.mil/ironbank/opensource/nodejs/nodejs20:20.11.0
ARG BASE_REGISTRY=registry1.dso.mil

FROM ${BASE_IMAGE} AS builder

USER root
WORKDIR /app

# Copy dependency manifests first for layer caching
COPY package.json package-lock.json ./
RUN npm ci --only=production --ignore-scripts && \
    npm cache clean --force

COPY . .
RUN npm run build

# --- Production stage: minimal attack surface ---
FROM ${BASE_IMAGE}

# STIG V-222425: Run as non-root
USER 1001

WORKDIR /app

COPY --from=builder --chown=1001:1001 /app/dist ./dist
COPY --from=builder --chown=1001:1001 /app/node_modules ./node_modules
COPY --from=builder --chown=1001:1001 /app/package.json ./

# STIG V-222431: No unnecessary packages, no setuid/setgid binaries
# (Iron Bank base images handle this — don't install additional packages)

EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s \
  CMD ["node", "-e", "require('http').get('http://localhost:8080/healthz', r => process.exit(r.statusCode === 200 ? 0 : 1))"]

CMD ["node", "dist/server.js"]

Notice the registry1.dso.mil/ironbank base. That's not a suggestion — in most DoD Kubernetes environments, admission controllers will reject any image that doesn't originate from an approved registry. Iron Bank images come pre-scanned, pre-hardened, and with documented provenance chains. You're standing on a reviewed foundation instead of building on whatever node:latest happened to include that week.

Big Bang: The Declarative DevSecOps Platform

Once you have hardened images, you need a platform to run them on. That's Big Bang — an open-source, declarative continuous delivery framework for DoD Kubernetes clusters.

Big Bang isn't a single tool. It's an opinionated assembly of production-grade components, all wired together via GitOps. Here's a representative values.yaml that shows the scope of what Big Bang manages:

# bigbang/chart/values.yaml — DevSecOps stack declaration
# Reference: https://github.com/DoD-Platform-One/bigbang

domain: mission-apps.mil

istio:
  enabled: true
  values:
    global:
      proxy:
        resources:
          requests:
            cpu: 100m
            memory: 256Mi

monitoring:
  enabled: true
  values:
    prometheus:
      prometheusSpec:
        retention: 30d
        storageSpec:
          volumeClaimTemplate:
            spec:
              resources:
                requests:
                  storage: 50Gi

logging:
  enabled: true
  values:
    elasticsearch:
      master:
        persistence:
          size: 100Gi
    kibana:
      enabled: true

twistlock:
  enabled: true
  values:
    console:
      persistence:
        size: 100Gi

kyverno:
  enabled: true
  values:
    replicaCount: 3

argocd:
  enabled: true
  values:
    server:
      extraArgs:
        - --insecure=false

fluxv2:
  enabled: true

jaeger:
  enabled: true

kiali:
  enabled: true

Service mesh (Istio). Monitoring (Prometheus/Grafana). Logging (EFK stack). Runtime security (Twistlock). Policy enforcement (Kyverno). GitOps deployment (ArgoCD and Flux). Tracing (Jaeger). Observability (Kiali). One values file. One helm install. That's the entire DevSecOps platform for a Kubernetes cluster, ready for a DoD accreditation boundary.

Every component in Big Bang is sourced from Iron Bank — hardened images all the way down. And because it's declarative, the entire platform state is version-controlled. Drift detection is built in. If someone kubectl edits a resource in production, Flux reconciles it back to the declared state.

The Pipeline That Ties It Together

With Iron Bank providing images and Big Bang providing the platform, the last piece is the CI/CD pipeline itself. Here's what a DoD-compliant build-scan-sign-deploy flow looks like in GitLab CI:

# .gitlab-ci.yml — DoD DevSecOps compliant pipeline
stages:
  - build
  - scan
  - sign
  - deploy

variables:
  REGISTRY: "registry1.dso.mil/ironbank"
  IMAGE_NAME: "${CI_PROJECT_NAME}"
  IMAGE_TAG: "${CI_COMMIT_SHA}"
  IMAGE: "${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}"

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.22.0
    entrypoint: [""]
  script:
    - /kaniko/executor
      --context="${CI_PROJECT_DIR}"
      --dockerfile="${CI_PROJECT_DIR}/Dockerfile"
      --destination="${IMAGE}"
      --build-arg BASE_IMAGE=${REGISTRY}/opensource/nodejs/nodejs20:20.11.0
      --cache=true

scan-container:
  stage: scan
  image: anchore/grype:latest
  script:
    - grype "${IMAGE}" --output json --file grype-report.json --fail-on critical
    - grype "${IMAGE}" --output table --file grype-report.txt
  artifacts:
    paths: [grype-report.json, grype-report.txt]
    expire_in: 1 year

scan-sast:
  stage: scan
  image: returntocorp/semgrep:latest
  script:
    - semgrep scan --config=p/owasp-top-ten --config=p/cwe-top-25 --json --output sast-report.json --error .
  artifacts:
    paths: [sast-report.json]
    expire_in: 1 year

generate-sbom:
  stage: scan
  image: anchore/syft:latest
  script:
    - syft "${IMAGE}" -o spdx-json > sbom.spdx.json
    - syft "${IMAGE}" -o cyclonedx-json > sbom.cdx.json
  artifacts:
    paths: [sbom.spdx.json, sbom.cdx.json]
    expire_in: 1 year

sign-image:
  stage: sign
  image: bitnami/cosign:latest
  script:
    - cosign sign --key ${COSIGN_PRIVATE_KEY}
      --annotations "commit=${CI_COMMIT_SHA}"
      --annotations "pipeline=${CI_PIPELINE_ID}"
      "${IMAGE}"
    - cosign attach sbom --sbom sbom.spdx.json "${IMAGE}"

deploy:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/${CI_PROJECT_NAME}
      ${CI_PROJECT_NAME}=${IMAGE}
      -n ${KUBE_NAMESPACE}
    - kubectl rollout status deployment/${CI_PROJECT_NAME}
      -n ${KUBE_NAMESPACE} --timeout=300s
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Build with Kaniko (no Docker daemon, no root). Scan with Grype and Semgrep. Generate an SBOM. Sign with cosign. Deploy with kubectl. Every artifact is retained for a year. Every scan report is audit evidence. This pipeline runs in minutes, and when it's green, the auditor has everything they need.

The Numbers

Here's the part where the skeptics stop being skeptical.

These aren't projections. They're actuals. From programs running in production on real weapons systems.

The Navy took it even further with their "Compile to Combat in 24 Hours" initiative — the goal of pushing software updates to production on a warship disconnected at sea, within 24 hours of a code merge (CNCF case study). The Marine Corps' Operation StormBreaker achieved a 17x improvement in software delivery timelines (GovCIO Media).

cATO vs. the Traditional ATO Cycle

If you've never been through a DoD Authority to Operate (ATO) process, count your blessings. If you have, you're probably already nodding along with a thousand-yard stare.

Traditional ATO is a point-in-time assessment. A team of assessors reviews your system documentation, scans your infrastructure, interviews your developers, and — if everything checks out — grants you permission to operate for three years. The timeline for this process: 6 to 18 months, with some programs reporting 18 to 24+ months and costs exceeding $3 million per assessment.

The core tension is structural. You freeze the system for months so assessors can evaluate it, but the moment you deploy an update, the assessment is technically outdated. So teams avoid updating. They batch changes into massive releases that are harder to test, harder to audit, and more likely to break. The security process designed to reduce risk ends up increasing it.

In July 2018, 18F (part of GSA) demonstrated that you could reduce the ATO timeline from months to under 30 days by automating evidence collection and baking compliance into the pipeline.

Then the DoD went further. In February 2022, the DoD CIO issued a memo on Continuous Authority to Operate (cATO), which fundamentally changes the game:

Traditional ATO:

• 6-18 months of assessment
• Valid for 3 years, then you do it all over again
• Point-in-time snapshot of compliance
• Changes require re-assessment or risk acceptance
• Encourages teams to avoid deployments

cATO:

• Continuous monitoring produces continuous evidence
• Authorization persists as long as monitoring is maintained
• Every deployment is assessed in real-time by the pipeline
• No renewal cycle — no "ATO cliff" where your authority expires
• Encourages frequent, small deployments (because each one generates compliance evidence)

The cATO model eliminates the renewal cycle entirely. Instead of a three-year ticking clock, your authorization lives as long as your continuous monitoring can demonstrate that your security posture hasn't degraded. Every pipeline run that scans, signs, and deploys is another data point proving the system is compliant. The security team doesn't audit once every three years — they have a live dashboard.

This is the single biggest structural change in DoD software delivery. It turns the compliance process from a blocker into a feature of the pipeline. Teams that would have frozen their codebase for months now deploy daily, because each deployment strengthens their compliance posture rather than undermining it.

Where This Is Heading

The SEI at Carnegie Mellon published a study in 2025 that surveyed the state of DoD software acquisition after years of reform. The findings:

• 78 acquisition programs have adopted the Software Acquisition Pathway (SWP), the DoD's streamlined acquisition process for software
• 75% of SWP programs deliver capability to users in under 6 months
• 50+ software factories are now operating across the DoD

The trend line is clear. The DoD went from "3 to 10 years" to "75% deliver in under 6 months" in roughly a half-decade. Not by writing memos about agile transformation. By building real platforms (Platform One), stocking real registries (Iron Bank), shipping real reference architectures (Big Bang), and proving them on real programs (Kessel Run, SoniKube, StormBreaker).

The programs that haven't adopted these patterns yet are the exception, not the rule. And the pressure is mounting — when your peer program is deploying 31 times a day and you're stuck in a 14-month ATO cycle, the questions from leadership get uncomfortable fast.

The DevSecOps revolution in the DoD isn't coming. It already happened. The question now is how fast the long tail of legacy programs catches up to what the leading edge proved five years ago.

---

Sources

• CNCF DoD Case Study: https://www.cncf.io/case-studies/dod/
• CNCF Blog — Kubernetes on F-16s and Battleships: https://www.cncf.io/blog/2020/05/07/with-kubernetes-the-u-s-department-of-defense-is-enabling-devsecops-on-f-16s-and-battleships/
• Platform One / Iron Bank: https://p1.dso.mil/ironbank
• Iron Bank Public (IL2): https://repo1.dso.mil/dsop
• Big Bang (GitHub): https://github.com/DoD-Platform-One/bigbang
• Platform One: https://p1.dso.mil
• SEI/CMU Study on DoD DevSecOps: https://www.sei.cmu.edu/news/sei-study-on-defense-department-devsecops-finds-excellence-and-opportunities/
• 18F — Taking the ATO Process from 6 Months to 30 Days: https://18f.gsa.gov/2018/07/19/taking-the-ato-process-from-6-months-to-30-days/
• DoD CIO cATO Memo (Feb 2022): https://dodcio.defense.gov/
• DoD DevSecOps Reference Design: https://dodcio.defense.gov/Library/
• Air & Space Forces Magazine (Kessel Run coverage): https://www.airandspaceforces.com/
• Rise8 (Kessel Run analysis): https://rise8.us/
• ExecutiveGov (Platform One reporting): https://executivegov.com/
• Breaking Defense (Platform One reporting): https://breakingdefense.com/
• GovCIO Media (Operation StormBreaker): https://governmentciomedia.com/