The DoD DevSecOps Reference Design Explained

The DoD DevSecOps reference design is not a shopping list.

The best known 2021 document is also not the current baseline.

Its Kubernetes architecture can still teach useful patterns for software factories, artifact flow, shared services, security services, and promotion. But the document states that it automatically expires one year after publication unless revised. A team that copies its boxes today without reading the current DoD Enterprise DevSecOps Fundamentals and cATO guidance is building from stale authority.

This guide explains what the DoD DevSecOps reference design contained, what changed, how the current ten phase lifecycle works, which controls deserve priority, and what evidence a modern software factory should produce. It supports the DevSecOps insights hub and the GS Consulting DevSecOps and secure software supply chain service.

The Short Answer

The DoD Enterprise DevSecOps Reference Design for CNCF Kubernetes, version 2.1, was published in September 2021. It described a product neutral but Kubernetes specific enterprise pattern. Certified Kubernetes was the production environment. Containers were the standard deployment unit. The design connected software factory services, a local artifact repository drawing from Iron Bank, a service mesh, cloud native access, and shared security services.

The same document says it automatically expires one year from publication unless revised. That sentence changes how the design should be used. It is an expired reference pattern, not a current universal mandate.

The current anchor is the DoD Enterprise DevSecOps Fundamentals version 2.5, approved in October 2024. It defines the operating concepts and ten phase lifecycle. It also states plainly that a DevSecOps implementation does not require a specific architecture, container technology, or cloud.

Read the Document Stack in the Right Order

1. Current Fundamentals. Start with the 2024 lifecycle, roles, software factory concepts, security integration, and tailoring principle.
2. Current authorization guidance. Read the DoD cATO implementation guide and cATO evaluation criteria for the operating capabilities and evidence expected in a continuous authorization model.
3. Current secure development guidance. Use the final NIST Secure Software Development Framework for organizational and development practices.
4. Current software supply chain guidance. Use NIST SP 800-204D for CI/CD supply chain strategies and SLSA version 1.2 for progressive build provenance and hardening concepts.
5. Historical reference designs. Reuse architecture patterns only after the team maps them to the current mission, system boundary, providers, authorization approach, and product reality.

What the Reference Architecture Was Trying to Solve

The durable idea was not “buy Kubernetes.” The durable idea was a controlled path from approved source to a known artifact running in a monitored environment.

A useful modern architecture has five layers.

1. Infrastructure and environment. Compute, network, storage, identity, cryptographic services, logging, isolation, baseline configuration, availability, and recovery.
2. Platform and software factory. Reusable build and deployment services, approved components, secrets, policy, artifact storage, evidence capture, support, and platform operations.
3. Application pipelines. Source protection, review, testing, build, provenance, artifact promotion, release approval, deployment, and rollback.
4. Mission applications. Runtime identities, dependencies, configuration, data paths, health, exposure, ownership, and mission behavior.
5. Monitoring and authorization evidence. Continuous monitoring, active cyber defense, exceptions, change history, metrics, control evidence, and risk decisions.

The products inside each layer can change. The trust boundaries and authority should not disappear when a product changes.

The Current DoD DevSecOps Lifecycle

The 2024 Fundamentals name ten phases: Plan, Develop, Build, Test, Release, Deliver, Deploy, Operate, Monitor, and Feedback.

Those phases are not ten disconnected tool categories. They are a continuous operating loop.

• Plan defines mission need, requirements, architecture, threats, risk, backlog, and acceptance.
• Develop creates source, infrastructure definitions, tests, review records, and documentation.
• Build converts controlled inputs into an identified artifact under a known builder and process.
• Test checks function, security, policy, dependencies, interfaces, and mission behavior.
• Release makes the authority decision for an exact version and evidence set.
• Deliver moves the approved artifact through controlled repositories and environments.
• Deploy changes the target environment under approved identity, configuration, and rollback rules.
• Operate runs the service, protects it, supports users, handles incidents, and owns reliability.
• Monitor observes health, vulnerabilities, configuration, behavior, threats, and control performance.
• Feedback returns operational evidence and mission learning to planning and engineering.

The distinction between Release, Deliver, and Deploy matters. Approval can apply to an exact artifact. Delivery can preserve its identity through repositories. Deployment can prove where and how it was installed. If those records collapse into one generic “pipeline succeeded” event, the authorization evidence is weak.

Original Research: The GS DoD DevSecOps Modernization Priority Index

GS Consulting built the DoD DevSecOps Modernization Priority Index to answer one decision: which capabilities should a program validate first when it applies the old reference design under current guidance?

The index scores ten capabilities from zero to 100. The formula assigns 25 percent to mission dependency, 25 percent to trust boundary impact, 20 percent to evidence reuse, 15 percent to change exposure, and 15 percent to recovery leverage. Each factor receives a GS analyst rating from one to five based on the cited public guidance.

Evidence and cATO governance scores 100. Identity and least privilege, build isolation and provenance, and continuous monitoring and cyber defense each score 97. Artifact repository and promotion scores 94. These capabilities rank first because they connect authority to actual changes across trust boundaries and preserve proof that can be reused through releases and operations.

