The Big Picture: In modern multi-domain operations, fighting alongside coalition partners is the operational baseline. Yet allied forces frequently find themselves isolated by rigid network enclaves, exchanging mission-critical target data over voice radio or manual file transfers. The barrier to data sharing is rarely network bandwidth; it is an Identity, Credential, and Access Management (ICAM) challenge.

Why It Matters

Static network enclaves do not protect sensitive intelligence — they paralyze decision-making. When data cannot flow safely across organizational boundaries at machine speed, commanders are forced to choose between security compliance and operational velocity. Solving coalition interoperability requires shifting from static perimeters to software-defined Zero Trust ICAM architectures.

The Details

• Perimeters create operational friction: Physical and cryptographic air-gaps build rigid silos. Secure data sharing requires protecting data at the object and API level, not isolating entire networks.
• Federated ICAM is essential for combined operations: Open standard federation (OIDC/SAML2) and workload identity protocols (SPIFFE/SPIRE) allow partner organizations to authenticate using native identity providers while host applications enforce zero-trust authorization locally.
• Attribute-Based Access Control (ABAC) enables dynamic policy: Role-Based Access Control breaks down across multi-national agreements. ABAC evaluates user attributes, sensitivity levels, organizational affiliation, and environmental context in real time.
• Commercial Off-The-Shelf (COTS) software proxies streamline integration: Replacing custom hardware cross-domain devices with containerized, software-defined API gateways dramatically reduces latency, simplifies updates, and enables continuous security auditing.

Go Deeper

The Multi-National Data Sharing Challenge

For decades, military command-and-control architectures relied on physical network segregation to satisfy security guidance. Command posts routinely operated separate hardware terminals on a single desk: one for organic feeds, another for coalition partners, and additional terminals for unclassified mission participants.

This hardware-bound security model creates a “manual transfer bottleneck.” When an analyst on one network identifies a time-sensitive target, sharing that detection with an allied unit often requires manually drafting a redacted text summary, copying it across a physical guard, and re-entering the data into the partner system. By the time the coordinates arrive, the operational window has passed.

In JADC2 and the Software-Defined Battlefield, I wrote that command-and-control is fundamentally a distributed systems problem. In a coalition context, it is specifically a distributed trust problem. The goal is not to merge independent networks into a single monolith, but to build a data fabric where trust is verified dynamically for every API request.

Federated ICAM at the Tactical Edge

To share data safely in real time, systems must answer two core questions instantly:

1. Authentication: Who or what is requesting access (user or automated workload)?
2. Authorization: Does this entity have permission to receive this specific payload under these current conditions?

National sovereignty dictates that partner organizations will not manage accounts inside a centralized external database. Federated ICAM solves this by establishing cryptographic trust between independent Identity Providers (IdPs):

• Human Identity Federation: Using OIDC or SAML 2.0, allied operators authenticate against their home organization’s IdP. The host application verifies the digital signature of the issuing IdP against a trusted registry and extracts user claims without storing foreign passwords.
• Workload Identity for Automated Services: Automated microservices and sensor nodes use SPIFFE/SPIRE to receive short-lived cryptographic identity documents (SVIDs). Authentication occurs at the transport layer via mutual TLS (mTLS) without human intervention.

Moving from RBAC to Dynamic ABAC

Once identity is established, traditional systems rely on Role-Based Access Control (RBAC). In combined operations, RBAC breaks down quickly: a role like Analyst carries different definitions across different nations. Furthermore, RBAC cannot account for object-level releasability caveats.

Attribute-Based Access Control (ABAC) evaluates policy rules at request time across four key dimensions:

1. Subject Attributes: Citizenship, clearance tier, organizational unit.
2. Resource Attributes: Sensitivity level, releasability caveats, expiration.
3. Action Attributes: Read, export, stream.
4. Environment Attributes: Threat condition, operational zone, transport encryption.

By expressing security policy as code (using tools like Open Policy Agent), authorization rules are declared in Git and deployed via GitOps. If a resource contains sensitive sub-fields, the zero-trust proxy dynamically redacts restricted keys before transmitting the response.

Modern COTS Proxies vs. Legacy Hardware Guards

Cross-domain data sharing between security domains historically required custom hardware appliances. While custom hardware remains appropriate for extreme high-to-low transfers, using it for same-level partner data sharing introduces friction: hardware boxes are proprietary, difficult to patch, and add significant latency.

Modern software architectures leverage containerized Commercial Off-The-Shelf (COTS) API gateways paired with policy sidecars. By wrapping mission APIs in a zero-trust proxy:

• Inbound API requests are intercepted at the ingress layer.
• Identity claims and environmental context are passed to a local policy engine.
• Restricted payload fields are stripped in transit.
• Cryptographically hashed audit logs feed the system’s Continuous ATO (cATO) compliance pipeline.

The Bottom Line

Software-defined tactical data sharing replaces static hardware isolation with data-centric protection. When identity becomes the perimeter, data moves at the speed of relevance — granting joint and allied forces a decisive operational advantage.

The Big Picture: Every security framework lists credential exposure as a critical risk. Yet the most common finding on enterprise defense program assessments is still a hardcoded password or a static API key committed to a repository years ago. The fix is a secrets architecture that makes embedding credentials technically harder than doing the right thing.

Why It Matters

A secret in a local config file is an authenticator management finding. A secret in git history — even after a force-push — is a finding that may have already been exfiltrated. A secret that never rotates is a finding that compounds daily. Defense pipelines running Continuous ATO (cATO) need secrets management wired directly into their compliance evidence stream.

The Details

• Static credentials are a structural problem: The only reliable fix is making dynamic, short-lived credentials the path of least resistance for developers.
• Tools solve different layers of the problem: Secrets brokers (Vault) handle runtime injection; SOPS handles encrypted secrets-as-code; External Secrets Operator (ESO) bridges the two for Kubernetes.
• Enterprise platforms provide the reference architecture: Hardened baseline platforms handle identity and secrets plumbing so application teams can focus on least-privilege policies.
• Rotation events must feed compliance evidence: A secret that rotates without producing machine-readable evidence does not satisfy Continuous ATO requirements.

Go Deeper

Why Hardcoded Credentials Persist

Hardcoded credentials appear because they work immediately, require no setup, and defer consequences. A developer connecting a pipeline at 11 PM pastes a static connection string and moves on.

The structural issue is that many defense programs deploy secrets managers but fail to integrate them into developer workflows. Credentials end up in environment variables or raw configuration files outside version control or audit trails. Under frameworks like NIST SP 800-53 (IA-5 Authenticator Management), static service credentials create open findings that automated scans catch instantly.

Dynamic Secrets Architecture

Secrets brokers operate by issuing credentials at runtime. Instead of embedding static passwords into application configs, workloads request temporary access on demand:

• Dynamic Credentials: Applications authenticate to the broker using native platform tokens (e.g. Kubernetes service accounts) and receive short-lived database or API credentials with a strict Time-To-Live (TTL). When the TTL expires, the credential is revoked automatically.
• PKI for Workload mTLS: In Zero Trust architectures, service-to-service communication requires mutual TLS certificates. Secrets managers issue dynamic X.509 certificates with short lifespans (24–72 hours), eliminating manual PKI overhead.
• Encrypted Storage & Audit Logging: Static tokens or legacy API keys are stored in encrypted key-value engines with complete audit logging for every read or modification.

Secrets-as-Code for GitOps Workflows

While dynamic secrets manage runtime access, infrastructure-as-code repositories require a solution for sensitive parameters in manifests or deployment templates.

SOPS (Secrets OPerationS) allows teams to store encrypted values directly in version-controlled repositories while keeping file structures readable. Key values are encrypted using cloud KMS or local key management, allowing developer teams to review configuration changes via standard Pull Requests without exposing plaintext credentials in Git.

Bridging to Kubernetes with External Secrets Operator

Running sidecars on every container adds operational overhead, while manually decrypting secrets in CI/CD pipelines can leave unencrypted artifacts in cluster storage.

The External Secrets Operator (ESO) bridges this gap. ESO runs as an in-cluster controller that fetches credentials from external secret stores (Vault, AWS Secrets Manager, Azure Key Vault) and generates native Kubernetes secrets automatically. When a secret rotates at the source, ESO syncs the update to the cluster on a scheduled interval without manual developer intervention.

Wiring Rotation into the cATO Evidence Stream

Most implementations stop short of full compliance integration. A secrets manager rotates credentials on schedule, but the Authorizing Official (AO) has no visibility into whether rotation requirements are met.

Connecting secrets management to a Continuous ATO (cATO) pipeline requires an automated evidence loop:

1. Audit Logs: Secrets brokers emit log events for every lease renewal, credential issuance, or policy modification.
2. Event Parsing: Log collectors filter rotation events and map them to control IDs (e.g., IA-5 Authenticator Management).
3. OSCAL Evidence Generation: Events are formatted into machine-readable OSCAL Assessment Results and streamed directly into the compliance dashboard.

Instead of presenting static screenshots during annual reviews, the program provides continuous, machine-generated proof that authenticators are rotated within policy windows.

Common Pitfalls to Avoid

• Unintegrated Auth Methods: Deploying a secrets broker but relying on static admin tokens in pipeline variables recreates the original vulnerability inside the secrets manager.
• Informal Key Management: Encrypting repository files with personal keys creates key-person dependencies. Encryption keys must reside in central key management services with audit logging.
• Untested Rotation: Rotation policies that have never been exercised in live environments are configuration artifacts, not active security controls. Credential refresh must be verified under operational loads.

The Bottom Line

Secrets management is the operational plumbing beneath modern defense applications. The tools are mature and open-source — the differentiator is integration depth. Programs that combine dynamic brokers, secrets-as-code, and automated rotation streams turn complex compliance findings into automated, verifiable security guardrails.

Why It Matters

Half the time lost on a defense software program is spent finding the authoritative document or the right tool, not reading it. Bookmark this page instead. Every link is the primary source or the working tool — no vendor summaries in between.

The Details

• Policy & Strategy: The DoD-level documents that set the rules — CSRMC, DoDI 8510.01, the Zero Trust Strategy, cATO criteria.
• NIST Publications: The control catalogs and frameworks the evidence maps to.
• Platforms & Pipeline Tools: Platform One services and the open-source tools that produce the evidence.
• Compliance & Training: CMMC bodies, assessment portals, and where to build the skills.

Bolding indicates resources I use or have used directly; non-bolded links are curated for reference. Verify the current version of any policy document before citing it — issuances change.

Go Deeper

Resource Index

• DoD Policy & Security Strategy
  • DoD CIO Cybersecurity Risk Management Construct (CSRMC) — the RMF replacement; covered in my RMF 2.0 post
  • CSRMC Strategic Tenets — the ten tenets, one page each
  • DoDI 8510.01 — Risk Management Framework for DoD Systems — still the issuance of record during transition
  • Continuous ATO Evaluation Criteria — what the DoD actually checks; pairs with my cATO post
  • DoD Zero Trust Strategy — the FY2027 mandate; covered here
  • DoD AI Cybersecurity Risk Management Tailoring Guide — how models get authorized; covered in ATO for AI Systems
  • EO 14028 — Improving the Nation’s Cybersecurity — the order behind SBOM and ZT mandates
  • DoD CIO Library — the index of record when you need the current version of anything above
• NIST Security Publications & Frameworks
  • SP 800-37r2 — Risk Management Framework — the framework CSRMC restructures
  • SP 800-53r5 — Security and Privacy Controls — the control catalog everything maps to
  • SP 800-171r3 — Protecting CUI — the CMMC Level 2 baseline
  • SP 800-172 — Enhanced Requirements for CUI — the Level 3 delta
  • SP 800-207 — Zero Trust Architecture — the ZT reference model
  • SP 800-218 — Secure Software Development Framework — the EO 14028 development standard
  • SP 800-161r1 — Supply Chain Risk Management — the C-SCRM practices behind the SR controls
  • OSCAL — Open Security Controls Assessment Language — machine-readable compliance; the foundation of cATO evidence
  • NIST AI Risk Management Framework — Govern, Map, Measure, Manage
  • SP 800-53 Control Overlays for Securing AI Systems (COSAIS) — the AI overlays, drafts landing Q3 2026
