Compliance standards
- Tier: Ultimate
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
Version history
- Introduced in GitLab 17.11.
You can use GitLab compliance controls to help meet the requirements of many compliance standards.
The Compliance Adherence Templates project contains a library of JSON templates. Use these templates to quickly adopt predefined compliance frameworks.
FedRAMP compliance requirements
FedRAMP (Federal Risk and Authorization Management Program) categorizes cloud services into three impact levels: Low, Moderate, and High, based on the potential impact of a data breach on government operations, assets, or individuals.
These levels correspond to different sets of security controls and requirements that cloud service providers (CSPs) must meet to achieve FedRAMP authorization. Controls are available for FedRAMP Low, FedRAMP Moderate, and FedRAMP High compliance.
FedRAMP Low compliance requirements
The following table lists the requirements supported by GitLab for FedRAMP Low and the controls for the requirements.
You can use the
fedramp_low_r5.json template
to create a compliance framework for this standard.
| FedRAMP Low requirement | Description | Supported controls |
|---|---|---|
| CM-5: Access Restrictions for Change | Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. |
|
| CM-6: Configuration Settings | Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services. |
|
| CM-10: Software Usage Restrictions | Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work. |
|
| IA-2(12): Acceptance of PIV Credentials | Accept and electronically verify Personal Identity Verification (PIV) credentials. |
|
| IA-8(1): Acceptance of PIV Credentials From Other Agencies | Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies. |
|
| RA-5: Vulnerability Monitoring and Scanning | Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information. |
|
FedRAMP Moderate compliance requirements
The following table lists the requirements supported by GitLab for FedRAMP Moderate and the controls for the requirements.
You can use the
fedramp_moderate_r5.json template
to create a compliance framework for this standard.
| FedRAMP Moderate requirement | Description | Supported controls |
|---|---|---|
| AC-5: Separation of Duties | Separate duties of individuals to prevent malevolent activity without collusion; document separation of duties; and define system access authorizations to support separation of duties. |
|
| CM-3: Configuration Change Control | Determine types of configuration-controlled changes; review and approve changes with security/privacy impact analysis; document decisions; implement approved changes; retain records; monitor activities associated with changes; and coordinate change control oversight through designated elements. |
|
| CM-5: Access Restrictions for Change | Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. |
|
| CM-6: Configuration Settings | Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services. |
|
| CM-10: Software Usage Restrictions | Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work. |
|
| IA-2(12): Acceptance of PIV Credentials | Accept and electronically verify Personal Identity Verification (PIV) credentials. |
|
| IA-5(7): No Embedded Unencrypted Static Authenticators | Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage. |
|
| IA-8(1): Acceptance of PIV Credentials From Other Agencies | Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies. |
|
| RA-5: Vulnerability Monitoring and Scanning | Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information. |
|
| SA-11(1): Static Code Analysis | Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis. |
|
| SA-11(8): Dynamic Code Analysis | Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis. |
|
FedRAMP High compliance requirements
The following table lists the requirements supported by GitLab for FedRAMP High and the controls for the requirements.
You can use the
fedramp_high_r5.json template
to create a compliance framework for this standard.
| FedRAMP High requirement | Description | Supported controls |
|---|---|---|
| AC-5: Separation of Duties | Separate duties of individuals to prevent malevolent activity without collusion; document separation of duties; and define system access authorizations to support separation of duties. |
|
| CM-3: Configuration Change Control | Determine types of configuration-controlled changes; review and approve changes with security/privacy impact analysis; document decisions; implement approved changes; retain records; monitor activities associated with changes; and coordinate change control oversight through designated elements. |
|
| CM-3(1): Automated Documentation, Notification, and Prohibition of Changes | Use automated mechanisms to document proposed changes to the system; notify organization-defined approval authorities; highlight change approvals that have not been received by organization-defined time period; prohibit changes to the system until designated approvals are received; and document all changes to the system. |
|
| CM-5: Access Restrictions for Change | Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. |
|
| CM-6: Configuration Settings | Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services. |
|
| CM-10: Software Usage Restrictions | Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work. |
|
| IA-2(12): Acceptance of PIV Credentials | Accept and electronically verify Personal Identity Verification (PIV) credentials. |
|
| IA-5(7): No Embedded Unencrypted Static Authenticators | Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage. |
|
| IA-8(1): Acceptance of PIV Credentials From Other Agencies | Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies. |
|
| RA-5: Vulnerability Monitoring and Scanning | Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information. |
|
| SA-11(1): Static Code Analysis | Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis. |
|
| SA-11(8): Dynamic Code Analysis | Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis. |
|
IRAP compliance requirements
IRAP is the Infosec Registered Assessors Program. Controls are available for IRAP Official, IRAP Protected, IRAP Secret, and IRAP Top Secret.
IRAP Official
The following table lists the requirements supported by GitLab for IRAP Official and the controls for the requirements.
You can use the
irap_official.json template
to create a compliance framework for this standard.
| IRAP Official requirement | Description | Supported controls |
|---|---|---|
| ISM-0402 Application security testing | Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases. |
|
| ISM-1163 Continuous monitoring plan | Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost. |
|
| ISM-1422 Development, testing and production environments | Unauthorised access to the authoritative source for software is prevented. |
|
| ISM-1698 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services. |
|
| ISM-1700 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products. |
|
| ISM-1701 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices. |
|
| ISM-1702 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices. |
|
| ISM-1808 Scanning for unmitigated vulnerabilities | A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities. |
|
| ISM-1816 Development, testing and production environments | Unauthorised modification of the authoritative source for software is prevented. |
|
| ISM-1875 Protecting credentials | Networks are scanned at least monthly to identify any credentials that are being stored in the clear. |
|
IRAP Protected
The following table lists the requirements supported by GitLab for IRAP Protected and the controls for the requirements.
You can use the
irap_protected.json template
to create a compliance framework for this standard.
| IRAP Protected requirement | Description | Supported controls |
|---|---|---|
| ISM-0402 Application security testing | Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases. |
|
| ISM-1163 Continuous monitoring plan | Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost. |
|
| ISM-1422 Development, testing and production environments | Unauthorised access to the authoritative source for software is prevented. |
|
| ISM-1698 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services. |
|
| ISM-1700 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products. |
|
| ISM-1701 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices. |
|
| ISM-1702 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices. |
|
| ISM-1808 Scanning for unmitigated vulnerabilities | A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities. |
|
| ISM-1816 Development, testing and production environments | Unauthorised modification of the authoritative source for software is prevented. |
|
| ISM-1875 Protecting credentials | Networks are scanned at least monthly to identify any credentials that are being stored in the clear. |
|
IRAP Secret
The following table lists the requirements supported by GitLab for IRAP Secret and the controls for the requirements.
You can use the
irap_secret.json template
to create a compliance framework for this standard.
| IRAP Secret requirement | Description | Supported controls |
|---|---|---|
| ISM-0402 Application security testing | Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases. |
|
| ISM-1163 Continuous monitoring plan | Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost. |
|
| ISM-1422 Development, testing and production environments | Unauthorised access to the authoritative source for software is prevented. |
|
| ISM-1698 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services. |
|
| ISM-1700 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products. |
|
| ISM-1701 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices. |
|
| ISM-1702 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices. |
|
| ISM-1808 Scanning for unmitigated vulnerabilities | A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities. |
|
| ISM-1816 Development, testing and production environments | Unauthorised modification of the authoritative source for software is prevented. |
|
| ISM-1875 Protecting credentials | Networks are scanned at least monthly to identify any credentials that are being stored in the clear. |
|
IRAP Top Secret
The following table lists the requirements supported by GitLab for IRAP Top Secret and the controls for the requirements.
You can use the
irap_top_secret.json template
to create a compliance framework for this standard.
| IRAP Top Secret requirement | Description | Supported controls |
|---|---|---|
| ISM-0402 Application security testing | Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases. |
|
| ISM-1163 Continuous monitoring plan | Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost. |
|
| ISM-1422 Development, testing and production environments | Unauthorised access to the authoritative source for software is prevented. |
|
| ISM-1698 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services. |
|
| ISM-1700 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products. |
|
| ISM-1701 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices. |
|
| ISM-1702 Scanning for unmitigated vulnerabilities | A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices. |
|
| ISM-1808 Scanning for unmitigated vulnerabilities | A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities. |
|
| ISM-1816 Development, testing and production environments | Unauthorised modification of the authoritative source for software is prevented. |
|
| ISM-1875 Protecting credentials | Networks are scanned at least monthly to identify any credentials that are being stored in the clear. |
|
ISMAP compliance requirements
The Information system Security Management and Assessment Program (ISMAP) aims to secure the security level of the government's cloud service procurement by evaluating and registering cloud services that meet the security requirements of the government in advance, thereby contributing to the smooth introduction of cloud services.
The following table lists the requirements supported by GitLab for ISMAP and the controls for the requirements.
You can use the
ismap.json template
to create a compliance framework for this standard.
| ISMAP requirement | Description | Supported controls |
|---|---|---|
| 6.1.2 Segregation of duties | Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization's assets. |
|
| 9.3.1 Use of secret authentication information | Users should be required to follow the organization's practices in the use of secret authentication information. |
|
| 9.4.5 Access control to program source code | Access to program source code should be restricted. |
|
| 12.1.2 Change management | Changes to the organization, business processes, information processing facilities and systems that affect information security should be controlled. |
|
| 12.6.1 Management of technical vulnerabilities | Information about technical vulnerabilities of information systems being used should be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk. |
|
| 14.2.1 Secure development policy | Rules for the development of software and systems should be established and applied to developments within the organization. |
|
| 14.2.8 System security testing | Testing of security functionality should be carried out during development. |
|
| 18.1.2 Intellectual property rights | Appropriate procedures should be implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products. |
|
ISO 27001 compliance requirements
ISO 27001 is an internationally recognized standard that provides a framework for implementing and managing an Information Security Management System (ISMS).
The following table lists the requirements supported by GitLab for ISO 27001 and the controls for the requirements.
You can use the
iso_27001:2022.json template
to create a compliance framework for this standard.
| ISO 27001 requirement | Description | Supported controls |
|---|---|---|
| 5.3 Segregation of duties | Conflicting duties and conflicting areas of responsibility shall be segregated. |
|
| 5.17 Authentication information | Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information. |
|
| 5.18 Access rights | Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization's topic-specific policy on and rules for access control. |
|
| 5.32 Intellectual property rights | The organization should implement appropriate procedures to protect intellectual property rights. |
|
| 8.4 Access to source code | Read and write access to source code, development tools and software libraries shall be appropriately managed. |
|
| 8.8 Management of technical vulnerabilities | Information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken. |
|
| 8.28 Secure coding | Secure coding principles shall be applied to software development. |
|
| 8.29 Security testing in development and acceptance | Security testing processes shall be defined and implemented in the development lifecycle. |
|
| 8.32 Change management | Changes to information processing facilities and information systems shall be subject to change management procedures. |
|
NIST compliance requirements
The National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL) provides standards, measurements, and testing for information systems, focusing on interoperability, security, usability, and reliability. These compliance standards involves implementing security and privacy controls across various areas, including:
- Risk management
- Identification and authentication
- Incident response
- System and communications protection
Controls are available for NIST 800-53, NIST 800-171, NIST SP 800-218, and NIST CSF 2.0 compliance standards.
NIST 800-53 compliance requirements
The following table lists the requirements supported by GitLab for NIST 800-53 Revision 5 and the controls for the
requirements.
You can use the
nist_800-53_r5 template
to create a compliance framework for this standard.
| NIST 800-53 requirement | Description | Supported controls |
|---|---|---|
| AC-3(2): Dual Authorization | Enforce dual authorization for organization-defined privileged commands and/or other organization-defined actions. |
|
| AC-5: Separation of Duties | Separate duties of individuals to prevent malevolent activity without collusion; document separation of duties; and define system access authorizations to support separation of duties. |
|
| AU-9(5): Dual Authorization | Enforce dual authorization for the deletion or modification of organization-defined audit information. |
|
| CM-3: Configuration Change Control | Determine types of configuration-controlled changes; review and approve changes with security/privacy impact analysis; document decisions; implement approved changes; retain records; monitor activities associated with changes; and coordinate change control oversight through designated elements. |
|
| CM-3(1): Automated Documentation, Notification, and Prohibition of Changes | Use automated mechanisms to document proposed changes to the system; notify organization-defined approval authorities; highlight change approvals that have not been received by organization-defined time period; prohibit changes to the system until designated approvals are received; and document all changes to the system. |
|
| CM-5: Access Restrictions for Change | Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. |
|
| CM-5(4): Dual Authorization | Enforce dual authorization for implementing changes to organization-defined system components and system-level information. |
|
| CM-6: Configuration Settings | Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services. |
|
| CM-9(1): Assignment of Responsibility | Assign responsibility for developing the configuration management process to organizational personnel that are not directly involved in system development. |
|
| CM-10: Software Usage Restrictions | Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work. |
|
| CP-9(7): Dual Authorization | Enforce dual authorization for the deletion or destruction of organization-defined backup information. |
|
| IA-2(10): Single Sign-on | Provide a single sign-on capability for organization-defined system accounts and services. |
|
| IA-2(12): Acceptance of PIV Credentials | Accept and electronically verify Personal Identity Verification (PIV) credentials. |
|
| IA-5(7): No Embedded Unencrypted Static Authenticators | Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage. |
|
| IA-5(9): Federated Credential Management | Use organization-defined external organizations to federate credentials. |
|
| IA-8(1): Acceptance of PIV Credentials From Other Agencies | Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies. |
|
| IA-8(5): Acceptance of PIV-I Credentials | Accept and verify Personal Identity Verification-I (PIV-I) credentials. |
|
| RA-5: Vulnerability Monitoring and Scanning | Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information. |
|
| SA-11(1): Static Code Analysis | Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis. |
|
| SA-11(8): Dynamic Code Analysis | Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis. |
|
NIST 800-171 compliance requirements
The following table lists the requirements supported by GitLab for NIST 800-171 Revision 3 CMMC and the controls for
the requirements.
You can use the
nist_800-171_r3_cmmc.json template
to create a compliance framework for this standard.
| NIST 800-171 requirement | Description | Supported controls |
|---|---|---|
| 03.01.04 Separation of Duties | a) Identify the duties of individuals requiring separation. b) Define system access authorizations to support separation of duties. |
|
| 03.04.04 Impact Analyses | a) Analyze changes to the system to determine potential security impacts prior to change implementation. b) Verify that the security requirements for the system continue to be satisfied after the system changes have been implemented. |
|
| 03.04.05 Access Restrictions for Change | a) Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. |
|
| 03.04.10 System Component Inventory | a) Develop and document an inventory of system components. b) Review and update the system component inventory (organization-defined frequency). c) Update the system component inventory as part of installations, removals, and system updates. |
|
| 03.05.07 Password Management | b) Verify that passwords are not found on the list of commonly used, expected, or compromised passwords when users create or update passwords. c) Transmit passwords only over cryptographically protected channels. d) Store passwords in a cryptographically protected form. |
|
| 03.11.02 Vulnerability Monitoring and Scanning | a) Monitor and scan the system for vulnerabilities (organization-defined frequency) and when new vulnerabilities affecting the system are identified. c) Update system vulnerabilities to be scanned (organization-defined frequency) and when new vulnerabilities are identified and reported. |
|
NIST CSF 2.0 compliance requirements
The following table lists the requirements supported by GitLab for NIST CSF and the controls for the requirements.
You can use the
nist_csf_2.json template
to create a compliance framework for this standard.
| NIST CSF 2.0 requirement | Description | Supported controls |
|---|---|---|
| ID.RA-01 - Identity - Risk Assessment: The cybersecurity risk to the organization, assets, and individuals is understood by the organization. | Vulnerabilities in assets are identified, validated, and recorded. |
|
| ID.RA-07 - Identity - Risk Assessment: The cybersecurity risk to the organization, assets, and individuals is understood by the organization. | Changes and exceptions are managed, assessed for risk impact, recorded, and tracked. |
|
| PR.AA-05 - Protect - Identity Management, Authentication, and Access Control - Access to physical and logical assets is limited to authorized users, services, and hardware and managed commensurate with the assessed risk of unauthorized access. | Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties. |
|
| PR.PS-06 - Protect - Platform Security - Management of hardware, software, and services aligned with risk strategy. | Secure software development practices are integrated, and their performance is monitored throughout the software development lifecycle. |
|
NIST SP 800-218 compliance requirements
The following table lists the requirements supported by GitLab for NIST SP 800-218 and the controls for the requirements.
You can use the
nist_800-218_v1-1.json template
to create a compliance framework for this standard.
| NIST SP 800-218 requirement | Description | Supported controls |
|---|---|---|
| PO.1.1 Define Security Requirements for Software Development | PO.1.1: Identify and document all security requirements for the organization's software development infrastructures and processes, and maintain the requirements over time. |
|
| PW.4 Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality | PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization's software. PW.4.4: Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles. |
|
| PW.5.1 Create Source Code by Adhering to Secure Coding Practices | PW.5.1: Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization's requirements. |
|
| PW.7 Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements | PW.7.1: Implement code review (manual inspection) and/or code analysis (tool-based scanning) according to organizational needs. Perform these reviews based on secure coding standards and track all discovered issues in the development workflow system. |
|
| PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements | PW.8.2: Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team's workflow or issue tracking system. |
|
| RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis | RV.1.1: Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports. |
|
PCI DSS v4.0.1 compliance requirements
PCI DSS is the PCI Data Security Standard.
The following table lists the requirements supported by GitLab for PCI DSS v4.0.1 and the controls for the requirements.
You can use the
pci_dss_v4-0-1.json template
to create a compliance framework for this standard.
| PCI DSS v4.0.1 requirement | Description | Supported controls |
|---|---|---|
| 6.2 Bespoke and custom software are developed securely. | 6.2.3 Review bespoke and custom software prior to release to identify and correct coding vulnerabilities. Ensure code follows secure coding guidelines and addresses emerging vulnerabilities. Implement software engineering techniques to prevent common software attacks. |
|
| 6.5 Changes to all system components are managed securely. | 6.5.1 Implement changes to system components according to established procedures including: documenting reason and description, security impact analysis, approval by authorized parties, and testing for security impacts. Separate production and pre-production environments. 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls. 6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. |
|
| 7.2 Access to system components and data is appropriately defined and assigned. | 7.2.5 All application and system accounts and related access privileges are assigned and managed as follows: Based on the least privileges necessary for the operability of the system or application; access is limited to the systems, applications, or processes that specifically require their use. |
|
| 7.3 Access to system components and data is managed via an access control system(s). | 7.3.1 An access control system(s) is in place that restricts access based on a user's need to know and covers all system components. 7.3.2 The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function. |
|
| 8.3 Strong authentication for users and administrators is established and managed. | 8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: Something you know, such as a password or passphrase; something you have, such as a token device or smart card; Something you are, such as a biometric element. |
|
| 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE. | 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access. 8.4.2 MFA is implemented for all non-console access into the CDE. |
|
| 8.6 Use of application and system accounts and associated authentication factors is strictly managed. | 8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. |
|
| 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed. | 11.3.1 Perform internal vulnerability scans using authenticated scanning methods. Address high-risk/critical vulnerabilities promptly and manage other vulnerabilities based on risk assessment. Conduct scans after significant changes to systems. 11.3.2 Perform external vulnerability scans via qualified personnel. Address high-risk/critical vulnerabilities promptly and manage other vulnerabilities based on risk assessment. Conduct scans after significant changes to systems. |
|
SOC 2 compliance requirements
SOC is the System and Organization Controls.
The following table lists the requirements supported by GitLab for SOC 2 and the controls for the requirements.
You can use the
soc2.json template
to create a compliance framework for this standard.
| SOC 2 requirement | Description | Supported controls |
|---|---|---|
| CC3.2 - COSO Principle 7: The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. | POF 7: Identifies Vulnerability of System Components — The entity identifies the vulnerabilities of system components, including system processes, infrastructure, software, and other information assets. |
|
| CC3.4 - COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control. | POF 4: Assess changes from systems, technology environment, and evolving threats/vulnerabilities. Evaluate impact on internal controls and security posture to identify and address resulting risks. |
|
| CC5.1 - COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. | POF 6: Addresses Segregation of Duties — Management segregates incompatible duties and, where such segregation is not practical, management selects and develops alternative control activities. |
|
| CC6.6 - The entity implements logical access security measures to protect against threats from sources outside its system boundaries. | POF 2: Protects Identification and Authentication Credentials — Identification and authentication credentials are protected during transmission outside its system boundaries. |
|
| CC6.8 - The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives. | POF 2: Detects Unauthorized Changes to Software and Configuration Parameters — Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software. |
|
| CC7.1 - To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities. | POF 5: Conducts Vulnerability Scans — The entity conducts infrastructure and software vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes are made to the environment. Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity's objectives. |
|
| CC7.2 - System monitoring for anomalies and security event analysis. | POF 1: Implement detection policies, procedures, and tools on infrastructure and software to identify potential intrusions, unauthorized access, and unusual system activity. Use intelligence sources to identify new threats and vulnerabilities. |
|
| CC8.1 - The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. | POF 2: Implement processes to authorize system changes before design or acquisition, test changes prior to production deployment, require formal approval of system changes, and protect confidential information during development and change processes. |
|
TISAX compliance requirements
TISAX is the Trusted Information Security Assessment Exchange.
The following table lists the requirements supported by GitLab for TISAX and the controls for the requirements.
You can use the
tisax.json template
to create a compliance framework for this standard.
| TISAX requirement | Description | Supported controls |
|---|---|---|
| 1.2.2 To what extent are information security responsibilities organized? | A successful ISMS requires clear responsibilities within the organization. An appropriate organizational separation of responsibilities should be established in order to avoid conflict of interests (separation of duties). (C, I, A) |
|
| 1.3.4 To what extent is it ensured that only evaluated and approved software is used for processing the organization's information assets? | Information processing is mostly done using of specific software. Security issues in software will easily become a risk for the information processed. Accordingly, software must be appropriately managed. Software is approved before installation or use. The software repositories are protected against unauthorized manipulation. Approval of software is regularly reviewed. Software versions and patch levels are known. |
|
| 5.2.1 To what extent are changes managed? | The objective is to ensure that information security aspects are considered in case of any changes to the organization, business processes and IT systems (Change Management) in order to prevent these changes from causing an uncontrolled reduction in the information security level. Information security requirements for changes to the organization, business processes, IT systems are determined and applied. A formal approval procedure is established. |
|
| 5.2.5 To what extent are vulnerabilities identified and addressed? | Gather and evaluate information on technical vulnerabilities affecting IT systems. Identify and assess potentially affected systems and software, then address vulnerabilities based on risk assessment to prevent exploitation by attackers. |
|
| 5.3.1 To what extent is information security considered in new or further developed IT systems? | Incorporate information security throughout IT system lifecycle. Determine and address security requirements during design, development, acquisition, and system changes. Conduct security-focused approval testing for all IT systems. |
|
| 7.1.1 To what extent is compliance with regulatory and contractual provisions ensured? | Non-compliance with legal, regulatory, or contractual provisions can create risks to the information security of customers and the own organization. Therefore, it is essential to ensure that these provisions are known and observed. Legal, regulatory, and contractual provisions of relevance to information security (see examples) are determined at regular intervals. |
|