ASOM-Fedv6.1Open the explorer
T4 · CISA ZTMM pillar · The urban terrain

Applications and Workloads

Dense, complex, and hard to clear — the layer where defenders lose track of what they own. It also holds the single most leveraged decisive point in a modern estate.

The Ground

The urban terrain.

Urban terrain is dense, compartmented, and expensive to clear. Every building is a separate problem, sightlines are short, the defender’s advantage of observation largely disappears, and a force can occupy a city for a long time without either side knowing exactly who holds what. Applications and workloads have all of those properties, which is why this is the layer where defenders most often lose track of what they own.

The doctrinal consequence is that clearing is the wrong instinct. You do not secure urban terrain by sweeping it repeatedly; you secure it by controlling the routes into it and by holding the few structures that dominate the rest. On this layer that means the pipeline, the gateway and the runtime admission point — not an annual scan of every application.

This is also the layer where the terrain changes fastest. An estate delivering by continuous deployment rebuilds parts of this ground weekly, which makes terrain currency (TM-6) more binding here than anywhere else in the model: a quarterly overlay describes a city that has been partially rebuilt since the map was drawn.

Origin

A CISA Zero Trust Maturity Model pillar, carried with its name and boundary unchanged so an agency reporting maturity under OMB M-22-09 reports the same rung here.

Asset pools feeding it
  • Application assets — the public service portal, case filing and case processing systems, secondary mission systems, public APIs and bulk data, the CI/CD pipeline; cloud workload assets — containers, orchestration, secrets stores

Key Terrain

Key terrain is what confers decisive advantage if you hold it. Everything else on this layer is defended in order to hold these.

  • The public service portalThe largest attack surface the agency operates, reachable by anyone, and the front door to external-user identity.
  • The case processing systemWhere mission records are actually worked, and where volume access is granted — mediated by an application rather than by a database boundary.
  • Public APIs and bulk dataDeliberately open surfaces whose abuse pattern looks like their intended use, which is what makes them hard to defend and easy to under-weight.
  • The CI/CD pipelineNot an application the mission uses, but the terrain from which every other application on this layer is produced.

The Decisive Point

The CI/CD pipeline — poisoning it envelops everything downstream

The decisive point is the CI/CD pipeline, and it is the strongest example of a decisive point in the whole model: seizing it does not defeat one application, it envelops every application downstream of it, including the ones built to defend the others.

The asymmetry is what makes it decisive. A defender who holds the pipeline can make an entire class of compromise non-viable — unsigned artifacts cannot reach production, so poisoning a dependency yields nothing. An adversary who holds it inherits the agency’s own deployment authority and does not need to defeat any runtime control, because the runtime will be told to trust what they built.

The consequence for reconstitution is severe and frequently missed: recovery that rebuilds from the pipeline restores whatever the pipeline was compromised with. A trusted rebuild path (RC-3) that runs through the same pipeline is not a rebuild path.

Sub-Towers, Rung by Rung

Maturity is scored here, not on the layer. Each rung below is stated for this sub-tower specifically — “Advanced” means something testable on each one, and something different on each one. The rung marked current is the illustrative position on the Federal Reference Agency profile.

AppSec (SAST / DAST)

Finding defects in agency-built software before an adversary does, and dispositioning them.

  • Criticality 4
  • Exposure 4
  • Weight 16
  • Illustrative rung Initial · 50%
Traditional25% coverage

A penetration test conducted before an authorization decision. Findings become plan-of-action items and are managed by age rather than by disposition.

Initial50% coverage · current

Static analysis runs in the pipeline for the main applications. Results are advisory; the build is not gated, so findings compete with delivery and lose.

Advanced75% coverage

Static and dynamic analysis run on every change to internet-facing and mission-tier applications. Defined severities break the build. Every finding carries an owner and a disposition rather than an age.

Optimal100% coverage

Security findings are dispositioned on the same interval as functional defects, and the escape rate to production is measured. The application inventory scanning runs against is the terrain overlay, so an unscanned application is a terrain-currency failure rather than an unknown.

ObservableShare of production applications scanned in the current cycle, and the median age of undispositioned high findings.

API Security

The registered, mediated and authorized state of every interface the estate exposes.

  • Criticality 4
  • Exposure 5
  • Weight 20
  • Illustrative rung Initial · 50%
Traditional25% coverage

APIs are documented by the teams that build them. There is no central inventory, and public bulk-data endpoints are authenticated by a key that never expires.

Initial50% coverage · current

A gateway fronts the main public APIs with authentication and rate limiting. Internal service-to-service calls are unmediated because they are considered internal.

Advanced75% coverage

Every API — public, partner and internal — is registered, fronted, authorized per call and rate-limited to a stated ceiling. The registry is reconciled against observed traffic, so an unregistered API is detected rather than assumed absent.

Optimal100% coverage

Authorization is per-object rather than per-endpoint, so enumeration cannot return records the caller is not entitled to. Abuse patterns on public bulk data are modeled and detected as a mission risk rather than as a performance anomaly.

ObservableCount of APIs observed in traffic but absent from the registry, and enumeration attempts detected per cycle on public data services.

Pipeline Security (CI/CD)

The integrity of the path from source to production, and who or what may use it.

  • Criticality 5
  • Exposure 4
  • Weight 20
  • Illustrative rung Initial · 50%
Traditional25% coverage

Build servers sit on the general network with shared credentials. Deploying by hand, directly to production, is possible and occasionally necessary.

Initial50% coverage · current