• Platform One & DoD Cloud Services
  • Platform One — the DoD DevSecOps platform; the reference cATO implementation
  • Iron Bank — hardened container registry with inheritance-ready assessments
  • Iron Bank Documentation — onboarding and hardening requirements for getting an image accepted
  • Big Bang — the P1 Kubernetes baseline (Istio, Kyverno, Falco) as code
  • Repo One — DoD source repository; pipelines with mandatory policy gates
  • DoD Cyber Exchange — STIGs, SRGs, and cyber policy in one place
  • DISA STIGs — the hardening baselines assessors check against
  • NSA/CISA Kubernetes Hardening Guidance — the K8s baseline worth reading before the STIG
• Pipeline Security & DevOps Tooling
  • Open Policy Agent — policy as code; the engine behind most pipeline gates (my PaC post)
  • Kyverno — Kubernetes-native policy; easier entry than Rego for K8s-only shops
  • OPA Gatekeeper — OPA as a K8s admission controller
  • Checkov — IaC scanning for Terraform, CloudFormation, K8s manifests
  • Trivy — container and dependency scanning plus SBOM generation in one pass
  • Semgrep — SAST with writable rules; tune it for LLM failure modes (why that matters)
  • Argo CD — GitOps controller; declarative state reconciliation (the GitOps case)
  • Flux — the other GitOps controller; lighter footprint, same principle
  • detect-secrets — pre-commit secret scanning; cheapest control you’ll ever implement
• Supply Chain & SBOM Security
  • Syft — SBOM generation for containers and filesystems; SPDX and CycloneDX output
  • Grype — vulnerability correlation against the SBOM
  • cdxgen — CycloneDX-native generation; strongest polyglot support
  • OWASP Dependency-Track — continuous SBOM monitoring against new CVEs
  • Sigstore / cosign — artifact signing and verification
  • SLSA — supply chain integrity levels; the provenance framework
  • SPDX — the ISO SBOM format
  • CycloneDX — the OWASP SBOM format; native VEX support
  • CISA SBOM Resources — minimum elements and current guidance (my SBOM post)
  • OSV — open source vulnerability database
  • NVD — the National Vulnerability Database
• CMMC, Compliance & Security Assessment
  • CMMC Program (DoD CIO) — the official program page; start here, not with vendors (my CMMC post)
  • The Cyber AB — the accreditation body; C3PAO marketplace
  • DIBNet — the 72-hour incident reporting portal; know it before you need it
  • eMASS (DCSA) — where authorization packages live
  • Lula — validates K8s state against OSCAL-defined controls
  • Compliance Trestle — the OSCAL SDK for automating SSP and assessment artifacts
  • FedRAMP — cloud service authorization; the inheritance source for most SaaS controls
• Getting Started: Education & Training
  • DoD Cyber Exchange Training — free role-based training, including RMF and ZT courses
  • Defense Acquisition University — acquisition and cybersecurity credentials; free for the workforce
  • CIS Critical Security Controls — the threat-informed control set behind Army RMF 2.0’s baseline
  • MITRE ATT&CK — the adversary behavior catalog; the “threat” in threat-informed
  • NIST RMF Small Enterprise Quick Start — the plain-language RMF walkthrough
  • The Secure Delivery series on this blog — GitOps → Policy as Code → Zero Trust → CMMC → SBOM → cATO, in reading order

TOC

The Bottom Line

A trusted DevSecOps ecosystem relies on authoritative primary sources, continuous scanning, and standardized platform infrastructure. Bookmark these core references to ground your software delivery pipelines in verified standards rather than vendor noise.

The Big Picture: The traditional Authority to Operate process takes 18 months to produce a compliance document no one reads. Continuous ATO replaces the annual gate with an automated evidence pipeline wired directly into CI/CD.

Why It Matters

Modern software deploys dozens of times per week. An ATO issued against a point-in-time assessment becomes stale the moment the first patch lands. Continuous ATO eliminates the authorization debt by treating security control evidence as a first-class artifact of every build — the Authorizing Official sees a live dashboard, not a six-month-old snapshot.

The Details

• OSCAL as the foundation: NIST’s Open Security Controls Assessment Language provides the machine-readable schema that makes continuous evidence collection possible — policies, assessments, and system security plans expressed as JSON or XML, not Word documents.
• Policy gates in the pipeline: Every CI commit is validated against security controls before merge — SAST, container scanning, dependency checks, and configuration compliance run as mandatory pipeline stages, not post-deployment audits.
• Real-time AO visibility: The Authorizing Official gets a live control inheritance dashboard showing current pass/fail status across all 110+ controls, with automated alerts when a new deployment changes the risk posture.

Go Deeper

Why the Legacy ATO Process Fails

The traditional Risk Management Framework (RMF) ATO process — defined in NIST SP 800-37 — was designed for static systems with infrequent change cycles. A weapons system that deploys firmware once every two years can reasonably be assessed at a point in time. A web application that merges 50 pull requests per week cannot.

The failure modes are structural:

1. Evidence is a snapshot, not a stream. A System Security Plan (SSP) documents what the system looked like when the assessor visited. The moment a developer commits new code, the evidence is stale. Traditional RMF has no mechanism to continuously reconcile the documented state against the deployed state.

2. The authorization cycle creates security debt. When an ATO takes 12–18 months, program teams learn to batch changes. Security improvements are deferred until the next authorization cycle rather than deployed incrementally. The result is a system that is simultaneously over-documented and under-secured.

3. Assessors become bottlenecks, not advisors. When security professionals spend the majority of their time writing and reviewing documentation artifacts, they have little capacity to engage with engineering teams on actual risk reduction. The process rewards documentation quality, not security posture.

What Continuous ATO Actually Is

Continuous ATO (cATO) is not a shortcut around the RMF. It is the implementation of RMF’s Step 6 — Monitor as a continuous, automated process rather than a periodic manual review. The authorization itself remains a formal AO decision; cATO changes the evidence cadence from annual to real-time.

The DoD defines cATO through DoDI 8510.01 and the associated cATO Reference Design published by the DoD CIO. The framework requires three foundational capabilities:

1. An active Authorizing Official who accepts ongoing risk rather than point-in-time risk.
2. Automated security controls assessment integrated into the delivery pipeline.
3. Continuous monitoring with real-time visibility into the system’s security posture.

Platform One — the DoD’s DevSecOps platform — operationalized this framework and demonstrated that programs meeting these requirements could receive ongoing authorization without repetitive full assessment cycles.

The OSCAL Foundation

NIST’s Open Security Controls Assessment Language (OSCAL) is the technical enabler that makes machine-readable cATO possible. OSCAL defines a standard schema for expressing:

• System Security Plans (SSP) — control implementations documented as structured data
• Assessment Plans and Results — automated test outputs mapped directly to control objectives
• Plan of Action & Milestones (POA&M) — open findings tracked as versioned data artifacts
• Component Definitions — reusable control implementations for common infrastructure (cloud providers, container platforms, identity services)

The practical implication: instead of a security engineer manually updating a 400-page Word document after every infrastructure change, the SSP is generated from Infrastructure-as-Code annotations and pipeline metadata. A Terraform module that provisions an S3 bucket with encryption-at-rest can assert — in machine-readable OSCAL — that it satisfies SC-28 (Protection of Information at Rest). The assessment tool reads the assertion and validates it against the actual deployed configuration.

Tools supporting OSCAL include Trestle (IBM’s open-source OSCAL SDK), Lula (DoD’s compliance validation tool that evaluates Kubernetes configurations against OSCAL-defined controls), and eMASS (the DoD’s enterprise OSCAL consumer that ingests assessment results for AO review).

The Four Technical Layers

A production cATO implementation requires four distinct layers operating in concert:

1. Policy Gates (Shift-Left Enforcement)

Security controls are validated at the earliest possible point in the development lifecycle — on the developer’s workstation and in the CI pipeline before code reaches a review stage.

• Pre-commit hooks: Lightweight checks using detect-secrets, Checkov, and Trivy catch obvious violations before they enter the codebase.
• CI pipeline gates: Every pull request triggers a full policy evaluation suite — SAST (Semgrep, SonarQube), dependency scanning (Grype, Dependabot), container image scanning (Trivy, Anchore), and IaC compliance (Checkov, OPA/Conftest).
• Admission controllers: In Kubernetes environments, Kyverno or OPA Gatekeeper enforce policy at the runtime layer — non-compliant workloads are rejected before scheduling, regardless of what passed in CI.

The critical design principle: every pipeline gate must produce a structured evidence artifact, not just a pass/fail exit code. The artifact feeds directly into the OSCAL assessment results layer.

2. Evidence Collection and Control Mapping

The output of every automated control check must be mapped to a specific NIST SP 800-53 or SP 800-171 control. This mapping — connecting a technical test result to a compliance control objective — is what makes automated evidence admissible for AO review.

Lula operationalizes this in Kubernetes environments by defining LulaValidations: YAML-configured checks that query the cluster state and evaluate whether a specific control is satisfied. A LulaValidation for AC-3 (Access Enforcement) might query all ClusterRoleBindings, verify that no wildcards are present in production namespaces, and emit an OSCAL-formatted finding.

The evidence chain for a single deployment:

CI Build   -> Trivy scan    -> SARIF output -> OSCAL converter -> Assessment Result
IaC Plan   -> Checkov scan  -> JUnit output -> OSCAL converter -> Assessment Result
K8s Deploy -> Lula validate -> OSCAL Assessment Result (native output)
All Results -> Aggregate into SSP Assessment Layer -> Ingest into eMASS / AO dashboard

3. Continuous Monitoring Dashboard

The Authorizing Official needs a single view answering three questions at any moment: What is the current control status? What changed since the last authorization decision? What is the residual risk posture?

DISA’s SRG compliance dashboards, Grafana-based OSCAL viewers, and platform-specific tools like Platform One’s Party Bus monitoring stack provide this visibility. The dashboard must reflect the live deployment state — not a static report uploaded weekly.

When a new CVE is published against a library in a production container, the monitoring layer should:

1. Identify affected containers within minutes via SBOM correlation
2. Automatically open a POA&M entry linked to the CVE, affected components, and risk rating
3. Notify the AO that the risk posture has changed
4. Track the patch through the pipeline and automatically close the POA&M when a clean build reaches production

4. Control Inheritance and Component Reuse

The capability that pays for itself fastest in a mature cATO program is control inheritance — the ability for multiple systems to inherit control implementations from a shared platform rather than re-documenting them independently.

Platform One’s Iron Bank (the DoD’s hardened container registry) and the associated Big Bang Kubernetes platform ship with pre-assessed OSCAL component definitions. A program team deploying on Platform One inherits the platform’s container hardening controls, FIPS-compliant cryptography, and network policy implementations — reducing the controls the program must independently implement and evidence from 110 to roughly 40–60, depending on the system profile.

This is the mechanism that makes cATO scale across the enterprise. A shared platform assessed once provides inheritance to every tenant program — the investment in platform-level evidence compounds across the portfolio.

Platform One as the Reference Implementation

The DoD’s Platform One program demonstrated cATO at scale for classified and unclassified DoD workloads:

Programs onboarding to Platform One receive a dramatically reduced authorization surface. The platform’s existing cATO covers the infrastructure layer; program teams focus exclusively on their application-specific controls.

Where Programs Actually Fail

1. Treating cATO as a one-time setup. The pipeline must produce current evidence on every deployment. Programs that configure tooling, generate an initial evidence package, and stop updating it have built a sophisticated point-in-time assessment — not continuous authorization. The cATO architecture is only as good as its cadence.

2. Evidence without control mapping. A Trivy scan producing a vulnerability list is not admissible OSCAL evidence. The evidence must be mapped to specific control objectives with a clear assertion: this result satisfies (or does not satisfy) RA-5 (Vulnerability Monitoring and Scanning). Programs that produce raw tool outputs without the OSCAL mapping layer cannot support AO review.

3. Incomplete inheritance documentation. Teams using cloud services or shared platforms without documenting the inheritance relationship enter assessments with undocumented control gaps. The SSP must explicitly identify which controls are inherited, from which provider or platform, and what residual responsibility the program retains.

4. No AO engagement during development. Continuous ATO requires a culturally engaged Authorizing Official — one who reviews the risk posture dashboard regularly, not one who signs the package at the end. Programs that treat the AO as a final approver rather than a continuous stakeholder find that the authorization decision still becomes a bottleneck regardless of how automated the evidence pipeline is.

5. POA&M management outside the pipeline. Open findings tracked in spreadsheets outside the automated pipeline degrade cATO effectiveness quickly. POA&M entries must be created automatically from evidence failures, linked to specific pipeline runs, and closed automatically when remediation is verified by a subsequent successful evidence collection.

The CMMC Connection

