Every classified-bound pipeline automates cleanly until it reaches the boundary — and then a person carries an artifact across and the chain of custody dies. Why that is no longer survivable, and how to build the crossing as engineering rather than ceremony.
The engineering talent, the tooling and the iteration speed all live on the low side. The mission lives on the high side. Every organisation delivering classified-bound software solves the same problem, and most solve it the same way: build low, then carry the result across by hand.
That crossing is usually the only manual step left in an otherwise automated pipeline, and it is where the chain of custody breaks. Once an artifact moves on burned media against a tribal checklist, the high side cannot prove what it received, the low side cannot prove what it sent, and the evidence the pipeline generated so carefully stops at the boundary.
The artifact is not the deliverable. The artifact plus a provable chain of custody is. If provenance does not cross, nothing useful crossed.
Hand-carried promotion has been awkward for years. In 2026 it became a compliance problem.
FedRAMP's Consolidated Rules for 2026 took effect on 4 July, and its Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules carry a 7 December 2026 adoption deadline with certification revocation named as the consequence. CISA's Binding Operational Directive 26-04, issued 10 June 2026, reprioritizes remediation around public exposure and known exploited status rather than severity score alone. DoD's Cybersecurity Risk Management Construct, announced September 2025 as the successor to the legacy RMF, contemplates withdrawing an authorization the moment risk thresholds break.
You cannot continuously demonstrate the state of a system you deploy to by hand once a fortnight.
A manual crossing forces a choice between two bad answers. Either the high side reports on what it believes it is running — an assertion rather than evidence — or it re-derives that state independently, duplicating the entire scanning and attestation apparatus inside the enclave, at cleared-labour rates, forever.
Cleared engineering is the most expensive input in federal software. The instinct is to economise on headcount; the leverage is in economising on what has to be done cleared at all.
In our delivery experience, genuinely high-side work is a minority of the effort on a typical mission application. The rest is application code that could have been built low, duplicated tooling, manual promotion ceremony, and re-testing to re-establish a state that was already known on the other side of the boundary.
The rule is not “never build high.” It is never build high what could have been built low — in our experience 80% or more of a typical mission application. That figure is a delivery observation rather than a published benchmark, offered as a shape to test against your own programme.
| Approach | Failure mode |
|---|---|
| Build everything high-side | Cleared-only labour for all work, starved tooling, iteration in days rather than minutes — the most expensive software you will ever ship, and the slowest |
| Ad hoc manual transfer | Every promotion is a bespoke event: burned media, tribal checklists, no provenance. Findings surface high, where fixes are slowest |
| Shadow parallel stacks | A second toolchain maintained by hand drifts from the first. Parity becomes a rumour and “it worked low” stops predicting anything |
| Trusting the manifest nobody checks | A signed artifact whose signature is never re-validated inside the enclave is a signed artifact in name only |
Four layers, each with explicit interfaces and its own evidence surface. The layering matters because the high side is frequently the part you are least free to change, and the design has to survive that.
Foundation — map before you design. Cloud topology, enclave separation, identity and access, CI/CD maturity, artifact management, current authorization status, and critically what the high side will actually permit. The most common discovery is that the high side already contains most of what the pipeline needs — a registry, an orchestrator, a logging stack — installed for other purposes and usable with configuration rather than procurement.
Orchestration — gated, not improvised. CI/CD spanning classification domains with gated approvals and secure relay through the cross-domain solution. The gates are where human judgement belongs; everything around them is mechanised precisely so that judgement is visible.
Security overlay — enforced, not audited. Isolation, access control, artifact validation and signing enforced at each stage rather than inspected afterwards. This is the difference between a control you can demonstrate and one you can describe.
Monitoring — on both sides. A promotion that fails should be as legible as one that succeeds, and an incident on the high side should trace back to the low-side commit that introduced it without an archaeology exercise.
The artifact is the small part. What makes the crossing defensible is everything bound to it.
| Travels with the artifact | What it lets you prove |
|---|---|
| Cryptographic signature | What arrived is what was built, unaltered |
| Software bill of materials | Exactly what is inside it, component by component, at deploy time |
| Scan results and policy attestations | It passed the gates, and which gates those were |
| Build provenance — source, commit, pipeline | Which code, built by which pipeline, from which commit |
| Manifest re-validated in the enclave | The high side verified independently rather than trusting the label |
Re-validation is not optional. A signature checked only on the low side proves the artifact was correct before it crossed. The whole point of the boundary is that the two sides do not trust each other by default; verification inside the enclave is what converts a manifest from paperwork into evidence.
The unspoken premise of building low is that low-side results predict high-side behaviour. That premise is only as good as the parity between the two environments, and parity decays silently. A package updated on one side, a configuration drift, a version pin nobody carried across — and the low-side test suite is testing a different system.
Environment definitions expressed as code and promoted through the same pipeline as the application; base images built once, low, and promoted rather than rebuilt independently; drift detection on both sides reported to the same place; and an explicit registry of what is legitimately different. There is always something. It should be a list rather than a surprise.
Three tiers, distinguished by how much of the work Ausper carries. Every tier begins with the same foundation assessment, because designing against an unmapped high side is how pipelines get built twice.
Tier 1 — Blueprint + Initial Consulting. Foundation assessment across both domains, target pipeline architecture and gate model, identity and approval model, gap register with sequencing. You execute; we advise at defined checkpoints.
Tier 2 — Blueprint + Advisory. Everything in Tier 1, plus named advisors on a working cadence, policy and manifest schema design, review before each accreditation gate, and a parity and drift strategy.
Tier 3 — Full Execution. Everything in Tier 2, plus pipeline implementation on both sides, signing, manifest and re-validation wiring, monitoring and incident-response integration, and an operator handover.
The 80% build-low figure and the effort split above are Ausper delivery observations, not published research.
Everything on this page, in depth: the four layers, what travels with an artifact and what each item lets you prove, the parity problem, a ten-question readiness instrument, engagement tiers, and nine cited sources. Name, title and business email — no charge.
Name, title, and business email — we’ll email you a one-time access code, then the PDF unlocks on this page.
And could you reconstruct any given crossing six months later? The answer to that one question is usually the whole engagement.
Talk to AusperThis site uses essential browser storage only. With your OK, we’d also use analytics cookies to understand which content is useful. No choice is required — “Essential only” changes nothing. Cookie policy