Running CI/CD Inside an Accredited Enclave for Federal Work

A standard GitHub-hosted or GitLab-hosted shared runner processes your code on infrastructure outside your own accredited boundary, which is a non-starter for a lot of federal work involving controlled unclassified information. Before setting up any pipeline, confirm with your ISSO or compliance lead what data classification the project involves and whether that classification permits a hosted runner at all.

This is a compliance question, not an engineering preference, and it needs an answer before the first workflow file gets written, not after a pipeline's already been running for months.

When hosted runners aren't appropriate, both GitHub Actions and GitLab CI support self-hosted runners you can place entirely inside your own accredited environment, including AWS GovCloud or an equivalent enclave, so the actual build and test execution never leaves your authorization boundary. The CI platform's control plane, scheduling the job and reporting results, may still be a cloud service outside the boundary, but the code and data processing itself happens on infrastructure you control.

Work through this distinction carefully with your compliance team, since where the control plane sits versus where the actual processing happens are two different questions that can each need their own answer.

A pipeline that builds and deploys a system handling controlled data is part of that system's authorization boundary, and it needs its own documented controls, not a blanket assumption that it's covered by the application's own ATO. Document who can trigger a pipeline run, how runner credentials are managed, and how build artifacts are stored and transmitted, since an assessor will ask about all three specifically.

Change failure rate¹ is a useful internal metric here too, since a federal system where deployed changes frequently cause incidents suggests the pipeline's own controls, not just the application code, need a closer look.

Federal guidance increasingly expects a software bill of materials documenting the components in a delivered system, and generating it manually after the fact is both slower and less reliable than producing it as an automated pipeline step on every build. Both GitHub Actions and GitLab CI can run SBOM generation tooling as part of the build process, attaching the resulting document to the build artifact automatically.

Treat a missing or stale SBOM the same way you'd treat a failed test: a build that doesn't produce a current one shouldn't be considered complete.

An authorization to operate reflects the system's controls at a point in time, and a pipeline that drifts from what was documented, a new integration added without updating the boundary documentation, say, quietly invalidates that picture without anyone deciding to. Review your pipeline's actual configuration against the ATO package on a fixed schedule, not just when a reassessment forces the question.

A pipeline is one of the more frequently changed parts of a federal system's infrastructure, which makes it one of the more likely places for documentation to drift out of sync with reality if nobody's specifically watching for it.

The runbook in order:

1. Confirm whether hosted runners are allowed at all for the data classification involved, before assuming a standard setup is appropriate.
2. Build self-hosted runners inside your own accredited enclave when hosted runners are not appropriate.
3. Treat the pipeline itself as part of the system boundary, with its own documented controls.
4. Generate a software bill of materials as a build artifact so it is tied to each delivered build.
5. Keep the authorization package's evidence current as the pipeline changes, not only accurate on approval day.

On a teamed contract, a subcontractor may bring its own CI/CD tooling and its own assumptions about what's permitted, which can create a mismatch if the prime contractor's boundary and the subcontractor's pipeline aren't clearly delineated. Settle explicitly, in writing, whose accredited environment a given piece of work runs in, rather than assuming it's obvious from the org chart.

This is worth resolving during contract kickoff rather than during an assessment, since untangling a boundary question after code has already been running for months is a much harder conversation to have cleanly. Put the agreed boundary in the subcontract itself, not just in an email thread that's easy to lose track of later, and revisit it whenever the contract's scope changes enough to shift where the actual processing happens, since a boundary that was correct at kickoff can quietly stop being accurate as the work evolves.