GitLab for defense contractors handling CUI

Why GitLab for defense contractors handling CUI starts with the assessment boundary

Self-managed GitLab can keep source repositories, CI/CD pipelines and review evidence inside a boundary you control, but the boundary itself is set by your contract and your CMMC scope, not by the software. If engineers push code that may contain controlled unclassified information (CUI), the first task is to decide which systems store, process or transmit that CUI, which systems merely touch it, and which are outside the assessment entirely. A self-managed instance on infrastructure you operate makes that boundary easier to draw and defend, because you decide where the database, object storage, Runners and backups live instead of accepting a multi-tenant SaaS service as a black box. The requirements you will be assessed against are not new in form. CMMC Level 2 is identical to NIST SP 800-171 Revision 2 under 32 CFR 170.14(c)(3), which counts 110 requirements, so a GitLab instance that holds CUI has to be mapped to those requirements in the same way as any other in-scope system. Revision 3 of SP 800-171 is published, but the current DoW direction is to enforce Revision 2 in the interim, so confirm the version your contracting officer and assessor expect before you write the boundary. Where a cloud service is used, 32 CFR 170.17(c)(5) limits CUI storage to FedRAMP Authorized services at the Moderate baseline or equivalent, so confirm this for any hosted runner, object store or AI service that touches your pipelines. DeployOpen plans, implements and documents the self-managed GitLab side of that boundary, and prepares the configuration and evidence an assessor will ask for. DeployOpen does not issue certifications or assessment reports. Level 2 certification assessments are performed by C3PAOs authorized through The Cyber AB, and the Phase II certification requirement is currently suspended, so confirm the present obligations with your contracting officer and a qualified assessor before fixing the scope.

Which federal requirements shape the GitLab build

This table maps the federal rules that govern CUI in a defense contractor's systems to what each one means for a self-managed GitLab build. Read each row against the version named in your contract, because the CMMC schedule and the NIST revision in force have changed in 2026. Phase II of CMMC is suspended, but Phase I self-assessments and SPRS postings still apply, so confirm the exact clause and revision your contracting officer uses before scoping.

Requirement	Source	What it means for the GitLab build
Safeguarding CUI on non-federal systems	32 CFR 2002.14(h)(2)	Agencies point to NIST SP 800-171 for CUI on contractor systems, so the GitLab instance, runners and backups holding CUI fall inside that control set unless the CUI category sets other safeguards.
CMMC Level 2 requirements and cloud use	32 CFR 170.14 and 170.17(c)(5)	Level 2 uses the 110 requirements of NIST SP 800-171 Rev. 2. If a cloud-hosted GitLab stores or processes CUI, the provider must be FedRAMP Authorized at Moderate or higher, or meet equivalent requirements, so confirm this before choosing a host.
Contract clause and Rev. 2 baseline	DFARS 252.204-7012 and DoW Class Deviation 2026-O0025, Revision 3	Contracting officers now name SP 800-171 Rev. 2 explicitly under the revised clause, so the build should be assessed against Rev. 2 unless your contract says otherwise. Confirm the revision named in each contract.
Rev. 3 parameters under the proposed FAR overhaul	FAR overhaul proposed rule (23 June 2026)	The proposal would require SP 800-171 Rev. 3 with organization-defined parameter values published by the DoW CIO. It was not final as of October 2026, so document Rev. 3 mappings now as a forward plan and track the final rule.
Phase status and evidence	DoW suspension of CMMC Phase II (13 July 2026) and DoW CIO About CMMC page	Phase II, which would have required C3PAO certification, is suspended, while Phase I self-assessments, SPRS postings and annual affirmations continue. Keep evidence from the GitLab build (access reviews, change records, backup tests) in final form, because drafts do not count as MET.
Criminal justice information, if also handled	FBI CJIS Security Policy v6.1	Applies only if the contractor also handles CJI. It requires FIPS 140-3 validated modules or AES-256 for CJI at rest and in transit outside secure locations, plus monthly vulnerability scanning. Confirm whether any CJI reaches the GitLab instance before adding these controls.

How to scope self-managed GitLab inside or outside CUI

One GitLab instance runs entirely inside the CUI enclave, so every repository, merge request, pipeline log, runner and backup that holds CUI sits within the assessed boundary. This is the most direct boundary to explain to an assessor, but it places the whole GitLab estate under the same controls as your CUI systems, including administration, patching and monitoring. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations apply whichever option you choose.