cATO and CMMC 2.0 are not the same framework, but they share significant technical overlap. The automated control evidence pipeline that satisfies DoD RMF assessment requirements is largely the same infrastructure that satisfies CMMC Level 2 assessment evidence requirements.

Organizations implementing cATO for a DoD program find that the OSCAL evidence artifacts, pipeline gate configurations, and continuous monitoring dashboards significantly reduce the manual documentation burden during a C3PAO assessment. The assessor can query the live system state rather than reviewing static screenshots — a qualitatively different assessment experience.

The SR (Supply Chain Risk Management) controls added in NIST SP 800-171 Rev 3 — flowing into CMMC via the 2024 rulemaking — align directly with cATO’s SBOM and dependency tracking requirements. An organization with a functioning cATO pipeline that includes SBOM generation and vulnerability correlation already has the evidence infrastructure for SR control satisfaction.

The Bottom Line

Continuous ATO is the correct answer to an unsolvable problem: you cannot write documentation fast enough to keep pace with modern software delivery. The solution is not to slow down delivery — it is to make the evidence generation automatic, the control mapping machine-readable, and the authorization decision continuous.

The tooling is mature. OSCAL is stable. Platform One has demonstrated the model at DoD scale. The programs that implement cATO correctly — with genuine pipeline integration, control-mapped evidence, and an engaged AO — compress their authorization timelines from 18 months to weeks and maintain continuous authorization through the life of the system.

The programs that treat cATO as a documentation shortcut will find the AO’s dashboard showing red controls and a risk posture they cannot explain. The difference is not the tools — it is whether the evidence pipeline is genuinely wired into how software ships.

The Big Picture: The Risk Management Framework authorizes a system as it existed on assessment day — but an AI model’s behavior shifts with every retrain, every fine-tune, and every drift in production data. The DoD’s answer so far: the model doesn’t get its own ATO at all.

Why It Matters

Every DoD program fielding AI is improvising an answer to the same question: what did the AO actually authorize, and is it still what’s running? The traditional ATO has no vocabulary for behavior change without a code change. Until it does, programs sit stuck at the accreditation gate — or operate on paperwork describing a model that no longer exists.

The Details

• Models don’t get ATOs — systems do. The DoD AI Cybersecurity Risk Management Tailoring Guide routes AI models through the RMF Assess Only construct: the model produces a body of evidence (T&E results, change management records, acquisition documentation) that gets folded into the hosting system’s authorization package.
• The control catalog is catching up. NIST’s SP 800-53 Control Overlays for Securing AI Systems (COSAIS) — five publications covering generative AI, predictive AI, agents, and developer use cases — hit public draft in Q3 2026, with the full set expected in 2027.
• Congress made it contractual. The FY2026 NDAA directs the DoD to build an AI/ML security framework and wire it into DFARS and CMMC — meaning contractors who develop, host, or deploy AI for the Department will have to evidence compliance the same way they evidence CUI protection today.

Go Deeper

Where the RMF Assumptions Break

The RMF, as laid out in NIST SP 800-37, rests on an assumption so basic it’s never stated: the system you assessed is the system that runs. Configuration drift is treated as an anomaly to detect and correct. For AI systems, that assumption fails four separate ways.

1. Behavior changes without a deployment. A fraud detection model scoring live traffic degrades as the traffic distribution shifts under it. Nothing was deployed. No commit exists to review. The system’s operational behavior on Tuesday is measurably different from Monday’s, and no traditional change control process fired.

2. The training data is attack surface. NIST’s adversarial ML taxonomy (AI 100-2) catalogs poisoning, evasion, extraction, and inference attacks — none of which map cleanly onto a control catalog written for software vulnerabilities. A poisoned dataset passes every SAST scan you point at it. Your Trivy output is green while the model learns a backdoor.

3. Retraining is redeployment with worse visibility. When a model retrains on fresh data, you’ve shipped a new system component. But unlike a code deployment, the diff is millions of weight changes no human can review. The artifact changed; the reviewable surface didn’t.

4. Test coverage doesn’t mean what it used to. A deterministic function passes or fails a test. A model has an accuracy distribution, confidence intervals, and performance that varies by input subpopulation. “Did it pass T&E?” becomes a statistical claim with an expiration date, not a binary gate.

What the DoD Actually Decided

The DoD CIO’s AI Cybersecurity Risk Management Tailoring Guide made a structural call that surprised people expecting a “model ATO”: AI models do not receive their own authorization. The infrastructure layer — the platform hosting, serving, and monitoring the model — gets the ATO through the normal RMF (or cATO) process. The model itself goes through Assess Only.

Assess Only is an existing RMF construct for components that operate inside an already-authorized boundary. Applied to AI, it works like this:

1. During model development, the team builds a body of evidence: test and evaluation results, change management documentation, data provenance records, and acquisition documentation.
2. That evidence package — including a categorization recommendation — is attached to the hosting system’s security authorization package.
3. The Security Control Assessor reviews it, and the AO makes a single risk decision covering the system and the models it hosts.

The elegance is that it reuses machinery that already exists. The weakness is the same thing: Assess Only was designed for components that don’t change much. A model retrained monthly generates a new body of evidence twelve times a year, and the guide leans on programs working out control gates with their AO — consistent with the DevSecOps Playbook — rather than prescribing what those gates are.

The guide also doesn’t stand alone. It points programs at the DoD Cybersecurity Knowledge Service, the DevSecOps Playbook, and CDAO’s Responsible AI Toolkit — which means the actual authorization workflow for an AI program is assembled from at least four documents, none of which is authoritative over the others.

The NIST Layer: AI RMF and the 800-53 Overlays

Two NIST work streams matter here, and they solve different problems.

The AI RMF (AI 100-1) is a voluntary risk framework — Govern, Map, Measure, Manage — aimed at trustworthiness: bias, explainability, safety, adversarial resilience. It’s useful for program-level risk conversations and it’s increasingly cited in DoD guidance, but it produces no control evidence. You cannot hand an AO an AI RMF profile and call it an assessment.

The SP 800-53 Control Overlays for Securing AI Systems (COSAIS) are the piece that plugs into the ATO machinery. An overlay tailors the 800-53 catalog for a specific technology class — adding controls, modifying implementation guidance, marking controls not applicable. NIST published the concept paper in August 2025, released an annotated outline for the predictive AI overlay in January 2026, and is targeting public drafts of all five overlays (generative AI, predictive AI, single-agent systems, multi-agent systems, and AI developer environments) in Q3 2026.

This matters because overlays are the format AOs already understand. Once a COSAIS overlay is finalized, “authorize this AI system” becomes “assess against the 800-53 baseline plus the AI overlay” — the same mechanics as a FedRAMP or classified overlay today. Until then, every program is inventing its own control tailoring and hoping the assessor agrees.

Continuous Evaluation: cATO Extended to Model Artifacts

If you already run a Continuous ATO evidence pipeline, the AI extension is conceptually clean: treat the model as one more artifact class flowing through the same evidence machinery.

The pipeline stages map like this:

Data ingest    -> provenance + poisoning checks   -> evidence: data lineage record
Training run   -> versioned artifact + model card -> evidence: training provenance
Eval suite     -> accuracy/adversarial/red-team   -> evidence: T&E results vs. thresholds
Deployment     -> signed model, admission control -> evidence: artifact integrity
Production     -> drift + performance monitors    -> evidence: continuous eval telemetry

Each stage produces a structured artifact mapped to a control objective, exactly the way a Trivy scan maps to RA-5 in a conventional cATO pipeline. Model registries (MLflow, SageMaker Model Registry), eval suites wired into CI, and drift monitors feeding the AO dashboard are the AI equivalents of the scanner-to-OSCAL chain.

Three practices carry most of the weight:

• Model cards as compliance artifacts. Version-controlled, generated at training time, recording data sources, eval results, intended use, and known limitations. This is the SSP fragment for the model.
• Eval gates with declared thresholds. The AO signs off on thresholds — minimum accuracy, maximum subgroup performance gap, a performance floor under adversarial perturbation — and the pipeline enforces them on every candidate model. A model below threshold doesn’t promote, same as a failed policy gate.
• Drift monitoring mapped to controls. Input distribution shift and output performance decay tracked in production, with alerting into the same dashboard the AO already watches. This is RMF Step 6 — Monitor — applied to weights instead of configurations.

For systems operating at the tactical edge, this pipeline has to extend past deployment into runtime — the argument I made in Runtime Governance for Mission AI.

The Unsolved Problem: Re-Authorization Triggers

Here is the gap in every current framework, and it’s worth being blunt about it: nobody has defined when model change requires a new authorization decision.

Traditional RMF has a concept of “significant change” that triggers reassessment. For software, programs have workable heuristics — new external interface, new data type, architectural change. For models, the analogous question has no agreed answer:

• Does a scheduled retrain on new data constitute a significant change?
• Does 5% accuracy decay from drift? 10%? On which subpopulation?
• Does a fine-tune that alters behavior on inputs no one thought to test?

Independent analysis of the DoD’s AI governance stack flags exactly this: lifecycle coverage is partial because the framework lacks clear drift-detection, retraining, and re-authorization triggers. CDAO’s Responsible AI Toolkit gets closest — its Stage 7 covers continuous monitoring of the system, its use, and its ecosystem, and the SHIELD assessment generates Statements of Concern through the lifecycle — but it’s a risk-management aid, not an authorization instrument.

In practice, programs are solving this contractually with their AO: negotiate drift and performance thresholds upfront, write them into the authorization decision as conditions, and treat a threshold breach the way cATO treats a failed control — automated POA&M, AO notification, and a defined remediation clock. It works. It’s also bespoke every single time, which is exactly the situation the RMF existed to eliminate.

The NDAA FY2026 Angle: This Is Coming for Contractors

The FY2026 NDAA directs the DoD to develop an AI/ML cybersecurity and physical security framework and — the consequential part — to incorporate it into DFARS and the CMMC program. Analysts are already calling it “CMMC for AI,” and the shape is familiar: contractors developing, deploying, storing, or hosting AI/ML for the Department will have to demonstrate framework compliance as a condition of contract.

If you watched the CMMC 2.0 rulemaking cycle, you know how this plays out. The framework gets defined, the DFARS clause appears, primes flow the requirement down, and the DIB spends two years retrofitting evidence infrastructure it could have built incrementally. The organizations that extended their cATO pipelines to model artifacts early will treat the new clause as a reporting format change. Everyone else gets an unfunded compliance program.

Where AI Programs Will Fail

1. Authorizing the demo, fielding the drift. The model that passed T&E is not the model running eight months later. Programs that treat the initial Assess Only package as done — with no continuous eval feeding the authorization — are running on stale evidence, and unlike stale software evidence, stale model evidence describes behavior that provably no longer occurs.

2. Evidence without thresholds. Logging eval metrics isn’t a control. Evidence becomes admissible when it’s compared against a threshold the AO accepted. Dashboards full of unjudged metrics give the AO data and no decision.

3. Skipping data provenance. The training pipeline is part of the authorization boundary. Programs that document the serving infrastructure but not data lineage have an unassessed supply chain sitting upstream of every prediction — the AI equivalent of shipping without an SBOM.

4. Waiting for COSAIS. The overlays land in draft in Q3 2026 and finalize into 2027. Programs deferring their control tailoring until then lose a year they could have spent building the evidence pipeline the overlays will demand anyway. The overlay changes the mapping, not the machinery.

5. Treating the RAI Toolkit as the authorization. SHIELD assessments and Statements of Concern inform risk; they don’t evidence controls. Programs conflating responsible-AI process artifacts with security assessment evidence show up to the SCA review with the wrong genre of paperwork.

The Bottom Line

The DoD’s current answer — ATO the platform, Assess Only the model — is a reasonable bridge. It keeps AI programs inside existing RMF machinery instead of inventing a parallel accreditation system, and it composes cleanly with cATO for programs that already have an evidence pipeline.

But it’s a bridge with a missing span. Until re-authorization triggers are defined — by COSAIS, by the NDAA-directed framework, or by DoD policy — the hardest question in AI authorization is settled program-by-program in negotiation with each AO. The programs in the strongest position are the ones treating models as first-class pipeline artifacts today: versioned, evaluated against AO-accepted thresholds, monitored for drift, and wired into the same continuous evidence flow as everything else they ship.

The model will change. That’s not the risk to eliminate — it’s the property to authorize.

The Big Picture: The Army rebuilt RMF around three moves — threat-informed control selection, inheritance by default, and continuous monitoring. The DoD then replaced RMF department-wide with the CSRMC. If you work Army systems, you now operate under both.

Why It Matters

