Building a Compliant CI/CD Pipeline for Public Sector: GitHub, GitLab, and the Authorization Boundary
Originally published on GoOptimal.io
Overview
This article addresses a fundamental challenge for federal government contractors: operating modern CI/CD pipelines using external tools like GitHub or GitLab while maintaining FedRAMP, DoD Impact Level, or agency-specific ATO compliance.
Core Architecture
The proposed three-stage pipeline follows this pattern:
Stage 1: External Source Control (Outside Boundary)
- GitHub Commercial or GitLab.com houses source code and runs CI workflows
- No federal data, CUI, PII, or FTI permitted
- Documented as non-authorized external service in System Security Plan
- Pull-based model only (boundary system retrieves code; external platform never pushes inward)
Stage 2: Internal Dev/Test Environment (Security Gate)
- Automated scanning pipeline validates incoming code
- SAST, DAST, SCA, SBOM generation, secrets detection, container scanning
- All boundary crossing uses FIPS 140-validated encryption
- Comprehensive audit logging of all pipeline events
Stage 3: Production with Manual Promotion
- Enforced separation of duties: developers, dev approvers, and production approvers are distinct individuals
- Human verification gate before production deployment
Key NIST 800-53 Controls
The architecture maps to specific controls:
- SA-3/SA-11: System development lifecycle and developer testing
- SA-9: External systems documentation
- CM-3/CM-5: Configuration change control and access restrictions
- SC-8: Transmission confidentiality via FIPS encryption
- RA-5: Vulnerability scanning at minimum monthly (automated scanning per build recommended)
- SI-7: Software integrity verification
Critical Constraints
- “No federal data in GitHub” represents the bright-line boundary requirement
- Pull-only architecture prevents unauthorized inbound traffic
- Dev environment isolation excludes customer data and dev team production access
Continuous Monitoring Obligations
Monthly deliverables include vulnerability scan reports, POA&M updates, and integrity assessments. Quarterly privilege reviews verify developer access controls. Annual submissions cover SSP updates, CM plans, and penetration testing results.
Risk Mitigation Strategy
Using non-authorized external SCM requires documented risk acceptance or POA&M entries. Organizations unable to tolerate this risk may deploy GitLab self-hosted, AWS CodeCommit on GovCloud, or GitHub Enterprise within the authorization boundary — particularly appropriate for DoD IL5 environments where DISA scrutiny is heightened.