Instance and data stores: The GitLab application, PostgreSQL, Redis, Gitaly storage and object storage for artifacts generally fall in scope because they store CUI.
Runners: Runners that check out CUI repositories or handle build artifacts are in scope, including autoscaled hosts, their images and their registration tokens.
Backups and Geo: Backup archives and any Geo secondary site hold copies of CUI, so each needs the same boundary and access controls as the primary.
Logs and monitoring: Audit, production and job logs can contain CUI in file paths, commit messages or job output, so log storage and shipping paths count.

Ask your assessor whether a single enclave instance matches the expected baseline for your contract, and confirm how the enclave boundary and shared administrator accounts are documented.

Which GitLab modules and settings matter for CUI repositories

A CUI repository inherits the security posture of every GitLab component that touches it: the install, the identity provider, the runners, the backups and any replica site. The cards below cover the settings that most often decide whether a self-managed instance can be defended as part of your assessed scope. Confirm each one against the GitLab version you deploy.

Offline installation and air-gapped operation

GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners and for GitLab Duo Self-Hosted. For a CUI enclave, the install, package sources, container images and scanner data must all arrive by approved transfer and never depend on outbound internet calls. Ask GitLab to confirm which scanner features and advisory data sources work offline in your chosen version, and document the import process as part of your system security plan.

Identity through SAML, LDAP or smart card

GitLab Self-Managed supports LDAP, SAML, generic OAuth 2.0, Kerberos, JWT, smart card authentication and SCIM user provisioning. In a defense setting, the choice usually follows your existing directory and whether users authenticate with CAC or PIV credentials. Map who can create, approve and administer users, and confirm that deprovisioning through SCIM or LDAP removes access to CUI projects promptly.

Hardening gitlab.rb, CI/CD and the OS

GitLab's hardening guidance covers application settings, CI/CD, configuration files such as gitlab.rb, the operating system and NIST SP 800-53 compliance. Treat it as a work in progress that should be rolled out gradually, with each change tested in a non-production instance and recorded as a configuration baseline. Trace each applied setting to the control family it supports so that assessors can follow the evidence.

Runner isolation and version alignment

GitLab Runner executes CI/CD jobs, so a shared or poorly isolated runner can expose CUI to other projects. Decide which runners may touch CUI repositories, use dedicated hosts or autoscaling VMs for them, and restrict tags and protected branches accordingly. The docs advise keeping Runner major and minor versions aligned with GitLab, which should be part of every upgrade plan.

Backup and restore, including secrets

A backup that omits the secrets file cannot restore encrypted CI variables or two-factor data, so the secrets must be backed up and stored with the same controls as the repositories. Define where backup archives live, who can read them, and how long they are kept. Test a full restore into an isolated environment, because an untested backup gives no assurance for CUI recovery.

Geo only inside approved boundaries

GitLab Geo provides a warm-standby secondary site that is continuously synchronized for disaster recovery. A secondary site holds a full copy of CUI repositories, so it must sit inside the same approved boundary as the primary, with equivalent controls and staff access rules. If your approved boundary is a single enclave, confirm with your assessor whether a second site in another region is in scope before you design around it.

Offline licensing for GitLab Duo and scanners in a closed enclave

Before you commit to a tier, confirm three things for the enclave: how the license reaches the instance without internet access, where the GitLab Duo models run, and how scanner data gets updated. GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Read that guidance with your network team, because each component has its own dependencies. A scanner that works in an offline install can still fail to refresh its vulnerability data if no internal mirror or transfer process exists, and your assessment evidence will show gaps like that quickly.

Tier choice drives what you can switch on. GitLab's pricing page lists Premium at 29 US dollars per user per month billed annually, with Ultimate custom priced, and both tiers are available for self-managed installations. The pricing page places application security testing, software supply chain security, vulnerability management and compliance features in Ultimate, so the scanner and provenance capabilities that support your CMMC evidence depend on that choice, not on the deployment model. Ask for a written quote that names the seat count, the billing term and every feature your control set relies on, and ask whether the Ultimate features you need are delivered to offline instances under the same terms.

Licensing terms for offline use, seat counting for users who never log in, renewal mechanics and any restrictions on hosting self-hosted models must be confirmed in writing with GitLab before you rely on them in a System Security Plan. Treat the pricing page as a starting point, not a contract. Record who in your organization owns license renewal, how an expired license affects a running enclave, and what the update path is for scanner content in each release cycle. Those answers belong in your change and continuity procedures, so an auditor can see that the enclave keeps working and stays current without an internet connection.

How a CUI-bound GitLab rollout runs in phases