Legacy RMF produced 18-month authorizations and paperwork nobody read. RMF 2.0 cut the Army’s control baseline roughly 40% and pointed authorization at live monitoring instead of periodic reassessment. The CSRMC makes that direction DoD policy. Program teams that still run checklist-first RMF are executing a retired process.

The Details

• Threat-informed selection (Project Sentinel): Controls are prioritized against validated threats, not applied as a flat catalog. Result: Control Correlation Identifiers cut from 1,335 to 805 on SIPRNet and 1,208 to 769 on NIPRNet — about 40% less manual work per system.
• Inheritance by default: Systems inherit controls from the infrastructure and enterprise policies they ride on, through common control providers. One assessment covers many tenants.
• CSRMC (Sep 2025): The DoD CIO’s replacement for RMF — five phases aligned to the system lifecycle (Design, Build, Test, Onboard, Operations) and ten strategic tenets, with continuous monitoring and continuous ATO at the center.

Go Deeper

What Broke in RMF 1.0

The original RMF — NIST SP 800-37 as the DoD implemented it — treated every system as an island. Each program selected from the full NIST SP 800-53 catalog, documented every control in its own SSP, and re-proved at reassessment what the enterprise had already proven elsewhere. Three predictable failures:

1. Flat baselines. Every control weighted the same, whether or not any adversary used it. Effort went where the catalog pointed, not where the threat was.
2. Duplicated evidence. A hundred systems on the same network each documented the same infrastructure controls. Same proof, written a hundred times.
3. Point-in-time authorization. The ATO described the system on assessment day. Every patch after that made the paperwork less true.

The Army hit these walls early and at scale — thousands of systems, one network, no way to staff the paperwork. RMF 2.0 was the response.

The Army’s Fix: Project Sentinel

Project Sentinel is the first phase of Army RMF 2.0. The mission: adapt the Unified Network Plan’s RMF process into a threat-informed risk decision process with far less overhead. Three mechanisms carry it.

1. Threat-informed control selection. Sentinel maps validated threats — from authoritative sources like the CIS Critical Security Controls — against the RMF catalog, and prioritizes the controls that counter real, current adversary behavior. This is what NIST always said to do (tailor the baseline); the Army built the process to actually do it. The measurable result: CCIs cut from 1,335 to 805 on SIPRNet and from 1,208 to 769 on NIPRNet — an average 40% reduction in manual control manipulation per system.

2. Inheritance and common control providers. The second mechanism is the same one that makes Continuous ATO scale: assess the shared infrastructure once, let every tenant system inherit. Common control providers document the enterprise controls — network defense, identity, physical security — and individual systems document only their delta. For a formation fielding hundreds of systems on one network, this is where the return on investment lives.

3. Continuous monitoring as the end state. The stated culmination of RMF 2.0 is continuous monitoring of technical controls, moving the Army from periodic reauthorization toward a continuous authorization model. The sentinel metaphor is the design intent: the watch never ends, so the authorization doesn’t expire on a calendar.

One honest caveat: reducing controls draws criticism. The counterargument from the assessor community is that a threat-informed cut risks trimming controls that matter against threats not yet on the validated list. The Army’s bet is that 805 controls actually monitored beat 1,335 controls documented and forgotten. I think that bet is right — but it only pays if the monitoring is real.

Then the DoD Replaced RMF Entirely

On 24 September 2025, the DoD CIO issued the Cybersecurity Risk Management Construct (CSRMC) — the department-wide replacement for RMF. The stated reason matches the Army’s diagnosis: static checklists and manual processes that ignored operational needs and cyber survivability.

CSRMC restructures risk management into five phases aligned to the system lifecycle:

Under the phases sit ten strategic tenets: automation, critical controls, continuous monitoring and ATO, DevSecOps, cyber survivability, training, enterprise services and inheritance, operationalization, reciprocity, and cybersecurity assessments. Read the list against Project Sentinel and the overlap is obvious — threat-prioritized critical controls, inheritance, continuous monitoring. The Army’s RMF 2.0 was, in effect, the pilot for what became DoD policy.

Two tenets deserve attention because they change behavior between organizations, not just within them:

• Reciprocity. An assessment done once gets reused across systems and components. The chronic failure mode of legacy RMF — every AO re-assessing what another AO already accepted — is now explicitly against the design.
• Cyber survivability. The system must keep operating in a contested environment, which shifts testing from “are the controls documented” to “does the system fight through degradation.” That’s the same requirement I covered from the JADC2 side in the software-defined battlefield post.

How the Two Frameworks Fit Together

If you’re on an Army program, the practical stack looks like this:

1. CSRMC sets the structure — five lifecycle phases, ten tenets, DoD-wide.
2. Army RMF 2.0 / Sentinel supplies the Army’s implementation — the threat-informed baseline, the common control providers, the monitoring infrastructure.
3. NIST SP 800-53 still supplies the control language. CSRMC reorganizes how controls are selected, assessed, and monitored; it does not invent a new catalog. Your evidence still maps to 800-53 controls — there are just fewer of them, chosen for a reason.

The through-line from both frameworks is the same one running through this whole series: evidence must be produced by the system, continuously, not written about the system, annually. The cATO evidence pipeline is how you build that. CSRMC is the policy language that now requires it.

Where Programs Will Get This Wrong

1. Treating CSRMC as RMF with new labels. The five phases are not the six RMF steps renamed. The unit of work changed: from documents produced at gates to monitoring wired in from design. A program that maps its old SSP process onto the new phase names has missed the point and will fail the Operations phase.

2. Claiming inheritance without a provider. Inheritance requires a common control provider that actually documents and maintains the shared controls. “We’re on the enterprise network” is not inheritance — it’s an undocumented dependency. Name the provider, get the inheritance agreement in writing.

3. Building dashboards instead of monitoring. The Operations phase requires real-time risk posture that an authority can act on — including disconnection. A dashboard nobody watches, wired to thresholds nobody set, is dashboard theater. If a control fails at 0300 and no alert fires, you are not continuously monitoring; you are continuously displaying.

4. Ignoring reciprocity in both directions. Teams remember to claim other organizations’ assessments and forget to package their own for reuse. Under CSRMC, an assessment that another program can’t consume is half-finished work.

The Bottom Line

RMF 2.0 and CSRMC are the same judgment issued at two echelons: control catalogs don’t defend networks, and paperwork isn’t evidence. The Army proved the mechanics — threat-informed baselines, inheritance, continuous monitoring — and the DoD wrote them into the replacement framework.

If you own a system under this stack, three moves, in order: map your current controls to the threat-informed baseline and cut what falls outside it; get your inheritance agreements documented with a named common control provider; and wire monitoring into the pipeline before the Operations phase demands it. Do them now, while the transition gives you room — the programs that wait will be re-learning legacy RMF’s lesson on the new framework’s timeline.

The Big Picture: The Pentagon spent two years and over a billion dollars learning that autonomous swarms fail exactly the way microservice architectures fail — healthy nodes, broken system. The hardware was never the hard part.

Why It Matters

Replicator dissolved into the Defense Autonomous Warfare Group in late 2025. The postmortem reads like a distributed systems incident report: platforms that couldn’t integrate with existing C2, no software to orchestrate mixed-vendor swarms, “hundreds” fielded against a target of thousands. Every failure mode has a name in commercial software engineering. The DoD is now betting roughly $54 billion it can solve the orchestration problem it skipped the first time.

The Details

• Replicator’s real lesson: The drones mostly worked. What failed was the coordination layer — the ACT program (Anduril, L3Harris, Swarm Aero) was supposed to make thousands of individually capable platforms behave as one coherent system, and it wasn’t ready when the hardware was.
• Open DAGIR is an API contract, not a program: CDAO’s ecosystem approach lets any vendor build applications against government-owned data — the procurement expression of a service-oriented architecture, and the piece that keeps the kill web from becoming one prime’s monolith.
• Swarm Forge is the CI/CD loop: CDAO’s follow-on effort packages validated swarm behaviors for transition to operational units in 90 days or less — treating swarm capability as a software release cycle, not a hardware acquisition milestone.

Go Deeper

What Replicator Actually Proved

Replicator launched in August 2023 with a clear pitch: field thousands of attritable autonomous systems within 18–24 months to offset China’s mass. Judged as a procurement sprint, it half-worked. Judged as a systems integration effort, the Congressional Research Service assessment is blunt — hundreds materialized, not thousands, and the systems that did arrive struggled to plug into existing command-and-control.

By late 2025 the initiative was folded into the Defense Autonomous Warfare Group (DAWG), and the Department’s next bet on autonomous warfare is an order of magnitude larger.

Here’s the part that matters for anyone building software: the failure wasn’t aerodynamics or batteries. Individual platforms flew fine. The program failed at exactly the layer commercial engineering spent fifteen years learning to build — the one that turns a pile of working components into a working system. A swarm without an orchestration layer isn’t a capability. It’s inventory with propellers.

If you’ve operated a microservice architecture, you’ve seen this incident before. Every service passes its health check. The system is down. The problem lives in the seams — discovery, routing, contract mismatches, backpressure — and no amount of improving the individual services fixes it.

Decomposing the Kill Chain

In the JADC2 post I argued the kill web is a distributed systems problem. Take it one level deeper and the classic targeting cycle — find, fix, track, target, engage, assess — decomposes into services with familiar shapes:

The legacy model is a monolith: one platform owns its own sensor, its own processing, its own effector, end to end. That’s an F-35 — a vertically integrated stack, brilliant and expensive and single-vendor. The kill web bet is that decomposed services on a shared data fabric beat vertically integrated platforms for the same reason services beat monoliths in commercial systems: independent scaling, graceful degradation, and the ability to swap implementations without rewriting the system.

The microservices analogy isn’t decoration. The engineering problems transfer almost one-to-one:

Service discovery is sensor-shooter pairing. “Any sensor cues any shooter” is a service registry problem. A new node joins the mesh, advertises its capabilities, and becomes discoverable — under jamming, with intermittent links, and with the registry itself as a contested target.

Partition tolerance is the whole game. Commercial architects read CAP theorem and pick a tradeoff. In a contested electromagnetic environment, the partition isn’t an edge case — it’s the adversary’s explicit goal. Systems must keep operating with local, possibly stale state, then reconcile when connectivity returns. That’s why GitOps-style declarative convergence keeps showing up at the tactical edge: it’s the pattern built for exactly this.

Heterogeneity is the contract problem. Replicator’s swarm software had to orchestrate drones from different vendors with different autonomy stacks — a schema and API versioning problem wearing camouflage. This is what the Modular Open Systems Approach (MOSA) mandates and what Replicator’s timeline couldn’t wait for: agreed interface contracts before scale, not after.

Backpressure decides who gets shot at first. Ten thousand sensor detections and a hundred available effects is a queueing and prioritization problem. Get flow control wrong in a commercial system and you drop requests. The military version of dropped requests is targets that never get serviced.

Open DAGIR: The Government Owns the Data Plane

CDAO’s Open Data and Applications Government-owned Interoperable Repositories — Open DAGIR — is the acquisition-policy expression of a clean architectural principle: the government owns the data plane; vendors compete on the application layer.

Under the platform-centric model, the prime that built the platform owned the data formats, the interfaces, and effectively the roadmap. Replacing an application meant renegotiating the stack. Open DAGIR inverts this: government-owned repositories with published interfaces, multiple vendors building against them, and — critically — the ability to onboard a new application without a new integration contract for the data underneath.

Any engineer who has unwound a monolith recognizes the move. Separating storage from compute, defining the contract at the data layer, and letting application teams iterate independently is the standard playbook. CJADC2’s minimum viable capability, delivered in early 2024, was built this way, and the multi-vendor experiments running since — Palantir, Lockheed’s interoperability factory, and others — are effectively contract tests against a shared fabric.

The strategic point: Open DAGIR is what stops the kill web from re-monolithizing. Without a government-owned data plane, the first vendor to win the integration contract becomes the new platform owner, and the Department is back where it started with extra steps.

Swarm Forge and the 90-Day Release Cycle

The most quietly radical thing CDAO is doing is Swarm Forge — an effort to discover, validate, and field AI-enabled swarm capability in 90 days or less per cycle.

Read that against traditional acquisition timelines and the shift is structural: swarm behavior is being treated as a software artifact with a release cadence, not a program of record with a fielding date. A validated swarm package is, in effect, a versioned release — behaviors tested in simulation and on the range, packaged, and shipped to operational units on a loop measured in weeks.

