Defense programs rarely live in a single cloud region. A production defense system may span multiple IL environments, include air-gapped components, require on-premises deployments at specific installations, and have components in both commercial and government cloud. The DevSecOps pipeline must work across all of these — consistently, securely, and with full ATO evidence generation at every stage.
Here's how Rutagon architects multi-site DevSecOps pipelines for defense and government programs.
The Multi-Site Pipeline Challenge
Single-site CI/CD design assumptions break down in multi-environment defense contexts:
- IL boundary crossings: Code that deploys to IL2 (commercial) and IL5 (GovCloud or DISA-controlled) needs different pipeline configurations, different scanning profiles, and different artifact registries at each boundary
- Network isolation: Air-gapped or JWICS-connected environments can't pull from the same artifact repositories as internet-connected pipeline stages
- Authority To Operate separation: Each IL boundary typically has a separate ATO with separate evidence requirements — a shared pipeline must generate distinct evidence packages for each environment's authorizing official
- Latency and bandwidth constraints: Forward operating environments, tactical clouds, and austere installations have bandwidth constraints that affect artifact distribution and pipeline efficiency
The solution isn't separate pipelines maintained independently — that creates drift, security gaps, and maintenance burden. The solution is a federated pipeline architecture: a shared pipeline definition with environment-specific execution contexts.
Federated Pipeline Architecture
In a federated pipeline, the pipeline definition (the .gitlab-ci.yml or equivalent) is authoritative and shared, but execution contexts (where and how stages run) are separated by classification and network tier.
# Pipeline stage definition — shared across all environments
stages:
- lint
- test
- sast
- build
- sign
- deploy
variables:
# Override per environment with CI/CD variable injection
TARGET_REGISTRY: ${ENVIRONMENT_REGISTRY}
SIGNING_KEY_ID: ${ENVIRONMENT_SIGNING_KEY}
sast:
stage: sast
script:
- trivy image --exit-code 1 --severity HIGH,CRITICAL ${BUILD_IMAGE}
- semgrep --config=auto --error
artifacts:
reports:
sast: gl-sast-report.json
deploy:
stage: deploy
environment:
name: ${TARGET_ENV}
script:
- terraform apply -var-file=envs/${TARGET_ENV}.tfvars -auto-approve
rules:
- if: $CI_COMMIT_BRANCH == $DEPLOY_BRANCH
Each execution context — commercial, GovCloud, air-gapped — has its own runner registration, variable set, and artifact storage. The pipeline definition and security requirements are identical; only the infrastructure executing it differs.
Air-Gapped Stage Handling
For programs with air-gapped deployment targets, the pipeline needs a transfer mechanism for build artifacts from the connected build environment to the disconnected deployment environment.
Typical architecture:
1. Build and scan in connected environment (internet-accessible build runners)
2. Sign the container image with Cosign (producing a verifiable signature bundle)
3. Export: docker save | gzip > artifact.tar.gz
4. Transfer via approved data transfer mechanism (USAF transfer guard, removable media process, DISN data transfer service)
5. Import into air-gapped registry: docker load < artifact.tar.gz
6. Verify signature in disconnected environment before deployment
The key: the trust chain is established before transfer. The disconnected environment doesn't need internet access to verify that the image was built and scanned by the approved pipeline — the signature bundle carries that proof.
ATO Evidence Segregation
Each IL environment's ATO requires its own evidence package. In a federated pipeline, this is handled through tagged artifact collection:
evidence:
stage: .post
script:
- collect-ato-evidence.sh \
--scan-reports=reports/ \
--sbom=sbom.json \
--signed-image=${SIGNED_IMAGE_DIGEST} \
--environment=${TARGET_ENV} \
--output=ato-evidence-${TARGET_ENV}-${CI_COMMIT_SHORT_SHA}.zip
artifacts:
paths:
- ato-evidence-*.zip
expire_in: 90d # Retain for ISSM review
The evidence ZIP contains SAST/DAST reports, SBOM, image signatures, infrastructure scan results, and deployment logs — scoped to the specific environment and deployment event. ISSO and ISSM roles review evidence per environment; the shared pipeline ensures consistent evidence structure across all environments.
Rutagon's Production Implementation
Rutagon's production SaaS platform uses a variant of this architecture — OIDC-federated runners that authenticate to environment-specific AWS accounts without long-lived credentials. Each environment (development, staging, production) has isolated runner registration, IAM role assumption via OIDC, and segregated artifact registries. The pattern scales directly to multi-IL defense architectures with the addition of classification-appropriate scanning profiles and ATO evidence collection.
The primary difference in defense contexts: Iron Bank images rather than arbitrary public registries as the base layer, and DISA STIG-aligned scanning profiles rather than generic vulnerability thresholds.
Explore teaming with Rutagon → rutagon.com/contact
Frequently Asked Questions
Can a single GitLab instance serve multiple classification levels?
Generally no — IL environments require segregated infrastructure. The standard approach is separate GitLab instances (or GitLab-compatible equivalents) per classification tier, with the pipeline definition synchronized via a configuration management process. Some programs use a shared pipeline codebase stored in IL2 with deployment into higher-IL environments through approved transfer mechanisms.
How does image signing work in air-gapped environments?
Cosign can sign and verify images entirely offline if the signing keys and verification certificates are available. The public key bundle used for verification is distributed through the transfer process along with the artifact. In disconnected environments, Sigstore's certificate transparency log is replaced with a local verification bundle — the trust root is the approved signing key rather than a CA-based PKI chain.
What scanning profiles apply to GovCloud deployments vs. commercial?
GovCloud deployments should use DISA STIG-aligned scanning profiles with stricter severity thresholds (typically CRITICAL findings block deployment; HIGH findings require documented exceptions). Commercial development environments can use CVSS-threshold scanning with a shorter remediation SLA. The critical requirement: findings in the GovCloud environment must be documented in the POA&M regardless of threshold — scanners must produce STIG-format output for ATO evidence.
How do you handle pipeline secrets in a multi-site environment?
Each environment uses its own secrets management system — AWS Secrets Manager in GovCloud, local HashiCorp Vault or equivalent in air-gapped environments. OIDC federation eliminates long-lived credentials in connected environments. For cross-environment operations (like the transfer step), short-lived credentials scoped to the transfer operation are generated at execution time and immediately rotated.
What's the ITAR posture for DevSecOps pipeline documentation?
Pipeline architecture documentation at the pattern level (this article's depth) is generally safe under ITAR. Specific system configurations tied to weapons programs, classified defense systems, or CUI-containing environments require appropriate handling. When writing SOPs and architecture docs for DoD program pipelines, mark them CUI if they contain controlled system configurations and handle via the program's CUI handling plan.