The DoD Triad

Back in the vendor seat — reading the destination

Seat change back: Meridian delivers software, and because the interconnect serves a military installation, the destination side runs under DoD authorization rules. You will not be pursuing a DoD authorization — that’s the destination system’s burden — but you must read that world accurately, because its expectations flow backward into what Meridian must deliver. Getting this lesson wrong in the field sounds like a vendor saying “our product has a cATO” — a sentence that, as Lesson 1.1’s anchor pattern established, describes nothing that exists. Here’s what does.

What cATO actually authorizes

DoD’s baseline remains classic RMF under its instruction of record (DoDI 8510.01), producing point-in-time authorizations. Continuous ATO — cATO — is not a faster stamp for a product. It is an authorization of an ENVIRONMENT’S ONGOING CAPABILITY. The founding 2022 memo demanded three competencies — continuous monitoring, active cyber defense, and delivery through an approved DevSecOps reference design — and the May-2024 Evaluation Criteria organized the actual assessment around three legs:

THE TRIAD - what a cATO evaluation actually examines:

  PLATFORM   the environment: hardened, monitored, with continuous
             visibility into its own state (the conmon machinery of
             Modules 2-3, running for real)

  PROCESS    the delivery pipeline: gated, evidenced, repeatable -
             the thing this training and its DevOps sibling build

  PEOPLE     the team: trained, staffed, actually operating the above -
             competence as an assessed property, not an assumed one

(Active cyber defense — the 2022 competency this delivery-focused training does not teach — lives inside the platform leg’s monitoring-and-response machinery; know it exists before briefing a destination program.) Read the triad as this training’s thesis restated by the strictest authority in the field: continuous authorization is granted to systems that deliver, not to software that is delivered. A cATO attaches to a DoD platform/system whose owners demonstrated all three legs. Vendors — Meridian included — land on such platforms (next lesson’s subject) and inherit from them; their software never holds the cATO itself. When the destination ISSO asks Meridian for its pipeline documentation, evidence samples, and team qualifications, that’s the triad’s three legs flowing backward down the supply chain — and Modules 2-3 already built your answers.

SBOM-as-evidence — the pattern, named

Name this pattern, because it anchors here: SBOM-as-evidence. The DoD’s software-fast-track experiments (status fenced below) contributed a model worth keeping regardless of any program’s fate: require a software bill of materials from the vendor, generate one independently from the artifact, and diff them. Agreement is evidence the vendor knows their own supply chain; divergence is a finding before any CVE (a published vulnerability identifier) enters the conversation. Add a structured third-party risk assessment (the experiments used a twelve-factor rubric) and automated anomaly review, and the SBOM stops being a compliance attachment and becomes what this module’s title promises — delivery evidence: proof about process, not just inventory of parts. The mainstream companions travel with it: the SBOM itself in a standard format (SPDX or CycloneDX — both machine-readable, both accepted), signed provenance (who built it, from what — generation lives in the DevSecOps Foundations training), and VEX statements (the emerging standard for a supplier’s machine-readable ‘this vulnerability does not affect this product’ notes) so the receiving side triages what applies instead of every CVE in the inventory.

Practical consequences for the vendor seat: generate your SBOM in the pipeline (generation mechanics live in this site’s DevSecOps Foundations training — Provenance and SBOM — in short: attestations and SBOMs emitted by CI, signed at build time), diff it against your previous release as a self-check, and expect the receiving side to diff it against their own scan of your artifact. If those disagree, you want to have found it first. A divergence the destination finds is a supply-chain finding against your delivery, with a remediation clock and a credibility cost on every other claim in your package. One you find is a build fix.

Pre-delivery self-check, run in CI on every release candidate:
1) generate SBOM-A from our build manifest (declared) and SBOM-B from
   the built artifact by scanning (observed); diff - unexplained
   divergence FAILS the candidate (we do not understand our own build);
2) diff SBOM-B against the previous release: new components, version
   changes, license changes - each classified expected (in changelog)
   or unexpected (investigate);
3) emit both SBOMs + diffs into the evidence store (Lesson 3.2) with
   provenance - this is the package the receiving side's diff will be
   checked against.

The successor-framework watch

DoD has declared a successor to RMF — a cybersecurity risk-management construct reorganizing the lifecycle into phases with continuous-authorization tenets at its center. It is real as strategic direction and not yet codified as the instruction of record; senior DoD voices simultaneously push “compliance does not equal security” messaging. How to hold it without betting your program: the triad’s legs are the invariant. Every proposed successor evaluates the same three things with new vocabulary — so build platform-process-people capability and you are ready for the framework churn either way. Program-planning rule: plan against the instruction of record; design toward the declared direction; never gate a delivery on an uncodified framework.

Practice status — among mature regulated delivery programs, commercial and federal

(a few rows carry a more specific status - principle, canon, suspended - where one of the five would mislead)

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

DoD’s continuous authorization evaluates a triad — platform, process, people — and attaches to environments, never products; vendors inherit by landing well, and the destination’s expectations flow backward into your pipeline, evidence, and team story. SBOM-as-evidence is the named pattern to adopt now: declared-vs-observed diffs, release-over-release diffs, everything into the evidence store. Track the successor framework as direction, plan against the instruction of record. Next: the platforms themselves — quantified gates and all.

LEADERSHIP DECISION   fund SBOM-as-evidence in the pipeline now (generate,
                      diff, sign, VEX) - the destination will diff you whether
                      or not you prepared
PRACTITIONER ACTION   declared-vs-observed SBOM diff on every release
                      candidate; release-over-release diff; SPDX/CycloneDX +
                      provenance + VEX into the evidence store
SUCCESS MEASURE       zero divergences first found by the receiver; every
                      release carries a signed, diffable SBOM with VEX