This is the same move the DevSecOps world made a decade ago, and it drags in the same dependencies: you need tests you trust (validation ranges and simulation), an artifact pipeline (signed, versioned behavior packages), and — the part that connects to everything else I’ve written this year — an authorization process that can keep up. A 90-day capability loop attached to an 18-month ATO process is an 18-month capability loop. The continuous authorization machinery isn’t adjacent to this; it’s load-bearing.

Where the Metaphor Breaks

The microservices frame is productive right up until it isn’t, and it’s worth being precise about where it stops.

Engagement is not a stateless service. In commercial systems, retries and at-least-once delivery are safe defaults. In a kill web, the engage stage carries legal and ethical weight that no other “service” does — engagement authority is held by humans under rules of engagement, and the architecture has to make that gate structural, not advisory. Idempotency isn’t a performance nicety when the operation is a strike; duplicate delivery isn’t an error budget item.

Latency asymmetry cuts the other way. Commercial systems tune for the happy path and tolerate slow failure recovery. Contested C2 inverts this: the system must degrade in milliseconds and can afford to recover slowly. Designs that fail closed — no valid policy, no engagement — are mandatory, which is the argument I made in Runtime Governance for Mission AI: policy enforcement has to travel with the node, because the node can’t phone home for permission from inside a jammed partition.

The registry is a target. Nobody DDoSes your Consul cluster with cruise missiles. Every piece of shared infrastructure in a kill web — the discovery layer, the data fabric, the orchestration plane — is a high-value target precisely because it’s shared. Architectural centralization that would be a mild availability risk commercially becomes a single point of strategic failure.

The Bottom Line

Replicator’s dissolution wasn’t a failure of the swarm concept. It was a demonstration — an expensive one — that mass without orchestration is theater, and that the orchestration layer is a harder engineering problem than the platforms it coordinates. The Department appears to have absorbed the lesson: DAWG inherits the mission with the software problem named up front, Open DAGIR keeps the data plane out of vendor hands, and Swarm Forge puts swarm capability on a release cadence instead of a fielding schedule.

The kill chain is becoming a set of services on a government-owned fabric, and the engineering disciplines that matter — interface contracts, partition-tolerant design, flow control, fail-closed authorization — are the ones commercial distributed systems teams already practice daily. The difference is the failure domain. When your service mesh has a bad day, you write a postmortem. When this one does, the postmortem has casualties. That asymmetry, not the technology, is what should shape every architectural decision in the stack.

The Big Picture: Executive Order 14028 turned Software Bills of Materials into a mandatory federal procurement requirement — contractors must deliver a machine-readable inventory of their entire software supply chain.

Why It Matters

Log4Shell proved the threat lives in dependencies you didn’t know you had. Programmatic SBOM pipelines let security officers verify dependency integrity and answer “are we affected?” in minutes when new CVEs drop, instead of weeks.

The Details

• Required Telemetry: CISA requires SBOMs to document supplier names, component names, exact version strings, dependencies, and SHA-based hashes.
• Industry Formats: SPDX (Linux Foundation standard, ISO-certified) and CycloneDX (OWASP standard, security-first, supports VEX documents) are the primary format specifications.
• Tooling Stack: Syft scans build directories to output raw lists; Grype correlates lists against current CVE databases; Cosign signs and distributes outputs.

Go Deeper

The Mandate That Changed Software Procurement

Executive Order 14028 — signed May 2021 — did something novel for federal IT policy: it made software transparency a contractual requirement, not a best practice. Section 4 directed NIST to define minimum elements for a Software Bill of Materials, and directed federal agencies to require SBOMs from software vendors. The order was triggered by SolarWinds and Kaseya, two incidents where attackers exploited the opacity of software supply chains to move laterally through government networks without detection.

Three years later, NIST delivered SP 800-218 (Secure Software Development Framework), SP 800-161r1 (C-SCRM Practices), and CISA published its minimum SBOM element guidance. OMB followed with M-23-16 requiring agencies to collect SBOMs for software used in federal environments. The regulatory scaffolding is complete. The procurement reality is more complicated.

What an SBOM Actually Is

An SBOM is a machine-readable inventory of every software component in a given artifact — libraries, packages, operating system layers, and their transitive dependencies — along with version information, licensing data, and provenance metadata.

The practical value is vulnerability correlation: when a new CVE drops for a specific component version, an organization with current SBOMs can immediately identify every system in its environment running that version and prioritize remediation without manual scanning. Log4Shell in December 2021 demonstrated the cost of not having this capability — organizations spent weeks answering the question “are we affected?” that an SBOM would have answered in minutes.

CISA’s minimum elements define three data categories an SBOM must contain to be actionable:

These are minimum elements. A useful SBOM for CUI environments also includes license expressions, known vulnerabilities at time of generation, and integrity hashes for each component.

The Format Question: SPDX vs. CycloneDX

Two formats dominate the SBOM ecosystem. The contracting officer’s solicitation will typically specify one; understanding both is necessary for toolchain selection.

SPDX (Software Package Data Exchange) — ISO/IEC 5962:2021 — was developed by the Linux Foundation with a focus on license compliance. It is the older standard, with broad tooling support and the advantage of being an ISO standard (which matters for some acquisition vehicles). SPDX 2.3 added support for vulnerability data and relationships that make it more competitive for security use cases.

CycloneDX — maintained by OWASP — was built security-first. It natively supports vulnerability information (VEX — Vulnerability Exploitability eXchange), hardware BOMs, machine learning model BOMs, and service dependency graphs. For defense contractors producing embedded systems or ML-enabled software, CycloneDX’s hardware BOM support is a meaningful differentiator.

The practical answer for most DIB contractors: generate both. The toolchain overhead is minimal, and federal customers have not standardized on one format. Syft generates both natively. The NTIA interoperability study confirmed that minimal-element SBOMs in either format are parseable by both communities.

The Toolchain

An SBOM pipeline has three stages: generation, enrichment, and distribution. Most organizations have only stage one.

Generation tools scan build artifacts, containers, or source trees and produce raw SBOMs:

• Syft (Anchore) — open source, generates SPDX and CycloneDX, works on container images, filesystems, and language-specific manifests. The de facto standard for container-era workloads.
• Trivy (Aqua Security) — open source, combines SBOM generation with vulnerability scanning in a single pass. Well-suited for CI pipeline integration.
• cdxgen — open source, CycloneDX-native, strong support for polyglot repos and language-specific package managers that Syft sometimes misses.
• FOSSA and Snyk — commercial, add license compliance workflows and continuous monitoring. Common in enterprises with legal requirements around open source licensing.

Enrichment is where most pipelines stop prematurely. A raw SBOM from Syft is a snapshot of components with version strings. An actionable SBOM correlates those versions against known vulnerability databases — NVD, OSV, GitHub Advisory — and produces either a scored vulnerability list or a VEX document asserting which known vulnerabilities are not exploitable in this context. Grype (Anchore), OWASP Dependency-Track, and Trivy all perform this enrichment step.

Distribution — securely delivering SBOMs to customers alongside software releases — is operationally immature across most of the DIB. The emerging standard is embedding SBOMs as OCI artifacts attached to container image digests (using tools like cosign and the ORAS spec). For traditional software deliverables, contractual delivery alongside the release package is still common and acceptable.

The CMMC Connection

NIST SP 800-171 Rev 3 — incorporated in the CMMC 2.0 final rule (December 2024) — added supply chain risk management controls that directly reference SBOM practices. Control SR.1.001 requires identifying, assessing, and managing supply chain risks. SR.2.002 requires establishing and managing a provenance record for the software, hardware, and services used in organizational systems.

Assessors interpreting these controls look for evidence that the organization knows what software components are running in its CUI environment and has a mechanism to respond when vulnerabilities are identified in those components. A maintained SBOM pipeline, coupled with a vulnerability tracking system, satisfies this evidence requirement in a way that manual software inventories do not. Organizations that lack SBOMs will find SR controls among the hardest to demonstrate during a C3PAO assessment.

Where DIB Contractors Actually Fail

1. Transitive dependencies are invisible. Most contractors generate SBOMs for their own code and direct dependencies but stop there. A Log4j-style vulnerability lives in a transitive dependency — a library pulled in by a library you explicitly depend on. SBOMs that only capture declared dependencies miss the attack surface that matters most. Tools must be configured for recursive dependency resolution, which requires more accurate build environment replication.

2. SBOM generation is not in the build pipeline. SBOMs generated manually, infrequently, or before the final build artifact diverge from what is actually shipped. An SBOM attached to a release that was generated from source rather than the final compiled artifact may be inaccurate. SBOM generation must run as a pipeline step against the final artifact — the container image digest or the compiled binary — not against source manifests.

3. Container base layer provenance is missing. A CycloneDX or SPDX document that accounts for application dependencies but not the OS packages in the container base layer is incomplete. An attacker who compromises a vulnerable glibc version in the base layer does not care that your application dependencies are well-inventoried. Full container SBOMs require scanning all layers, not just application files.

4. VEX documents are not being produced. A complete SBOM often surfaces dozens of known CVEs in dependencies — many of which are not actually exploitable in the specific deployment context. Without a VEX (Vulnerability Exploitability eXchange) document asserting which vulnerabilities are not exploitable and why, contracting officers and security teams reviewing SBOMs are left with uncontextualized vulnerability lists that generate false urgency. VEX is the complement to SBOM that makes the vulnerability data actionable rather than alarming.

5. SBOMs are treated as a deliverable, not a capability. The most common failure: contractors produce an SBOM once, attach it to the initial contract deliverable, and stop. Software changes. Dependencies are updated. Vulnerabilities are disclosed. An SBOM that does not track the actual running software is not a supply chain risk management capability — it is a document artifact that satisfies a checkbox without providing the underlying value. SBOMs must be regenerated on every meaningful software change and continuously correlated against current vulnerability intelligence.

The Operational Model That Works

Organizations that have solved SBOM operationally share a pipeline pattern:

1. Generation on merge to main — Syft or Trivy runs in the post-build CI stage against the final artifact. SBOM output is stored as a build artifact alongside binaries.
2. Vulnerability enrichment at release time — Grype or Dependency-Track correlates the SBOM against current CVE feeds and produces a scored vulnerability report.
3. VEX generation for high-severity findings — Security engineers review critical CVEs, produce VEX documents asserting exploitability status, and attach them to the release package.
4. Continuous monitoring — Dependency-Track or a commercial equivalent monitors production SBOMs against new CVE publications and alerts on new exposures in deployed software — not just at release time.
5. Contractual delivery — SBOMs in both SPDX and CycloneDX formats are delivered alongside software releases, signed with the same code-signing certificate as the software itself.

Stage 4 — continuous monitoring — is what converts SBOM from a compliance artifact into an operational security capability. A new critical CVE disclosed against a library in production requires the same response speed regardless of when the software was released. Without monitoring, the SBOM is dead on arrival from a security standpoint.

The Bottom Line

The EO 14028 SBOM mandate was not a documentation requirement — it was a transparency requirement. The underlying goal is an environment where a zero-day against a specific library version triggers an immediate, automated inventory query: which systems are affected, who is responsible for them, and what is the remediation path. The SBOM is the prerequisite for that query.

DIB contractors who treat SBOM as a one-time deliverable are satisfying the letter of the requirement while missing the operational value entirely. The assessors know this; the contracting officers are learning it. The organizations that get ahead of this are building SBOM generation and continuous monitoring into their delivery pipelines now — while the tooling is mature, the formats are stable, and the cost of implementation is low relative to the cost of demonstrating SR control compliance during a C3PAO assessment.

The SolarWinds attackers exploited opacity. SBOM is the infrastructure that removes it.

The Big Picture: CMMC 2.0 is the DoD’s contractual pass/fail enforcement mechanism — without a valid certification, defense contractors are legally barred from handling CUI and winning DoD bids.

Why It Matters

For the majority of the Defense Industrial Base (DIB) handling Controlled Unclassified Information (CUI), CMMC Level 2 (aligned to NIST SP 800-171’s 110 controls) is a contractual reality. Triennial C3PAO audits require documented, audited proof of compliance rather than self-attestations.

The Details

• Level 1 (FCI): 15 basic security practices; evaluated via annual self-assessment.
• Level 2 (CUI): 110 controls (NIST SP 800-171); audited triennially by certified third-party assessors (C3PAOs).
• Level 3 (High-Value CUI): 110+ controls (NIST SP 800-172); audited directly by government agencies.

Go Deeper

What CMMC Actually Is

