CI/CD is the spine of a federal DevSecOps program
Every federal application that reaches production in 2026 passes through a CI/CD pipeline. The pipeline is where policy becomes enforcement, where software supply chain artifacts are produced, where authorization evidence is generated, and where changes are gated before they touch a user. A strong federal CI/CD pipeline replaces a quarterly manual review cycle with an automated gate on every commit.
The tooling landscape has matured to the point where a capable pipeline is no longer exotic. The work is in the integration: wiring together ten tools, mapping outputs to NIST 800-53 controls, producing OSCAL-formatted evidence, and keeping the whole thing auditable across the authorization boundary.
Federal CI/CD platforms
- GitHub Enterprise Cloud — FedRAMP Moderate authorized. Actions runner infrastructure hosted on Microsoft Azure commercial. Strong fit for systems handling CUI at Moderate.
- GitHub Enterprise Server — self-managed inside agency boundary. Works at any impact level.
- GitLab Dedicated for Government — FedRAMP Moderate managed offering.
- GitLab self-managed — runs in AWS GovCloud, Azure Government, on-premise, or air-gapped.
- AWS CodePipeline/CodeBuild — FedRAMP High in GovCloud. Tight integration with AWS deployment targets.
- Azure DevOps — FedRAMP High in Azure Government.
- Jenkins self-hosted — flexibility first. Runs anywhere. Requires more operational burden.
- DoD Platform One Party Bus — hosted GitLab with hardened runners for IL2-IL5 workloads.
What a federal pipeline contains
A minimum federal DevSecOps pipeline for application delivery:
- Source control policies. Branch protection, signed commits required, mandatory two-reviewer approval on main branch, Dependabot or Renovate for automated dependency updates.
- Secrets scanning. Pre-commit via Gitleaks, pre-merge via TruffleHog or GitHub secret scanning. Block merge on finding.
- Static application security testing (SAST). Semgrep, CodeQL, or SonarQube. Critical and high findings block the build.
- Software composition analysis (SCA). Snyk, Dependabot, or OWASP Dependency Check. Vulnerability findings tied to CVE and KEV datasets.
- License compliance. FOSSA or ScanCode Toolkit. Block merges on GPL-incompatible licenses in distributed binaries.
- Container image scanning. Trivy, Anchore, or Clair. CIS benchmark compliance. Critical CVE findings block.
- Infrastructure-as-code scanning. Checkov, tfsec, or KICS. See federal Terraform IaC.
- SBOM generation. Syft or CycloneDX Maven plugin producing SPDX or CycloneDX artifacts on every build.
- Image signing. Cosign with Sigstore or internal KMS-backed keys. Signatures verified at deployment admission.
- Artifact registry. Artifactory, Harbor, Quay, or cloud-native registries with retention, provenance, and vulnerability tracking.
- DAST. OWASP ZAP or Burp Enterprise against ephemeral staging environments.
- Policy-as-code gates. OPA, Sentinel, or GitHub Environments rules enforcing compliance before promotion.
- Deployment. GitOps via Argo CD or Flux, progressive rollout, automated rollback on SLO breach.
SBOM and software supply chain
Executive Order 14028 and OMB Memorandum M-22-18 establish SBOM as a federal requirement for software delivered to agencies. We produce SBOMs on every build in SPDX or CycloneDX formats, sign them with Cosign, attach them as release artifacts, and publish them to an internal SBOM registry. Where required, we submit SBOMs to the agency via the CISA-defined channels. We also implement SLSA (Supply-chain Levels for Software Artifacts) provenance attestations, targeting SLSA Level 3 for federal delivery pipelines.
OIDC-federated credentials, not long-lived keys
The cleanest pattern for federal CI/CD is OIDC federation. GitHub Actions or GitLab Runners assume an IAM role in AWS (or a federated identity in Azure) using a short-lived token issued per workflow run. No long-lived access keys in CI secrets. No credential rotation workflow to fail. Clean mapping to NIST 800-53 SC-12 (cryptographic key management) and IA-5 (authenticator management). Every federal pipeline we build uses OIDC unless a legacy constraint forces otherwise.
DoD Platform One integration
For DoD workloads, we integrate pipelines with Platform One's DevSecOps reference architecture: Iron Bank for hardened base images, Party Bus for hosted GitLab, Big Bang for the Kubernetes platform, and Repo1 for shared source code. The integration produces authorization artifacts that map directly to the DoD Enterprise DevSecOps Reference Design v2 control framework.
Pipeline as authorization evidence
The strongest argument for continuous ATO is that a well-instrumented pipeline produces most authorization evidence automatically. Each build generates: dependency manifest, SBOM, vulnerability scan report, container image signature, SAST results, DAST results, IaC compliance report, test results. Packaged together, these satisfy a material fraction of the CA, CM, SA, SI, and SR control families. We design pipelines from the start so that a security control assessor can sample any build in the last 12 months and see every artifact needed to evaluate the controls in scope.
Air-gapped and classified pipelines
Classified environments run the same tooling disconnected from the internet. GitLab self-managed runs air-gapped. Jenkins agents run in any network. Image registries mirror approved images from Iron Bank or an approved source over an accredited cross-domain transfer. Argo CD reconciles from an internal git mirror. The pipeline architecture is the same; the operational discipline around image mirroring and evidence export is where the work concentrates.
Who we build pipelines for
- DoD — Platform One-aligned IL4/IL5 pipelines.
- HHS — GitHub Enterprise Cloud and GitLab Dedicated for Moderate workloads.
- VA — enterprise CI/CD serving claims and health applications.
- GSA — cloud.gov-aligned pipeline patterns.
- DHS — hardened pipelines for HVA systems.