How GitLab supports CMMC Level 2 configuration management
A defense contractor handling CUI must show assessors how configuration changes are authorized, tested and recorded, and self-managed GitLab can supply much of that change approval, audit and access evidence inside a CUI enclave. It covers only part of the picture, though. Under 32 CFR 170.14(c)(3), CMMC Level 2 requirements are identical to NIST SP 800-171 Revision 2, which 32 CFR 170.4 counts as 110 requirements, so GitLab supports some of those requirements through merge request approvals, protected branches, audit events and access controls, while the rest sit with policy, personnel, physical and network controls that a tool cannot satisfy. Confirm which requirements your team maps to GitLab before you make any claim to an assessor.
NIST published SP 800-171 Revision 3 on 14 May 2024, and that version is current, but the CMMC rule still incorporates Revision 2. The Department of War said on 13 July 2026 that it will enforce Revision 2 in the interim, and a class deviation signed 3 September 2026 names Revision 2 in the contract clause. A FAR overhaul proposed rule published 23 June 2026 would move contractors to Revision 3 with organization-defined parameter values published by the DoW CIO, but it was not final as of October 2026. Plan the GitLab evidence design so it can be re-mapped to Revision 3 requirement IDs, and check the current status of CMMC Phase II and the proposed FAR rule with your contracting officer before you commit scope.
DeployOpen plans, builds and documents self-managed GitLab inside your enclave, configures protected branches, approval rules and audit events, and prepares the evidence that your assessor will examine. DeployOpen does not issue CMMC certifications or assessment results. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, and self-assessments are your organization's responsibility. Ask any implementation partner, including DeployOpen, to show in writing which control objectives each GitLab setting supports and where the evidence stops, and read the CMMC Model Overview to confirm requirement IDs before the scope is agreed.
Mapping NIST SP 800-171 Rev. 2 configuration requirements to GitLab features
This table pairs Level 2 requirement IDs from NIST SP 800-171 Rev. 2 with the GitLab settings that typically support them, based on GitLab's NIST SP 800-53 hardening guidance. Read each row as a starting configuration, not a finding: the assessor still checks each requirement against the SP 800-171A objectives and needs evidence in final form. GitLab settings alone do not satisfy a requirement, so the surrounding process and records matter as much as the feature.
| Requirement (Rev. 2 ID) | GitLab configuration needed | Objective-level evidence to confirm |
|---|---|---|
| CM.L2-3.4.3 (track, review and approve changes) | Merge requests with required approvals, protected default branch, and approval rules for production-affecting projects | Approval records showing reviewer independence and that each change was approved before merge, confirmed against SP 800-171A objectives |
| CM.L2-3.4.5 (control changes to production) | Protected environments and deploy approvals in CI/CD, with developers limited from deploying directly to production | Pipeline and deployment logs tying each production change to an approved merge request |
| CM.L2-3.4.1 (baseline configuration) | Version-controlled configuration repositories, including gitlab.rb and runner settings, with protected branches | Commit history and tagged baselines that show the approved configuration state at a given time |
| AU.L2-3.3.1 (create and retain audit records) | Audit events enabled and retained, with the instance and project audit streams configured | Retained audit event exports covering the assessment period, with retention settings documented |
| AU.L2-3.3.5 (correlate audit records) | Audit events streamed to the organization SIEM, with consistent user identity from SAML or LDAP | SIEM correlation rules or searches that link GitLab events to user identities and other system logs |
| IA.L2-3.5.3 (multifactor authentication) | Two-factor authentication enforced for all users, with SAML or LDAP as the primary sign-in path | Enforcement setting screenshots or exports and a list of any exceptions with approval records |
| SC.L2-3.13.11 (FIPS-validated cryptography) | FIPS versions of GitLab container images and FIPS-enabled host operating system, deployed in the CUI enclave | Image and host configuration records; confirm with the assessor how the cryptographic modules are validated and scoped |
| CP.L2-3.12.3 and CP.L2-3.8.9 (backup and recovery of CUI systems) | Geo secondary site in a separate location and tested backup and restore procedures, with the enclave boundary respected | Restore test records and Geo replication status; confirm whether the secondary site falls inside the assessed boundary |
What evidence GitLab produces for assessors and how to keep it
An assessor will not accept a claim that a change was reviewed. They will ask for a record that shows who approved it, what ran, and who could touch the logs. The cards below cover the GitLab records that answer those questions, and the retention, export and tamper controls that keep them usable for the assessment.
Audit events as the change trail
Audit events record administrative actions such as permission changes, project settings edits and protected branch changes. For configuration management, they show who altered the controls that govern changes. Check that audit events are enabled for every group that holds CUI-related code, and confirm that they are streamed to your SIEM rather than left only inside GitLab, so they survive an instance rebuild.
Merge request approval records
Merge request approvals, along with the approver list and the protected branch rules, show that a second person reviewed each change before it reached a controlled branch. Assessors look for approvals that were recorded before the merge, from people other than the author. Confirm that approval rules cannot be removed by the people they govern, and that the approval history is kept with the merge request.
Pipeline logs and job artifacts
Pipeline records show which commit was tested, which jobs ran, which runner executed them and what they produced. Together with the merge request, they tie a deployed change to its tests and scans. Decide how long job logs and artifacts are kept, and confirm that the runners that handle CUI code are inside the enclave and log to the same retention period as the rest of the evidence.
Access and authentication logs
Sign-in records, failed attempts and changes to SSH keys and tokens show who could reach the repositories and when. These logs support identification and authentication practices and help explain any change made under an unexpected account. Confirm that SAML or LDAP sign-ins and two-factor events are captured in the logs you export, not only in the identity provider.
Final form, not drafts
Under 32 CFR 170.16 and 170.24(b), a requirement counts as MET only when its assessment objectives are satisfied with evidence in final form, not drafts. In GitLab, that means an approved, merged and tested change, and a policy document that has been approved and dated. Exports of unmerged merge requests or draft wiki pages will not satisfy an assessor, so label each export with its completion status.
Retention, export and tamper protection
Decide retention periods for each record type in writing, and set the SIEM retention to meet or exceed them. Export logs on a schedule to write-once storage inside the enclave, and restrict who can delete or edit exported files. Verify exports periodically by checking hashes, and test a restore so you can show the evidence can be read. Confirm the retention figure your contracting officer or assessor expects before you set it.
How the CUI enclave, runners and offline operation fit together
The trust boundary for CUI sits around the self-managed GitLab instance, its runners and every path that moves code, packages or container images across the enclave edge. Decide first which components hold CUI in source, issues, job logs and artifacts, because those are the systems the Level 2 assessment will examine. The GitLab instance, its PostgreSQL and Redis services, Gitaly storage, object storage for artifacts and backups, and the runners that execute pipelines should all sit inside the enclave boundary. Anything outside it, including a vendor-hosted SaaS runner or an external container registry, becomes a question you must answer in your system security plan before it is used.
Offline operation is a design choice you make before installation, not a switch you flip later. GitLab documents running self-managed instances in offline, air-gapped environments and provides separate guidance for its security scanners and for GitLab Duo Self-Hosted. Confirm with GitLab, feature by feature, which capabilities work without internet access in your target version, because scanner vulnerability data, pipeline templates and some integrations may depend on outbound connections. Runners need the same treatment: confirm that the images and packages they pull resolve to an internal registry, and that runner versions match the GitLab version as the Runner documentation advises.
Everything that crosses the boundary is an intake event that should leave a record. Plan a controlled import path for the Linux package or container images, runner binaries, dependency mirrors and scanner signatures, with a hash check and an approval entry for each transfer. Decide who may bring media across, where it is staged and how the transfer log feeds your audit events. Ask your assessor early whether they expect this intake process to appear in the configuration management evidence, since a transfer that no one can trace will weaken the change record that the rest of the enclave depends on.
What GitLab does not cover for CMMC
GitLab can evidence change management and secure development inside the CUI enclave, but it covers only part of the Level 2 picture. The cards below list the areas that stay with your organization, from physical controls and endpoints to your own SSP, POA&M and the parameter values that Rev. 3 leaves to you.
Physical and personnel controls
GitLab has no view of the data center floor, badge access to server rooms, visitor logs or personnel screening. Those controls protect the hosts running GitLab and the people who approve merge requests, so they need their own evidence. Check that administrators with root access to the GitLab hosts are covered by your personnel and physical security procedures, and that approver roles are reviewed when staff leave.
Enclave network access
Who can reach the GitLab instance, its runners and its container registry is decided by your network boundary, not by GitLab. Firewall rules, segmentation between the CUI enclave and corporate networks, and remote access paths must be documented and tested separately. Confirm that runners in the enclave cannot initiate outbound connections that bypass your boundary controls.
Endpoint and workstation controls
Developers push code from laptops and workstations that GitLab cannot inspect. Disk encryption, endpoint protection, patching and local credential storage on those devices fall under your endpoint program. A compromised workstation can still submit a change that looks legitimate, so verify that enclave users work only on managed, configured devices.
Policy, training and incident response
GitLab records what happened, but it does not define who may approve a change, how security incidents are declared or how staff are trained. Your written policies, role-based training records and incident response plan must name GitLab roles and audit log review as part of the process. Test the plan with a scenario, such as an unauthorized change to a protected branch.
Your SSP, POA&M and CUI scoping
The System Security Plan describes how your enclave meets each requirement, and the Plan of Action and Milestones tracks what is not yet met. Neither is produced by GitLab, and both must reflect your actual boundary, including which repositories hold CUI and which systems inherit controls from GitLab. Assessors examine these documents, so keep them consistent with the configuration you have in place.
Rev. 3 parameters and a moving rule
Rev. 3 requires you to assign organization-defined parameter values where a federal agency has not specified them, and the rule is still changing. A FAR overhaul proposal would move contractors to Rev. 3 with DoW-published parameter values. Confirm with your contracting officer which revision applies to each contract, and record your parameter choices in the SSP.
NIST guidance is not a compliance finding
GitLab's NIST SP 800-53 hardening guidance lists settings, audit events and FIPS images, and it states that the guidance alone does not make a system fully compliant. Treat it as a configuration baseline that you verify and document, not as proof of any requirement. Assessors look for your evidence of implementation, not for vendor statements.
Configuration sequence for a compliant GitLab enclave
This sequence builds a self-managed GitLab instance inside a CUI enclave in an order that produces the evidence a CMMC Level 2 assessment examines. Each step ends with a check that the team can show to an assessor. The order matters because later controls depend on the boundary, identity and logging decisions made earlier.
Scope the CUI boundary first
The security lead and the GitLab administrators list every system that stores, processes or transmits CUI in the development workflow. That includes the GitLab instance, its database and object storage, Runners, backup targets, the identity provider, the SIEM and any workstation that pushes code. Anything outside the boundary is kept out of CUI repositories, and connections across the boundary are documented. Done when the team has a boundary diagram and an asset list that the system security plan can cite.
Choose install method and edition
The platform team selects an install method from the Linux package, Helm chart, GitLab Operator, Docker or source, and documents why. The Linux package is the method GitLab describes as most mature, while the other options add container platform dependencies that the enclave must also secure. The team then maps each required control, such as approvals, audit or security scanning, to a tier (Free, Premium or Ultimate) and confirms the tier with GitLab in writing. Done when an edition decision record lists each feature the controls depend on.
Enable SAML or LDAP with two-factor
The identity team connects GitLab to the enclave's directory using SAML or LDAP, and configures SCIM provisioning if the identity provider supports it. Two-factor authentication is enforced for every account, including administrators and service-related human accounts. Local password sign-in is limited to a documented break-glass path. Done when a test user cannot sign in without the second factor, and a disabled directory account loses GitLab access in a tested deprovisioning run.
Configure protected branches and approvals
The engineering lead sets protected branches for release and production-bound code, restricts who can push and merge, and requires merge request approvals from reviewers who did not author the change. Required pipelines and approval rules are set so that no change reaches a protected branch without the approvals the change policy requires. Done when a test merge request without approval is blocked, and the team exports the protected branch and approval settings as configuration records for the assessment file.
Stream audit events to the SIEM
The security operations team configures GitLab to send audit events to the SIEM, following the audit event guidance in GitLab's NIST SP 800-53 documentation. They confirm which event types the tier produces and which must come from another source, then align clocks so timestamps can be correlated. Alerting rules cover changes to users, permissions, protected branches and CI/CD settings. Done when test actions in GitLab appear in the SIEM with the expected actor, object and time.
Deploy FIPS images and harden the instance
The platform team pulls the FIPS versions of GitLab container images where the chosen install method uses containers, and confirms with GitLab which components in the enclave are covered. They then work through GitLab's hardening guidance for application settings, gitlab.rb, Runners and the operating system, rolling out changes gradually because GitLab describes that guidance as a work in progress. Offline installs use an internal package and registry source. Done when each hardening decision is recorded as applied, deferred or not applicable, with a reason.
Plan upgrades through required stops
The operations team writes an upgrade plan that moves the instance only through GitLab's required upgrade stops, which fall at versions x.2, x.5, x.8 and x.11 under the current upgrade paths documentation. The plan also accounts for the maintenance policy, which backports security fixes to more releases than bug fixes, so security patches can be scheduled promptly. Each upgrade is rehearsed in a staging copy inside the enclave with the same configuration. Done when the plan names the target stop, the rehearsal result and the change record that will authorize production work.
Test restore and collect SSP evidence
The operations team runs a full backup and restore test into an isolated environment, following GitLab's backup and restore guidance, and includes the secrets files that the restore depends on. They then gather configuration exports, approval records, audit event samples, authentication settings and test results into one evidence set. Each piece is kept in final form, because assessment objectives are met only with final evidence. Done when the system security plan cites the evidence set, and an independent assessor or the team's compliance lead has reviewed the mapping to NIST SP 800-171A objectives.
Questions buyers ask before hiring help with GitLab and CMMC
What does help with GitLab for CMMC cost, and what drives it?
Cost comes from three parts: the GitLab subscription, the infrastructure you run it on, and the services scope agreed in writing. A quote follows from that written scope, and DeployOpen does not publish a price list. The subscription is the one part with a public figure: the GitLab pricing page lists Premium at 29 US dollars per user per month billed annually, Ultimate is custom priced, and both are available for self-managed installations. Services are usually one-time, while licenses, hosting, backups and any ongoing support recur. Costs rise with the edition, user count, number of enclaves and integrations, runner fleets, and offline work such as moving packages and images into the enclave. Ask each quote to split one-time from recurring costs and to name which features depend on the tier.
How do user count and enclave scope change the GitLab project?
User count and environment design change the scope more than the software does. GitLab's published reference architectures run from 1,000 users at 20 API requests per second to 50,000 users at 1,000 requests per second, and the documentation generally recommends a high availability strategy at 3,000 or more users. A high availability build adds Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, which means more hosts to build, patch, back up and test. Enclave work adds boundary controls, separate identity and logging paths, and evidence collection. Ask for the user count, peak CI load, number of runners, and whether a secondary site is required for recovery, since Geo is available in Premium and Ultimate.
How long does a GitLab deployment for a CUI enclave take?
No duration should be fixed until the scope is written, and a credible partner will not promise one earlier. The main drivers are the number of users and environments, whether the enclave network and identity provider already exist, how many integrations and runners are involved, and whether the environment is offline. Offline work adds time for mirroring GitLab packages, container images and scanner data into the enclave before anything installs. Upgrades also shape the calendar, because GitLab requires upgrade stops at versions such as 18.2, 18.5 and 19.2, so the upgrade plan belongs in the schedule from the start. Ask for milestones with clear entry and exit criteria, and a list of the dependencies the client must clear before each one begins.
What do we need to provide before a GitLab enclave project starts?
Most delays come from decisions the client has not yet made, so list the inputs before scoping. Expect to provide a written description of the CUI boundary and the systems inside it, the identity provider and group model, network and egress rules, storage and backup targets, and a named list of administrators and approvers. You will also need your existing security plan or equivalent documentation, your approved change process, and the staff who own the business processes being evidenced. For offline work, provide an approved transfer path for importing packages and images. Confirm which CMMC level and which NIST SP 800-171 requirements your contracts apply. Ask the partner to return the inputs with owners and due dates as part of the written scope.
Can our internal team run CMMC-aligned GitLab without a partner?
Yes, an internal team can do much of this, but it needs people who understand both GitLab operations and NIST SP 800-171 evidence. Build tasks include choosing the install method, configuring backups and testing restores, keeping runners aligned with GitLab versions, and running an upgrade calendar. GitLab's maintenance policy shows the operating load: bug fixes are backported only to the current stable release, while security fixes also go to the previous two monthly releases, so patches must be tracked and applied on time. The hardest part is usually evidence, meaning final records that show each requirement was met over time. Ask whether you have capacity for patch cycles, evidence collection and assessment preparation for the life of the system, not only for the first build.
Does the current CMMC phase change how we set up GitLab?
The phase changes timing and the contract obligations that apply, but the Level 2 control set is the same. The Department of War announced on 13 July 2026 that it suspended CMMC Phase II, which had been scheduled to begin 10 November 2026 and would have required Level 2 certification assessments for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. A class deviation signed 3 September 2026 has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2. Level 2 still uses the 110 Revision 2 requirements. Because this status has changed more than once, confirm the current requirement with your contracting officer and the DoW CIO CMMC page before fixing the scope.
Why can DeployOpen not certify our CMMC Level 2 status?
Certification sits outside DeployOpen's role. Under the CMMC program rule, Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and Level 3 assessments are performed by DCMA DIBCAC. Self-assessments are carried out by the organization itself. DeployOpen plans, implements and documents the GitLab environment and prepares systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. An independent assessor decides whether each requirement is met, using the assessment objectives in NIST SP 800-171A. Be wary of any provider that promises certification or a pass. The 32 CFR Part 170 text sets out the assessment roles.
Does self-managed GitLab make us CMMC compliant by itself?
No. GitLab supports several requirements, but it cannot make a system compliant on its own. GitLab's own NIST SP 800-53 hardening guidance lists audit events streamed to a SIEM, FIPS versions of container images, SAML and LDAP, two-factor authentication and Geo replication among the features administrators configure, and it states that the guidance alone does not make a fully compliant system. CMMC Level 2 draws on the 110 requirements in 14 families of NIST SP 800-171 Revision 2, which cover far more than the code platform, including media protection, incident response, personnel security and physical protection. Map each requirement to a documented procedure, a configured control and a dated evidence record, and identify which requirements sit outside GitLab entirely.
How DeployOpen scopes and delivers GitLab compliance configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For GitLab in a CUI enclave, we start with the configuration management evidence your assessor will ask for, then build the approval, logging and offline controls that produce it. Scope is agreed in writing before work begins.
How we scope
- Written scope listing the CUI boundary, GitLab instances, runners and identity sources in the enclave
- Mapping of protected branches, approvals and audit events to the CMMC Level 2 requirements in scope
- Confirmation of which NIST SP 800-171 revision your contract and DFARS clause currently require before design starts
How we build
- Protected branch, approval and pipeline settings configured and tested on a non-production instance before the enclave go-live
- Audit event forwarding to your SIEM, with GitLab hardening guidance applied in gradual steps as the guidance recommends
- Offline installation from a mirrored package and image set, with FIPS images where requirements call for them
How we hand over
- Runbook for approval, backup, restore and upgrade procedures, including required upgrade stops
- Evidence collection guide describing where each control's records live and who exports them for an assessment
- Documented system security plan inputs and a list of open items, with owners and dates agreed in writing
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Upgrade planning against GitLab's release cadence, with required upgrade stops and a test instance first
- Re-review of the evidence set when CMMC or NIST requirements in force change, under a new written scope