Cybersecurity Maturity Model Certification (CMMC) 2.0 is the DoD’s contractual enforcement mechanism for cybersecurity in the Defense Industrial Base (DIB). If your organization handles Controlled Unclassified Information (CUI) and wants to win DoD contracts, CMMC is the gate. It is not a best-practices framework — it is a pass/fail assessment tied directly to contract eligibility.

CMMC 2.0 replaced the original five-level model in 2021, consolidating it into three levels aligned directly to existing NIST standards. The final rule took effect in December 2024, meaning assessments are now a contractual reality, not a future requirement.

The Three Levels

Most defense contractors fall under Level 2. The operative document is NIST SP 800-171, and a third-party assessor organization (C3PAO) certified by the Cyber AB conducts the triennial audit. There is no partial credit on Level 2: deficiencies require a Plan of Action & Milestones (POA&M) with a credible remediation timeline to maintain contract eligibility during remediation.

The 14 Control Domains

NIST SP 800-171 organizes its 110 controls into 14 domains. Organizations consistently underestimate three of them:

Access Control (AC) — 22 controls The largest domain. Least privilege, session lock, remote access restrictions, and CUI access logging. This is where Zero Trust architecture directly maps to compliance: every AC control is easier to satisfy if you have an identity-governed, microsegmented environment. Organizations running flat networks with shared service accounts fail AC consistently.

Configuration Management (CM) — 9 controls Requires a baseline configuration for all systems, change control processes, and documented deviation approval. The practical requirement: every system in scope must have a documented configuration baseline in version control, and changes must go through an approval process. CI/CD pipelines with policy gates satisfy this natively.

Incident Response (IR) — 3 controls Deceptively short but operationally demanding. IR requires a tested, documented incident response plan and the capability to report incidents to DoD within 72 hours via the DIBNet portal. Many organizations have plans they have never exercised. Assessors ask for evidence of tabletop exercises, not just document existence.

The remaining 11 domains — Audit & Accountability, Awareness & Training, Identification & Authentication, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System & Communications Protection, System & Information Integrity — follow the same pattern: each control requires documented implementation and supporting evidence artifacts.

The System Security Plan

The System Security Plan (SSP) is the central artifact of a CMMC assessment. It must describe:

• The authorization boundary: exactly which systems, networks, and users are in scope for CUI handling
• Implementation status for all 110 controls (Implemented / Partially Implemented / Planned / Not Applicable)
• For every implemented control: the specific policy, procedure, or technical configuration that satisfies it
• All external service providers (cloud, managed services) and their inherited controls

The SSP is a living document. Assessors will cross-reference it against actual system configurations during the assessment. A well-written SSP with inaccurate technical claims fails faster than a sparse SSP that accurately reflects a partially implemented environment.

Where Organizations Actually Fail

1. Scope creep on the authorization boundary. Organizations try to shrink their CUI boundary to reduce assessment scope, but draw it too narrowly. When the assessor finds CUI flowing through a system excluded from the SSP, the entire assessment is at risk. Define the boundary conservatively, then work to reduce the actual CUI footprint.

2. Inadequate audit logging. AU controls require logging of user activity, privileged commands, and CUI access — with logs protected from tampering and retained for at least three years. Most organizations have logging enabled but lack the centralized SIEM, integrity protection, and retention policies the controls require.

3. Inherited controls without documentation. Cloud providers (AWS GovCloud, Azure Government) satisfy many controls at the infrastructure layer. But CMMC requires the organization to document which controls are inherited, from which provider, and under what shared responsibility model. “We use GovCloud” is not sufficient — the SSP must map inherited controls explicitly.

4. Software supply chain gaps. SR controls (from NIST SP 800-171 Rev 3, added in the 2024 rulemaking) require supply chain risk management: SBOM documentation, vendor vetting, and controls against counterfeit components. Organizations that have not updated their SSP for Rev 3 additions enter assessments with unmitigated gaps.

Connecting CMMC to Zero Trust

The DoD’s ZT Strategy and CMMC are complementary frameworks targeting the same underlying controls from different directions. The ZT pillar requirements directly satisfy CMMC control families:

• User pillar → AC (Access Control) and IA (Identification & Authentication)
• Device pillar → CM (Configuration Management) and SI (System & Information Integrity)
• Data pillar → MP (Media Protection) and AC data controls
• Visibility pillar → AU (Audit & Accountability)

Organizations implementing ZT architecture as a genuine operational model — not just for compliance — will find CMMC Level 2 assessments significantly easier. The controls are the same; ZT just implements them as automated, continuously enforced policy rather than documented procedures.

The Bottom Line

CMMC 2.0 assessments are won or lost on evidence quality, not intent. The C3PAO is not evaluating whether your organization cares about security — they are evaluating whether each of 110 controls is implemented and documented. That is an engineering and documentation problem as much as a security problem.

The organizations that pass Level 2 assessments cleanly share three traits: an accurate, current SSP; technical implementations that match what the SSP claims; and evidence artifacts (screenshots, configuration exports, log samples, policy documents) pre-organized by control family. Build the evidence package as you build the controls, not the week before the assessment.

The deadline is no longer theoretical. Contracts are being awarded with CMMC requirements in the solicitation. The time to close the gap is before the assessor shows up.

The Big Picture: Build-time governance only secures the system before it operates — autonomous systems at the tactical edge require runtime governance that enforces policy while the mission is active.

Why It Matters

At the tactical edge, connectivity is intermittent and consequences are high. Autonomy without local policy checks is an accountability gap waiting for an incident.

The Details

• Context-Aware Scopes: Permission scopes shift with live mission parameters, data freshness, and confidence levels — authority tracks context, not a static role.
• Local Edge Policies: Policy-as-code bundles (e.g. Open Policy Agent) run locally at the edge, ensuring safety even in degraded/disconnected environments.
• Human-in-the-Loop Thresholds: Programmatically separates recommendation logic from execution permissions, forcing human overrides for high-impact actions.

Go Deeper

The Runtime Governance Challenge

Most organizations govern AI during development—asking about training data, model versions, and CI/CD guardrails. While necessary, this only covers the system before it operates. The harder problem begins after deployment, when mission AI systems operate at the tactical edge with intermittent connectivity and high-stakes consequences.

In these environments, governance cannot stop at the pipeline. Build-time governance validates the system you intended to deploy; runtime governance constrains the system that is actually operating.

6 Core Runtime Capabilities

A runtime control plane for autonomous behavior is required to manage speed, trust, and accountability. This control plane needs six primary capabilities:

1. Context-Aware Authorization

Authority should belong to the mission context, not just a service account. An agent’s permissions should be scoped in real time by mission role, data sensitivity, operational phase, and confidence thresholds.

2. Policy-as-Code at the Edge

Mission AI needs executable policy bundles that run locally. This “hybrid” model ensures that even when disconnected from a central control plane, the system continues to enforce approved boundaries.

3. Data Provenance and Freshness

The system must continuously evaluate data quality. If sensor data is stale or a source is degraded, the AI should lose the authority to take actions dependent on that data. No output should carry more trust than the data pipeline beneath it.

4. Human Authorization Thresholds

Human-in-the-loop is an engineering design problem. Runtime governance must separate recommendation from execution, ensuring that high-impact actions always trigger explicit human approval workflows.

5. Continuous Telemetry and Audit

AI-specific telemetry must capture more than just uptime. It must record model identity, prompt context, tool calls, and the policy logic behind every autonomous decision to support post-mission accountability.

6. Graceful Degradation

Every system needs designed failure modes. When confidence drops or data integrity is compromised, the system should automatically shift from autonomous to advisory mode or disable specific high-risk tools.

The Architectural Balance

A mature mission AI architecture requires four distinct layers:

1. Execution Layer: Where models and agents generate recommendations.
2. Runtime Governance Layer: Where actions are evaluated against live mission policy.
3. Telemetry Layer: Where behavior and approvals are recorded for audit.
4. Enterprise Layer: Where model approvals and policy bundles are managed centrally.

The Bottom Line

Autonomy without runtime governance is just automation with an accountability gap. None of this exists to slow operators down — it exists so that speed doesn’t erase accountability, and so autonomous behavior stays tied to mission intent. Runtime governance is what keeps a system worthy of trust once it leaves the clean environment of the dashboard and enters the field.

The Big Picture: The Department of Defense faces a hard FY2027 deadline to achieve Target Level Zero Trust Architecture across its entire enterprise — 152 activities across 7 security pillars.

Why It Matters

Nobody has attempted a security migration at this scale — millions of users, thousands of networks spanning COBOL-era systems and cloud. Whether it lands decides if the DoD can secure distributed networks in contested environments or keeps carrying legacy IT as an open vulnerability.

The Details

The framework classifies security controls across 7 distinct fields:

• User: Enforces phishing-resistant MFA (CAC/PIV) and continuous behavioral monitoring.
• Device: Mandates real-time endpoint threat detection and device health attestation.
• Applications & Workloads: Scopes access to micro-perimeters and requires Software Bills of Materials (SBOM).
• Data: Tagging, labeling, and data loss prevention (DLP) to track Controlled Unclassified Information (CUI).
• Network: Enforces network microsegmentation and encrypted transit (SASE/ZTNA).
• Automation & Orchestration: Integrates security playbooks (SOAR) for automated response.
• Visibility & Analytics: Consolidates logging to identify anomalous behavior.

Go Deeper

The Mandate

In November 2022, the DoD released its Zero Trust Strategy and Roadmap — a directive requiring all DoD components to achieve department-wide Zero Trust Architecture by FY2027. The trigger was EO 14028 (May 2021), which ordered federal agencies to accelerate ZT adoption, followed by OMB M-22-09 setting hard timelines across the federal enterprise.

The DoD’s version goes further than most federal mandates. It defines 152 discrete ZT activities across two maturity tiers, holds components accountable to a published roadmap, and has a dedicated program office tracking progress. For an organization of this scale — millions of users, tens of thousands of systems, a mix of cloud and legacy — it is the most ambitious ZT program ever attempted.

The Seven Pillars

The DoD ZT framework is organized around seven capability pillars. Each pillar has its own activity set and target maturity level.

The Data and Visibility pillars are the hardest. Data tagging at scale in a multi-classification environment — where the same system may handle CUI, FOUO, and SCI — is an unsolved operational problem for most components. Visibility requires telemetry ingestion from systems that were never designed to emit it.

Two Levels: Target and Advanced

The strategy defines two tiers of compliance:

Target ZT — 91 activities covering foundational controls. This is the FY2027 requirement. Most components are building toward this baseline.

Advanced ZT — an additional 61 activities representing a more mature, automated, and analytically sophisticated posture. This is the long-term destination, not a near-term mandate.

The distinction matters operationally: Target ZT is survivable for legacy-heavy organizations. Advanced ZT assumes modern infrastructure, deep telemetry, and policy-as-code enforcement — capabilities that require significant re-platforming for many DoD components.

What DISA Is Building

DISA’s Thunderdome program is the reference implementation. Launched as a ZT pilot in 2022, Thunderdome provides:

• Secure Access Service Edge (SASE) architecture replacing legacy VPN tunnels
• Application-level access control via identity-verified micro-perimeters
• Zero Trust Network Access (ZTNA) brokered by DISA’s cloud-hosted infrastructure

Thunderdome is being extended to DoD enterprise endpoints and serves as the template for component-level ZT deployments. DISA also maintains the ZT Reference Architecture (ZT RA) v2.0, which provides the technical blueprint that program offices are expected to implement against.

Progress and Gaps

The ZT PMO — housed under the DoD CIO — publishes annual assessments. The picture as of early 2026 is mixed:

What’s working:

• Identity and credential management has accelerated. PIV/CAC enforcement and phishing-resistant MFA are broadly deployed across SIPRNet and NIPRNet.
• Cloud migration has created natural ZT on-ramps. New cloud-native workloads are being deployed ZT-first.
• Components with modern infrastructure (DIA, CYBERCOM, NSA) are tracking ahead of schedule on Target ZT activities.

What’s lagging:

• Legacy system integration remains the critical path risk. Many components operate COBOL-era back-office systems that cannot emit the telemetry ZT requires without middleware shims that introduce their own attack surface.
• Microsegmentation is the most-cited unmet control. Segmenting flat DoD networks at scale requires changes to physical switching infrastructure that procurement cycles can’t keep up with.
• Data tagging at the pillar level is largely manual in practice. Automated classification pipelines exist in classified enclaves but are not uniformly deployed.
• OCONUS environments — deployed tactical networks operating in denied or degraded conditions — have no clear ZT implementation path for several advanced controls.

The FY2027 Question