The sequence fixes the assessment boundary before any server is built, then moves through architecture, offline installation, identity, runners, migration and evidence, so the system a contractor describes in its SSP is the system it actually runs.

Define the CUI boundary and assessment scope
Before any architecture is chosen, the contractor and DeployOpen identify where CUI is created, stored, processed and transmitted, which users and administrators touch it, and which systems fall inside the assessment boundary. Source control, CI runners, backups, the identity provider and any external services each need an explicit in-scope or out-of-scope decision. The output is a written boundary diagram and a scoping memo that the contractor's assessor or compliance lead has reviewed. Ask early whether any cloud service will hold CUI, because 32 CFR 170.17(c)(5) limits that case to FedRAMP Authorized Moderate or higher services or equivalent requirements.
Size the architecture to user count
Choose between a single node and a reference architecture based on the number of users and API load that the GitLab reference architectures document for your range. The documentation generally recommends a high availability strategy from 3,000 users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Stateful components such as PostgreSQL and Redis should not run inside Kubernetes under the Cloud Native Hybrid pattern, so this decision also sets where those services live. The output is a sized architecture document with named hosts, storage and network paths, reviewed against the enclave's change control process.
Source and install offline
Install GitLab inside the enclave using the offline environment guidance, which covers running self-managed instances in air-gapped networks and separate guidance for security scanners and GitLab Duo Self-Hosted. Choose an install method from the documented options, such as the Linux package, which bundles PostgreSQL, Redis and Sidekiq, or the Helm chart, and confirm that the chosen method has the offline steps you need. Image and package sourcing, transfer through the approved cross-domain process, and the version pinned for the first build should all be recorded. The step is done when the instance runs with no outbound internet dependency and the install record names every artifact by version and checksum.
Configure identity and harden the instance
Connect GitLab to the contractor's corporate identity through the authentication methods the product supports, such as SAML, LDAP, SCIM provisioning or smart card authentication, and disable local access paths that bypass them. Apply the hardening documentation, which covers application settings, CI/CD, gitlab.rb configuration, the operating system and NIST SP 800-53 guidance, in a staged order and record each setting against the control it supports. Confirm with the vendor and your assessor whether a FIPS-enabled image is the right build for your boundary. The step is complete when test accounts show that sign-in, provisioning and deprovisioning behave as the SSP describes.
Stand up the runner fleet inside the enclave
Deploy GitLab Runner inside the enclave, choosing the shell, Docker or autoscaling executor that fits the build workloads, and keep runner major and minor versions aligned with the GitLab version. Runners that process CUI must sit in the assessment boundary, with restricted egress, isolated job environments and no shared runners reaching outside networks. Confirm that the runner registration, tags and protected branches match the access model defined in the earlier steps. The output is a runner inventory showing location, executor, owner and version, plus a test pipeline that completes without any external network call.
Migrate repositories with a verified import plan
Move repositories, issues and pipelines from the existing host using the import methods documented for GitLab, including direct transfer or file export from other GitLab instances, and the supported importers for other Git hosts. Subversion needs external conversion tools, so plan that conversion separately. For each repository, record whether CUI is present, who approves the move, and where the original remains until the cutover is confirmed. The step is done when a sample of migrated projects shows matching commit history, branch protections, members and pipeline definitions, and the CUI repositories are confirmed to sit only inside the boundary.
Collect evidence for the SSP and SPRS
Map each in-scope GitLab configuration, log source, access review and change record to the NIST SP 800-171 requirement it supports, using the revision your contract currently requires. Collect evidence in final form, because a requirement is met only when all applicable assessment objectives are satisfied with evidence that is not a draft. The output is an evidence matrix tied to the system security plan and the score the contractor posts to SPRS. DeployOpen prepares this evidence, but it does not issue assessment results, and the contractor's assessor or certification body makes the determination.
Run day-two upgrades on required stops
Plan every GitLab upgrade through the required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, such as 18.2, 18.5, 18.8, 18.11 and 19.2, 19.5, 19.8 and 19.11. Track the maintenance policy, because bug fixes are backported only to the current stable release while security fixes also reach the previous two monthly releases, so the security patch cadence drives the enclave's update window. Each upgrade is staged in a non-production copy, backed up first, and recorded as a change in the boundary's change management system. The step is complete when the upgrade record shows the stop path followed, the post-upgrade checks passed and the SSP reflects the new version.

What the assessment will ask for as evidence from GitLab

An assessor testing against NIST SP 800-171A will ask for proof that each requirement operates, not just that a setting exists. The cards below map common control families to the GitLab records that usually supply that proof. MET requires evidence in final form, so the records must be captured, retained and reviewable before the assessment begins. DeployOpen prepares this evidence, but assessment results come only from the assessor.