Pipeline access is controlled by team membership. Deployment credentials are long-lived, and build logs are retained for troubleshooting rather than for evidence.

Advanced75% coverage

The pipeline is treated as key terrain: its own identity plane, no standing privilege, signed commits on protected branches, deployment credentials short-lived and scoped to one target. A human cannot deploy without going through it.

Optimal100% coverage

Build provenance is generated and verified at deploy, so an artifact of unknown origin cannot reach production. Compromise of the pipeline itself is a rehearsed scenario with a rebuild path that does not run through it.

ObservableShare of production deployments carrying verified provenance, and the count of paths to production that bypass the pipeline entirely.

Runtime & Container

What is permitted to run, with what privilege, and what is visible while it runs.

  • Criticality 4
  • Exposure 3
  • Weight 12
  • Illustrative rung Initial · 50%
Traditional25% coverage

Workloads run with broad privileges. Images are pulled from public registries at deploy time, and there is no visibility inside a running container.

Initial50% coverage · current

Images are scanned in the registry. Privileged containers are discouraged by policy and permitted in practice.

Advanced75% coverage

Admission control rejects images that are unsigned, unscanned or over-privileged. Runtime telemetry from workloads reaches the SOC at the same fidelity as endpoint telemetry.

Optimal100% coverage

Workloads run least-privileged by construction and are restarted rather than repaired. Runtime detections are pre-authorized to isolate a workload under the rules of engagement, which is what makes M8 available on this layer at machine speed.

ObservableShare of running workloads that were admitted under policy, and the measured time from runtime detection to workload isolation.

Weight, Coverage and Residual Risk

Weight is criticality × exposure, 1–25 per sub-tower. Coverage is the weighted mean of the sub-towers’ maturity coverage — never a flat average. Residual risk is reported both as the inverse percentage and in weight points, because the points are what rank a backlog.

  • 68Layer weightSum of criticality × exposure across 4 sub-towers
  • 50%Rolled-up coverageWeighted mean of the sub-tower maturity coverage
  • 50%Residual riskThe inverse of coverage, before weight is considered
  • 34Residual pointsWeight left uncovered — the figure that ranks against other layers
Sub-towerCriticalityExposureWeightIllustrative rungCoverageResidual points
AppSec (SAST / DAST)4416Initial50%8
API Security4520Initial50%10
Pipeline Security (CI/CD)5420Initial50%10
Runtime & Container4312Initial50%6

AppSec (SAST / DAST)

Criticality
4
Exposure
4
Weight
16
Illustrative rung
Initial
Coverage
50%
Residual points
8

API Security

Criticality
4
Exposure
5
Weight
20
Illustrative rung
Initial
Coverage
50%
Residual points
10

Pipeline Security (CI/CD)

Criticality
5
Exposure
4
Weight
20
Illustrative rung
Initial
Coverage
50%
Residual points
10

Runtime & Container

Criticality
4
Exposure
3
Weight
12
Illustrative rung
Initial
Coverage
50%
Residual points
6

Criticality on T4 comes from the mission service the application carries, not from the application’s size or cost. The case-processing system and a small internal reporting tool may share a technology stack and differ by a factor of five in criticality.

The pipeline is the weighting anomaly on this layer and should be scored as an asset in its own right, with criticality inherited from the highest-criticality thing it can deploy to. Scored as "a developer tool" it lands at weight 4 and never reaches the top of a backlog; scored as terrain that can reach production it lands at 20 and sits where it belongs.

Exposure needs a reachability answer rather than a hosting answer. An internal application reachable from any staff workstation with a valid session is not exposure 2 because it is "internal" — the reference profile’s most common intrusion path ends at exactly that kind of application. KT-4 exists to replace the assumption with a tested statement.

Maneuvers That Consume This Layer

The primary list is derived from each form’s own primary-terrain declaration in the maneuver catalog, so the two cannot disagree. The supporting list is authored: “consumes without being principally about” is a judgment, and deriving it would be a false claim of rigour.

Primary — Derived

  • M6 DelayBuy decision time and prevent the adversary culminating on the objective.

Supporting — Authored

  • M1 Screen / GuardExternal attack-surface monitoring screens this layer; the application estate is where an unregistered internet-facing service appears.
  • M2 Defense in DepthApplication controls are counted as one of the independent layers an adversary must defeat — but only where they are enforced rather than scanned.
  • M10 Exploitation & PursuitConverting a contact into a durable fix usually means an application or pipeline change, so exploitation and pursuit terminates on this layer.

Controls That Apply

Two lists. The first is specific to this ground; the second is the spine every layer runs through, stated once here rather than repeated ten times across the reference.

Specific to T4

  • KT-4 Adversary Reachability AssessmentReachability of the pipeline from a developer workstation, and of the mission tier from the portal, are the two reachability questions this layer turns on.
  • SM-6 Maneuver Effectiveness ValidationManeuver effectiveness validation is where a rate limit or a WAF rule is shown to have changed adversary behavior rather than merely existing.
  • LC-4 Update Integrity and StagingUpdate integrity and staging governs supplier code arriving through this layer’s pipeline; T4 and T9 meet at the deployment gate.
  • RC-1 Recovery ObjectivesRecovery objectives are declared per mission service, and mission services are applications — this layer is where the objective becomes concrete.
  • RC-3 Trusted Rebuild PathThe trusted rebuild path is defined against this layer, and its central requirement is not to run through the compromised pipeline.
  • FO-5 Statutory Availability FloorThe statutory availability floor is carried by specific applications; naming them is what stops a containment action from breaching a filing deadline.

The Common Spine