The FY2027 deadline for Target ZT is aggressive but achievable for the majority of DoD components — if procurement and integration timelines hold. The realistic risk is a two-speed outcome: modern, cloud-forward organizations clearing Target ZT, while legacy-heavy components receive waivers or partial credit on the 20–30 activities that require infrastructure modernization.

Advanced ZT by FY2027 is not the goal, and conflating the two tiers creates false urgency in the wrong places. Organizations should put their resources into the 91 Target activities before reaching for the Advanced tier.

The Bottom Line

What separates the DoD ZT strategy from prior federal security mandates is the accountability structure. The ZT PMO has visibility into component progress, the roadmap is public, and waivers require documented justification. This is policy-as-code thinking applied at the organizational level: the intent is enforceable, measurable, and auditable.

The FY2027 target will stress-test that accountability layer. Components that treat ZT as a compliance checkbox will fail the activity audits. Those that treat it as an infrastructure migration — identity-first, microsegmentation second, telemetry third — have a clear path to completion.

The perimeter is gone. The question is only how long it takes each organization to finish building what replaces it.

The Big Picture: The 2026 National Cyber Strategy mandates extending Zero Trust Architecture to the AI stack — for federal contractors, the AI model pipeline is now the enterprise security perimeter.

Why It Matters

Traditional Zero Trust was designed for human users and static endpoints. AI systems introduce non-deterministic agents, float-weight datasets, and overly broad service accounts that bypass standard network segmentation.

The Details

• AI Bill of Materials (AI-BOM): Every deployed model must be cryptographically signed, traced to authenticated training datasets, and attested before deployment.
• Dynamic Least Privilege: Scopes AI agent API keys to specific repositories and tasks, forcing automated expiration to limit token exposures.
• Data Lineage Tracking: Labels model weights with the highest classification level of their absorbed training data to prevent exfiltrations.

Go Deeper

AI as a Perimeter

In early 2026 the White House stopped treating AI as just another application. The 2026 National Cyber Strategy mandates Zero Trust Architecture (ZTA) and AI security across federal networks, and industry moved the same direction at the same time. For defense contractors the implication is direct: the AI stack is the security perimeter now, and it gets defended like one.

Why Traditional Zero Trust Fails AI

Traditional Zero Trust was designed for human users and managed devices. AI systems break this model in three fundamental ways:

1. The Identity Problem: AI agents often inherit broad service account permissions rather than scoped, verifiable identities.
2. The Data Problem: Models “absorb” data during training. Weights become data artifacts that carry the classification of their source, yet traditional labels can’t track floating-point weights.
3. The Verification Problem: Continuous verification built on behavioral baselines fails against non-deterministic AI agents whose outputs are variable by design.

A Framework for AI Zero Trust

Extending ZTA to the AI stack requires four primary enforcement layers:

1. Model Provenance and Attestation

Every model version must be cryptographically signed, traceable to a known training run, and documented via AI-BOM (AI Bill of Materials). Unsigned or unverified models must be blocked from deployment.

2. Agent Least Privilege

AI agents must operate under the strictest application of least privilege. Permissions should be scoped to specific repositories or tasks and automatically revoked upon completion. This is a technical implementation of AC-6 (Least Privilege) for automated systems.

3. Pipeline Integrity Gates

The CI/CD pipeline is the last line of defense. Organizations should implement AI-specific Policy as Code (OPA) gates that require human approval for any AI-authored changes to security controls or infrastructure manifests.

4. Technical Data Governance

AI data governance requires four-part lineage tracking:

• Lineage: Tracking every dataset used in fine-tuning.
• Sensitivity Labeling: Labeling model weights with the highest classification of their absorbed data.
• Output Filtering: Applying DLP controls to inference outputs.
• Post-Quantum Encryption: Encrypting all model weights on the 2030 federal migration timeline.

The Bottom Line

If your AI system touches Controlled Unclassified Information (CUI), it is in scope for your CMMC 2.0 assessment. Organizations must add AI components to their System Security Plan (SSP), document model provenance as a configuration management (CM) control, and implement agent least privilege as an access control (AC) requirement.

The framework is clear and the tooling (SLSA, OPA, MLflow) is mature. The choice is whether to build this compliance in now or respond to an audit finding later.

The Big Picture: Strip away the acronyms and Joint All-Domain Command and Control is a distributed systems architecture problem — connecting sensors and shooters across every domain of warfare, with all the consistency, latency, and partition headaches that implies.

Why It Matters

Wars are won on decision latency. Turning fragile, linear kill chains into self-healing kill webs means one thing: normalizing data across service silos into a single Zero-Trust data fabric.

The Details

• Decentralized Meshes: Any sensor cues any shooter. If a communication node is jammed, routing protocols dynamically heal connections.
• Decision Speed: Exercises (like Project Convergence) prove that moving target allocations to AI meshes reduces cycle times from 20 minutes to under 20 seconds.
• Edge Deployment: Employs hardened Kubernetes (Platform One/Iron Bank) and local AI inference to support disconnected edge operators.

Go Deeper

The Shift to a Software-Defined Battlefield

The deciding variable in modern warfare isn’t radar range or missile speed — it’s decision latency. The 1990s built networked warfare; adversaries responded by building capabilities specifically to blind and isolate those networks. Joint All-Domain Command and Control (JADC2) is the answer: a framework for connecting sensors and shooters across land, sea, air, space, and cyber into a single coherent operational picture.

JADC2 is fundamentally a software architecture problem. It requires a “Data Fabric” that normalizes information across service-specific silos using modern cloud principles: event-driven architecture, API-first interoperability, and Zero Trust security.

From Kill Chains to Kill Webs

Traditional targeting follows a linear kill chain: find, fix, track, target, engage, and assess. This sequential process is fragile and slow. JADC2 enables a kill web—a resilient, parallel mesh where any sensor can cue any shooter. If one node is jammed or destroyed, the network reroutes.

Experiments in programs like the Air Force’s ABMS and the Army’s Project Convergence have cut targeting cycles from 20 minutes to under 20 seconds. And none of this is theoretical — Ukraine is running the pattern today with Starlink and DELTA, built on commercial software and open standards.

The Engineering Toolkit for JADC2

Engineers building JADC2-aligned systems are utilizing the same toolkit as commercial cloud architects, adapted for physically hostile and electronically contested environments:

• Platform One / Iron Bank: Providing hardened, K8s-based DevSecOps foundations.
• Policy as Code (OPA): Enforcing security rules on disconnected edge nodes where manual review is impossible.
• GitOps (Flux/ArgoCD): Ensuring declarative state convergence for systems with intermittent connectivity.
• Zero Trust (NIST SP 800-207): Replacing perimeter security with continuous, identity-based authorization.

The Hard Problems Ahead

The technical concept is clear, but the execution faces significant non-technical hurdles:

1. Cross-Domain Security: Automating data sharing across classification boundaries requires new policy authorities, not just software.
2. CDIL Environments: Systems must function in Contested, Degraded, Intermittent, and Limited connectivity, requiring aggressive edge computing and local AI inference.
3. Acquisition Speed: Software evolves in days, but defense programs take years. The organization must evolve faster than the adversary can adapt.

The Bottom Line

JADC2 may be the largest software integration effort ever attempted, and it will be won by whoever fields distributed systems, API design, and DevSecOps practice most effectively — not by whoever owns the most hardware. The software-defined battlefield already exists. The open question is who implements it faster.

The Big Picture: When autonomous AI agents commit and push code without human authorship, the CI/CD pipeline must evolve from a quality gate into a governance layer.

Why It Matters

AI-generated commits occur at velocities and volumes that humans cannot manually review. Pipelines that assume human authoring expose systems to prompt injection, dependency confusion, and runaway permission scopes.

The Details

• Provenance Tracking: Cryptographically signs and metadata-tags every AI commit to map models, source prompts, and human approvers (e.g., via Sigstore/Gitsign).
• LLM-Tuned Analysis: SAST and Semgrep rules specifically tuned to detect common LLM failure modes (hallucinated APIs, weak error handling).
• Supply-Chain Verification: Strict dependency lockfile validation to capture hallucinated package names before package registry requests are resolved.

Go Deeper

The End of Human-Only Assumptions

Every CI/CD pipeline was designed around one implicit assumption: a human wrote the code with conscious intent. AI agents—like GitHub Copilot Workspace, Devin, and Claude Code—break this assumption. They are already writing features, fixing CI jobs, and modifying infrastructure at speed.

When AI agents are in the loop, the CI/CD pipeline stops being a quality gate and becomes a governance layer. Traditional review ensures that human-reviewed code is consistent; AI-aware pipelines must catch emergent issues that only appear when agentic code interacts with a broader system.

Building an AI-Aware Pipeline

An AI-aware pipeline requires four fundamental additions to the standard DevOps workflow:

1. Provenance and Attribution

Every AI-generated change must be tagged at commit time with metadata: which model produced it, what prompt triggered it, and which human authorized it. Frameworks like SLSA and tools like Sigstore/Gitsign provide the necessary cryptographic chain of custody.

2. AI-Specific Static Analysis

Standard SAST tools catch known vulnerabilities, but AI can produce novel, semantically incorrect patterns. Pipelines need Semgrep rules tuned for LLM failure modes (hallucinated APIs, incorrect error propagation) and OPA/Conftest to enforce architectural invariants.

3. Hallucinated Dependency Detection

LLMs occasionally invent plausible but non-existent package names—a major risk for dependency confusion attacks. Mitigation requires strict lockfile enforcement and treating any unrecognized dependency in an AI PR as a high-priority human review item.

4. Intent-Oriented Human Review

When agents write code, human review changes character. Tests already cover mechanical correctness, so the reviewer’s real job becomes intent alignment: should this feature exist? Does this infrastructure change match our architectural direction? You stop checking the implementation and start checking the decision.

Risk Modeling for Agentic Development

Organizations must explicitly model three primary agentic risks:

• The Compromised Agent: An agent manipulated via prompt injection to introduce backdoors.
• The Confident Hallucination: An agent implementing a security algorithm incorrectly while providing readable but false documentation.
• The Runaway Agent: An agent with broad permissions making individually reasonable decisions that lead to a collectively catastrophic outcome (e.g., mass resource deletion).

The Bottom Line

GitOps is the governance structure that makes AI agents safe at scale. By making Git the single source of truth, every change an agent makes—from spinning up servers to updating manifests—becomes a versioned, reviewable pull request.

The pipelines we built for humans aren’t wrong; they are incomplete. The transition to AI-aware CI/CD is the organizational decision to treat agent governance as a first-class engineering concern before something goes wrong.

Why It Matters

Building entirely on closed stacks means vendor lock-in, slower feedback loops, and a smaller hiring pool — every candidate knows Kubernetes, few know your vendor’s orchestrator. Community-vetted OSS tooling is tested at a scale no single company can replicate internally.

The Details

• Git & Containers: Git handles version control and declarative intent; Docker and Kubernetes represent the standards for container orchestration.
• Infrastructure as Code (IaC): OpenTofu (or Terraform) and Ansible automate multi-cloud infrastructure and agentless system configurations.
• Telemetry Observability: Prometheus collects real-time system metrics, while Grafana visualizes complex alert telemetry.

Go Deeper

The Bedrock of Modern Technology

Open source software started as a movement and ended up as the plumbing. Nearly everything the industry runs on — orchestration, monitoring, version control — is built in the open, improved by thousands of contributors, and battle-tested in production environments more varied than any vendor’s QA lab. Teams that know this stack well avoid lock-in and get improvements at the pace of the community, not the pace of a vendor’s release calendar.

The Technical Payload: Industry Standards

The open source ecosystem is vast, but these tools have become the non-negotiable standards for modern engineering:

1. Control & Orchestration

• Git: The foundation of all collaboration and version-controlled intent.
• Kubernetes (K8s): The CNCF-maintained standard for container orchestration at scale.
• Docker: Still the default answer to “works on my machine.”

2. Infrastructure & Delivery

• Terraform / OpenTofu: Declarative Infrastructure as Code (IaC) for multi-cloud provisioning.
• Ansible: Agentless automation for configuration management and orchestration.
• Jenkins / GitLab CI: Customizable automation engines for the CI/CD backbone.

3. Observability & Monitoring

• Prometheus: High-performance systems and service monitoring.
• Grafana: The leading platform for querying, visualizing, and alerting on technical metrics.

The Bottom Line

The tools we use shape the products we build. But the ecosystem only works because users become contributors — code, documentation, even a well-written bug report keeps the foundation maintained. If your company runs on open source (it does), sending something back upstream isn’t charity. It’s maintenance on infrastructure you depend on.