Access control

Assessors look for who can reach CUI repositories and why. Use group and project membership with the least role needed, and keep CUI projects in a dedicated group so access is visible in one place. Record approvals for membership changes as change tickets or issues. Check that project visibility is private by default and that sign-up and external access settings match your system security plan. Confirm which GitLab tier provides each feature you rely on before you commit to the design.

Audit and accountability

Audit events are the core record of administrative and access actions in self-managed GitLab. Decide early where they are forwarded, how long they are retained, and who reviews them on a set schedule. Test that an event such as a permission change can be traced to a named user and a timestamp. Confirm the retention period in your own environment, since your system security plan and the assessor will expect it to match your stated policy.

Identification and authentication

Show that each user maps to a single corporate identity and that authentication is enforced. Connect GitLab to your identity provider with SAML or LDAP, and use SCIM to provision and deprovision users so that departures are reflected in GitLab. Export the provisioning logs and the list of accounts with two-factor authentication enforced. These records show that identifiers are managed and that inactive accounts do not keep access.

Configuration management

Protected branches, required approvals and merge request rules show that changes to CUI code follow an approved path. Export the branch protection settings and a sample of merge requests with reviewer approvals, and keep the settings under change control. Assessors also look at how the GitLab configuration itself is baselined. Keep the configuration file and hardening decisions in version control, and record each change with a reason.

System and communications protection

Evidence here shows that CUI is protected in transit and inside the boundary. Document TLS settings for the GitLab endpoint, the runner network paths and any object storage traffic, and show that the instance does not reach external services it should not reach. For offline deployments, retain the configuration that disables outbound connections. Confirm FIPS-compliant builds with your architect, since image choice changes what the assessor can accept.

Backup and recovery testing

Backups protect against loss, but assessors ask whether restores work. Keep dated restore test records that show a backup was restored to a separate instance and that repositories, users and pipeline definitions were verified. Store these records with the backup logs. Note which items were excluded from the backup and why, and confirm the method with your DeployOpen or GitLab documentation before the first test.

Planning for Rev. 2 now and Rev. 3 later

Design your GitLab control mapping against NIST SP 800-171 Rev. 2 today, because CMMC Level 2 incorporates Rev. 2 and its 110 requirements, and record which requirement set each control statement answers. Keep a simple register with one row per requirement ID, the GitLab setting, runbook or log source that evidences it, and the owner. Where a control depends on a value a contract or the DoW will supply, mark it as an organization-defined parameter (ODP) and name the document where that value is recorded. The Department of War's 2026 deviation and interim guidance keep Rev. 2 in force while CMMC Phase II is suspended, so confirm with your contracting officer which revision your contract names before you finalize the register.

Rev. 3 is the likely next step. It contains 97 requirements in 17 families, numbered 03.01.01 to 03.17.03, and it adds ODPs that nonfederal organizations must assign when the federal agency does not. A FAR overhaul proposed rule published 23 June 2026 would require Rev. 3 with DoW-published ODP values, but it was not final as of October 2026. Ask your contracting office whether ODP values will be published, by whom and when, and plan for a column in the register that holds the Rev. 3 ID and its parameter value. Do not assume the mapping will be a clean renumbering of Rev. 2, because several requirements were withdrawn and new ones were added.

Connect this mapping to the GitLab upgrade plan. Minor releases ship on the third Thursday of each month, security fixes are backported to the previous two monthly releases, and bug fixes only reach the current stable release. Required upgrade stops, such as 19.5, 19.8 and 19.11 in the documented pattern, mean a security fix may need a planned stop rather than a one-step move. Record which GitLab version each control evidence set was tested against, so an assessor can see that a change in the platform did not silently invalidate a mapped control.

What defense contractors ask before a GitLab implementation

What drives the cost of a self-managed GitLab implementation for CUI work?

The main cost drivers are the size of the enclave, the number of users, whether high availability is required, the size of the runner fleet, which GitLab tier you need, how much assessment support you want, and how much offline mirror work the environment requires. Scope of the enclave matters most, because every system that stores, processes or transmits CUI and every connected component may need to be documented and assessed. Premium and Ultimate are priced differently, and the GitLab pricing page lists Ultimate as custom priced, so ask for the tier mapping in writing. Ask any implementation partner for a quote built from a written scope with one-time build work separated from recurring licenses, support and retainers.

Can our own team run a GitLab implementation for CUI in-house?