Automated security testing scores 83. That does not make testing optional. It exposes a common imbalance: programs often buy scanners before they can bind findings to an owner, exact source, exact build, release decision, deployed version, exception, and operating result.

A sensitivity case shifts five weight points from trust boundary impact to mission dependency. The main ordering remains stable and no score moves more than one point. The model data, source register, formulas, and limitations are included in the research package.

Planning caveat: The index is a GS Consulting derived planning tool based on cited public sources and documented assumptions. It is not an official legal, audit, compliance, authorization, DoD, NIST, SLSA, or regulatory determination.

The Controls That Matter Before the Tool List

Identity and separation of duties

Separate source administration, build service identity, artifact administration, release authority, deployment identity, platform administration, and evidence review where risk requires it. One broad automation identity can turn a fast pipeline into one large trust failure.

Source, build, and artifact identity

Bind an approved change to the exact source commit, build recipe, builder, dependencies, generated artifact, provenance, signature, repository location, promotion record, and deployment receipt. SLSA gives teams a clear progression from available provenance to hosted, signed, and hardened build controls.

Finding disposition

A scan result is not a decision. Record the affected component, severity, exploitability, exposure, owner, due date, release effect, exception authority, conditions, expiration, and closure proof. The companion article on automating DevSecOps pipelines with AI shows where automation can summarize and route this evidence without receiving unchecked release authority.

Environment promotion and rollback

Define approved source repositories, build environments, artifact repositories, promotion paths, deployment identities, target environments, stop rules, rollback evidence, and recovery tests. A copied architecture diagram does not answer which exact object may cross each boundary.

Operations feedback

Vulnerabilities, incidents, health, configuration drift, mission failure, exploitation data, and recovery performance must return to the backlog and control design. The broader DevSecOps operating model guide explains this loop in detail.

How cATO Changes the Evidence Standard

Continuous authorization is not “the pipeline is automated, so the ATO is continuous.” The current DoD guide describes core capabilities that include continuous monitoring, active cyber defense, and use of an approved DevSecOps reference design or equivalent activities. The responsible authorization authority still decides whether the system and evidence support the approach.

A practical cATO evidence model connects four views:

1. What is inside the boundary. Systems, providers, data, identities, environments, dependencies, controls, and owners.
2. What changed. Requirement, source, review, tests, build, components, artifact, approval, deployment, and configuration.
3. What is happening now. Health, threats, vulnerabilities, incidents, drift, exceptions, control performance, and cyber defense activity.
4. Who accepted risk. Decision authority, evidence reviewed, scope, conditions, expiration, remediation, and follow up.

Evidence should be generated as part of delivery and operation. A screenshot drive assembled before a review is not a continuous control system.

A Practical Implementation Sequence

1. Define the mission and release risk. Name the users, data, operational effect, release cadence, threat exposure, availability need, and recovery objective.
2. Map the current delivery path. Trace source, build, dependencies, test, artifacts, approvals, deployment, runtime, monitoring, incidents, and evidence. Include every provider and service identity.
3. Set the system and trust boundary. Decide which services are inherited, shared, program owned, or external. Assign evidence and exception ownership.
4. Select architecture patterns. Choose container, virtual, cloud, and on premises patterns for the actual workload. Document why the pattern fits rather than invoking the 2021 diagram as authority.
5. Bind the release record. Connect the exact change, tests, build, provenance, artifact, SBOM, finding disposition, approval, deployment, runtime result, and rollback state.
6. Test failure paths. Exercise compromised source, untrusted dependency, build failure, signature failure, unsafe finding, approval denial, deployment failure, drift, incident, and rollback.
7. Measure operations. Review lead time, failed change rate, time to restore, vulnerability age, exception age, evidence completeness, provenance coverage, unauthorized change, and recovery proof.

The Minimum Release Evidence Packet

Every release should tell one coherent story: an approved requirement changed controlled source, a known builder produced an identified artifact, relevant checks ran, findings received disposition, an authorized person or rule approved the exact release, a controlled identity deployed it, and operations verified the result.

The Bottom Line

The DoD DevSecOps reference design still has value if it is read as an expired architecture pattern and not a current product mandate. The current Fundamentals give teams room to choose the architecture. That flexibility increases the need for explicit trust boundaries, artifact identity, release authority, monitoring, cyber defense, recovery, and evidence.

The operating standard is decisive: no copied stack without current authority, no release without exact artifact identity, and no continuous authorization without continuous proof.

Research Sources and Caveats

The GS DoD DevSecOps Modernization Priority Index, document stack, architecture layers, decision path, failure modes, and evidence packet are derived planning tools. They are not official legal, audit, compliance, authorization, DoD, NIST, SLSA, or regulatory determinations.

• DoD Enterprise DevSecOps Reference Design for CNCF Kubernetes
• DoD Enterprise DevSecOps Fundamentals version 2.5
• DoD cATO Implementation Guide
• DoD cATO Evaluation Criteria
• NIST Secure Software Development Framework version 1.1
• NIST SP 800-204D
• SLSA version 1.2