Why It Matters

When code changes deploy multiple times daily, manual reviews become security liabilities. Expressing policies as executable code ensures that security standards (like encryption at rest or access controls) are automatically enforced before deployment.

The Details

• Build-Time Blocking: Catching cloud misconfigurations (like public storage buckets) at the CI pipeline gate rather than during runtime audits.
• Git Audit Trails: Tracks policy modifications via standard Pull Requests, providing an immutable history of compliance changes.
• Same Rules Everywhere: The compliance check that runs for a 5-person team is byte-identical to the one running for 5,000 — no per-team interpretation of the policy doc.

Go Deeper

The Problem with Document-Based Policy

Traditional security policy lives in Word documents, PDF checklists, and manual reviews. That worked when deployments were quarterly. Against code that ships dozens of times a day, a policy nobody’s pipeline can read is a liability with a signature page. Policy as Code (PaC) expresses the same rules as machine-readable, executable code, version-controlled in Git.

Instead of a document stating “No public S3 buckets,” PaC uses logic (e.g., Rego) to automatically reject any infrastructure manifest that lacks encryption or blocks public access. This is testable, versionable, and automatically enforced in the CI/CD pipeline.

Why Policy as Code Matters

• Automatic Enforcement: PaC shifts security to the left, catching violations at the build gate rather than during a post-deployment audit.
• Testability: Policies can have unit tests, ensuring they correctly block risks while allowing legitimate traffic before they reach production.
• Auditability: Every policy change is a Pull Request in Git, providing a complete, tamper-evident record of who approved what rule and when.
• Scale: A codified policy is enforced identically for 5 developers or 5,000. Consistency stops depending on how each team read the document.

The Implementation Stack

Successful PaC implementation requires enforcement at four distinct layers:

1. Pre-commit: Lightweight checks (e.g., Checkov) running on developer workstations to catch obvious misconfigurations.
2. CI Pipeline: The primary enforcement gate where every PR is evaluated against the full policy set (using OPA or Sentinel).
3. Admission Control: Runtime enforcement in Kubernetes (via Kyverno or OPA Gatekeeper) to reject non-compliant resources that bypass CI.
4. Continuous Monitoring: Detecting “drift” in deployed infrastructure using cloud-native tools like AWS Config or Azure Policy.

The Bottom Line

Policy as Code turns security from a periodic gate into a continuous guardrail. By making Git the source of truth for both infrastructure (GitOps) and security rules, organizations can ship faster with higher confidence.

Start small: pick five critical rules (e.g., encryption at rest, no hardcoded secrets), codify them, and add them to your pipeline. The hard part is the first policy; after that, automated governance becomes a natural property of the system.

The Big Picture: Standard Agile breaks down in defense environments where security accreditations, compliance audits, and hardware lead times create constraints Silicon Valley never designed for.

Why It Matters

Threats change weekly. Waterfall delivers in 18–36 months. Defense teams must ship secure capability incrementally — without dropping safety or compliance to do it.

The Details

• Continuous ATO (DevSecOps): Automates security validation checks (SAST, container scans) directly within the code pipeline, shifting security from a final bottleneck to continuous verification.
• Hardware-Software Decoupling: Uses digital twins and Hardware Abstraction Layers (HAL) to develop software independently of long-lead physical hardware cycles.
• Automated Documentation: Replaces manual reports with automated API and architecture docs generated directly from source code and Infrastructure-as-Code (IaC).

Go Deeper

The Necessity of Defense Agility

When threats evolve weekly, an 18-36 month waterfall cycle isn’t a process choice — it’s a decision to field obsolete software. Iterative development lets systems adapt to new threats and fold in warfighter feedback in weeks. The defense industry knows this; the argument ended years ago.

However, standard Silicon Valley Agile often fails in defense due to Documentation Gaps, Security Accreditation (ATO) bottlenecks, and Contractual Rigidity. The goal is not to adopt Agile blindly, but to adapt it for the unique constraints of high-stakes mission systems.

The 5 Pillars of Defense Enterprise Agility

To succeed, defense organizations must build a framework that balances speed with enterprise-grade governance:

1. Modular & IDIQ Contracting

Fixed-price contracts lock in requirements before learning happens. Defense leaders should pivot to modular contracting with sequential awards tied to demonstrated capability and IDIQ (Indefinite Delivery/Indefinite Quantity) task orders scoped per release.

2. Continuous ATO (DevSecOps)

Traditional security reviews happen at the end, creating 6-12 month delays. Agile defense requires embedding security engineers into teams and using Continuous ATO approaches where controls are verified incrementally via automated CI/CD pipelines (SAST, DAST, container scanning).

3. Automated & Versioned Documentation

Agile’s emphasis on “working software over documentation” can lead to sustainment nightmares. The solution is Automated Documentation: generating API docs from code and architecture diagrams from IaC, then versioning them in Markdown alongside the source code in Git.

4. Hardware-Software Decoupling

Pure Agile struggles with 3-year hardware cycles. Successful programs use Hardware Abstraction Layers (HALs) and Digital Twins to decouple software development from physical hardware milestones, allowing code to evolve even while components are in production.

5. Architectural Guardrails

Iteration without vision creates technical debt. Organizations must define a modular System Architecture upfront, using Microservices and clearly documented Interoperability Standards to allow team autonomy within defined technical boundaries.

The Bottom Line

You can’t buy defense agility as a certification course — it takes real changes to contracts, culture, and technical practice, and most organizations only get two of the three. The ones that manage all three ship systems that are modular, secure, and responsive to the battlefield. The rest keep building software that’s too rigid to adapt and too slow to matter, with better standup meetings.

Why It Matters

You cannot keep humans accountable for thousands of distributed devices by hand. UAV fleets and cloud estates have the same requirement: one declarative, version-controlled source of truth that reconciles drift on its own.

The Details

• Declarative Operations: Defines what the system should look like rather than writing manual deployment scripts.
• Automated Reconciliation: Tools like ArgoCD or Flux continually pull the actual system state back toward the Git config, so drift gets corrected instead of accumulating.
• Cryptographic Provenance: Enforces signed Git commits to verify identity and auth before changes sync to air-gapped networks.

Go Deeper

From Convenience to Control Plane

GitOps applies DevOps practice — version control, collaboration, CI/CD — to infrastructure. Git holds the declarative state, and everything else works to match it: complex systems managed through pull requests and automated reconciliation. That used to be a nice-to-have for cloud teams. With AI agents running operations and warfare going software-defined, it’s become the accountability layer everything else depends on.

Why GitOps Matters Now

• Reproducibility for AI Agents: As AI agents handle more operations, GitOps provides the immutable infrastructure and audit trails necessary to maintain human oversight of autonomous decisions.
• Scale and Speed: A global SaaS platform and a distributed sensor network have the same problem at scale — thousands of nodes that need to converge on a desired state without a human touching each one. Continuous reconciliation is the only mechanism that survives that scale.

Software-Defined Warfare: Lessons from Ukraine

The conflict in Ukraine has validated GitOps principles at scale. The battlefield is now a software-defined environment where victory depends on the speed of iteration.

1. Sensor Mesh Management: Saturation of the battlespace with sensors requires coordinated, declarative deployment across thousands of distributed nodes.
2. UAV Fleet Scaling: Managing thousands of drones requires version control for mission parameters and rapid iteration cycles to counter adversary jamming within hours.
3. Rapid Countermeasures: When new electronic warfare threats emerge, counter-algorithms are pushed through GitOps pipelines—tested, validated, and deployed to entire fleets simultaneously.

The GitOps Control Loop

A mature GitOps implementation rests on four core principles:

1. Declarative Configuration: Defining what the system should look like, not how to build it.
2. Version Control: Every change resides in Git with a full, immutable history.
3. Automated Reconciliation: Controllers (e.g., Flux, ArgoCD) continuously work to eliminate drift.
4. Observability: Providing real-time visibility into the actual state of every system.

For critical infrastructure, this must be augmented with Signed Commits for provenance and Air-Gapped Sync capabilities for disconnected operations.

The Bottom Line

GitOps provides the guardrails that modern automation requires. Cloud infrastructure or a thousand drones — the operational framework is the same, and the side that iterates fastest with the fewest surprises wins. If your infrastructure isn’t declarative and version-controlled yet, that’s the first move. Everything else in this series builds on it.

Why It Matters

As prompt-to-code pipelines mature, typing speed stops being a constraint on anything. The teams that pull ahead will be the ones with better judgment about design, intent, and system-level discipline — the things a model can’t supply.

The Details

• Flow first: Cut the syntactic decision overhead so engineers keep momentum on the actual problem.
• Directing, not typing: The developer’s job shifts from solo builder to real-time director of AI code generators.
• Prototype before architecture: Validate the core logic with AI quickly, before committing to a structure that’s expensive to unwind.

Go Deeper

What Changed

Vibe coding is a development approach that puts flow-based momentum ahead of rigid upfront planning. With agentic AI everywhere, the developer’s role has moved from writing syntax by hand to defining the “vibe” — the intent, logic, and creative direction of the system.

In practice that means:

• Protecting flow state. Less decision overhead, less context-switching, more sustained attention on the problem.
• Working with an agent. The AI is a real-time collaborator that shapes the coding direction as you go, not an autocomplete you tolerate.
• Refining iteratively. Start with a working prototype that feels right, then firm up the architecture once the core logic is proven.

The Workflow

Vibe coding isn’t an absence of structure. It’s a different order of structure:

1. Define the vibe. Pin down the intent and feel of the feature before anything else.
2. Iterate with the agent. Use Cursor or Claude to generate and refine logic in real time.
3. Tune later. Performance work and deep refactoring wait until the creative part has landed.

This works best for prototypes, MVPs, and fast-moving environments — anywhere requirements change faster than a traditional spec can keep up.

Spontaneity Needs a Cleanup Phase

Speed and creativity are the upside. The downside is that spontaneous code accrues technical debt, and you have to schedule the payback:

• Architecture review. Check that the vibe holds up against long-term system stability.
• Deliberate refactoring. Harden the organic code into something production can trust.
• Documentation. Write down the intent before it evaporates with the flow state.

The Bottom Line

Vibe coding is human-centered development. The AI handles mechanical syntax so the developer can spend attention on problem-solving and architectural intent. Best practices don’t go away — they just move to a cleanup phase you have to actually do. Skip it, and “vibe” becomes a polite word for debt.

Why It Matters

Teams still hand-writing boilerplate are spending engineering hours on work a model does in seconds. An agentic-first stack moves that time to the parts that need a human: system architecture and user experience.

The Details

• Cursor (IDE): The benchmark for AI-first editors right now. Claude and O1 sit directly in the edit loop for tab-completion and inline refactoring.
• Claude (Anthropic): My default pair programmer for architectural reviews, long-context refactoring, and checking my logic before I commit to a design.
• GitHub Copilot: The industry-standard autocomplete. Best used to kill boilerplate in whatever editor you already live in.

Go Deeper

The Core Stack

The tools worth keeping are the ones that don’t interrupt you. By 2026 the stack has settled around three:

• Cursor: The AI-first IDE to beat. With Claude 3.5 and O1 built into the editor, tab-completion, refactoring, and natural-language edits feel like part of the editor rather than a plugin bolted on.
• GitHub Copilot: Context-aware completion that works in VSCode, JetBrains, and Vim. Its job is narrow — reduce boilerplate — and it does that job well.
• Claude (Anthropic): Where I go for the conversations Copilot can’t have: architecture trade-offs, complex refactors, design reviews. The long context window means it can hold an entire subsystem in its head while you argue with it.

Specialist Tools

Past the editor, a few tools handle specific domains better than the generalists:

• v0 (Vercel): Generative UI for React. Text description or sketch in, working accessible component out.
• Vercel AI SDK: The standard framework for building AI features into applications — one API for streaming across multiple models.
• Eraser: Turns a system design prompt into an architecture diagram you’d actually put in a doc.
• Codeium: A privacy-focused Copilot alternative with a genuinely usable free tier. Good default for individual developers.

A Working Setup

If I were configuring a machine from scratch today:

1. Editor: Cursor, for the deep AI integration.
2. Architecture partner: Claude, for design and logic review.
3. Frontend: v0, for fast UI iteration.

The Bottom Line

These tools are multipliers, not replacements. Treat suggestions as good starting points and still review everything for security and architectural intent. Let the AI handle syntax; your job is the system’s “vibe” — the logic, the user experience, and whether anyone can maintain it in two years.