Many contractors can, provided they have people who understand Linux administration, identity integration, network segmentation, backup and restore, and the NIST SP 800-171 requirements that apply to the system. The harder part is usually not installation but the evidence trail: documented boundaries, configuration baselines, change records and test results that an assessor can verify. Honest self-assessment starts with a skills check against those areas and a review of who would own the system after go-live. An outside partner can take on defined pieces, such as the build, hardening documentation or assessment preparation, while your staff keep operational ownership.

How long does a GitLab deployment for a defense contractor take?

No fixed duration applies to every contractor, because the timeline depends mainly on the boundary decisions made early and on the volume of repositories and pipelines to migrate. Boundary questions include which projects hold CUI, whether runners sit inside the enclave, how identity is federated, and whether the offline or air-gapped mode is required. Migration volume, the number of CI/CD pipelines to rebuild and the approvals needed from your security and program teams all add time. Ask for a timeline in the written scope that lists each dependency and the party responsible for it, rather than accepting a single estimate without those inputs.

What do we need to provide during a GitLab implementation?

The work needs named people and approvals from your side, and delays usually come from their absence. Typical requirements include:

A system owner who can make decisions about scope, boundary and risk acceptance
An assessor or compliance contact who can confirm evidence requirements early
An identity administrator for SAML or LDAP connections and group mapping
Network and firewall approvals for the enclave, runner connectivity and any offline package transfer path
Access to hosting, storage and backup systems within the agreed boundary

Is cloud-hosted GitLab allowed for storing CUI?

Under 32 CFR 170.17(c)(5), a contractor seeking CMMC Level 2 may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. That rule applies to external cloud service providers, so a hosted GitLab service that handles CUI must meet it, and the contractor should confirm the provider's authorization status directly. A self-managed GitLab instance inside your own accredited boundary is assessed within your own scope, which is why many contractors keep CUI repositories on infrastructure they control. Confirm the applicable contract clauses and your assessor's view before choosing a hosting model.

Does DeployOpen certify that our GitLab environment meets CMMC or NIST SP 800-171?

No. DeployOpen plans, implements, hardens and documents self-hosted platforms in your infrastructure, and prepares systems, controls and evidence for compliance assessments. We do not issue audit reports, attestations or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, and Level 3 assessments are performed by DCMA DIBCAC. Confirm the current assessment requirements with your contracting officer, since the Department of War suspended CMMC Phase II on 13 July 2026, and ask your assessor which evidence they will expect.

Which GitLab tier and features do CUI repositories need?

The tier decision depends on which controls you must evidence inside GitLab and which security scanning or compliance features your program requires. GitLab Free and Premium are both available for self-managed installations, and the pricing page lists advanced CI/CD and priority support for Premium, with application security testing, software supply chain security, vulnerability management and compliance features for Ultimate. Map each NIST SP 800-171 requirement family to a feature or process before choosing a tier, and check which scanners work offline if your enclave is air-gapped. Confirm with GitLab which features are available in your chosen tier before you commit to a design.

How DeployOpen scopes and delivers CUI-bound GitLab

DeployOpen plans, implements, hardens, documents and supports self-hosted GitLab inside your own infrastructure, including enclaves and air-gapped networks. For defense contractors handling CUI, the work starts with a written scope that separates the CUI boundary from the rest of the estate, so the controls, evidence and operating procedures are sized to what actually touches CUI.

How we scope

Written scope agreed before work starts, listing which repositories, runners, users and integrations sit inside the CUI boundary
Mapping of GitLab configuration and operating procedures to the NIST SP 800-171 Revision 2 requirements that CMMC Level 2 currently assesses
Confirmation of which GitLab components need FIPS-compliant images, offline licensing and air-gapped scanner or Duo operation

How we build

Installation in your enclave using a method your team has approved, with hardening applied to application settings, runners and the operating system
Identity integration with your directory, enforced two-factor authentication and access roles configured to your separation-of-duties model
Testing of backup, restore and upgrade procedures, with the upgrade path checked against required upgrade stops before any change

How we hand over

Documentation of system configuration, boundary diagrams, runner placement and the evidence each control produces
Runbooks for backup, restore, upgrades, runner maintenance and monitoring, written for your own operations staff
Walkthrough with your assessors' evidence expectations so that artifacts are in final form, not drafts, at the point of assessment

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Planned upgrade reviews against each required upgrade stop, scoped and quoted in writing before each change
Note that DeployOpen prepares systems and evidence but does not issue assessment results, certifications or attestations; your assessor or C3PAO does