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.
| 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 configuration settings for components employed in the system that reflect the most restrictive mode consistent with operational requirements using organization-defined common secure configurations; implement the configuration settings; identify, document, and approve any deviations from established configuration settings for organization-defined system components based on organization-defined operational requirements; and monitor and control changes to the configuration settings in accordance with organizational policies and procedures. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and prohibit or restrict organization-defined functions, system ports, protocols, software, 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.
| 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 and document the types of changes to the system that are configuration-controlled; review proposed configuration-controlled changes and approve or disapprove such changes with explicit consideration for security and privacy impact analyses; document configuration change decisions; implement approved configuration-controlled changes to the system; retain records of configuration-controlled changes to the system for organization-defined time period; monitor and review activities associated with configuration-controlled changes to the system; and coordinate and provide oversight for configuration change control activities through organization-defined configuration change control element. |
|
| 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 configuration settings for components employed in the system that reflect the most restrictive mode consistent with operational requirements using organization-defined common secure configurations; implement the configuration settings; identify, document, and approve any deviations from established configuration settings for organization-defined system components based on organization-defined operational requirements; and monitor and control changes to the configuration settings in accordance with organizational policies and procedures. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and prohibit or restrict organization-defined functions, system ports, protocols, software, 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.
| 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 and document the types of changes to the system that are configuration-controlled; review proposed configuration-controlled changes and approve or disapprove such changes with explicit consideration for security and privacy impact analyses; document configuration change decisions; implement approved configuration-controlled changes to the system; retain records of configuration-controlled changes to the system for organization-defined time period; monitor and review activities associated with configuration-controlled changes to the system; and coordinate and provide oversight for configuration change control activities through organization-defined configuration change control element. |
|
| 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 configuration settings for components employed in the system that reflect the most restrictive mode consistent with operational requirements using organization-defined common secure configurations; implement the configuration settings; identify, document, and approve any deviations from established configuration settings for organization-defined system components based on organization-defined operational requirements; and monitor and control changes to the configuration settings in accordance with organizational policies and procedures. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and prohibit or restrict organization-defined functions, system ports, protocols, software, 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
| 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
| 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
| 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
| 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.
| 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 in 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.
| 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.
| NIST 800-53 requirement | Description | Supported controls |
|---|---|---|
| AC-3(2): Dual Authorization | Enforce dual authorization for organization-defined privileged commands 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 and document the types of changes to the system that are configuration-controlled; review proposed configuration-controlled changes and approve or disapprove such changes with explicit consideration for security and privacy impact analyses; document configuration change decisions; implement approved configuration-controlled changes to the system; retain records of configuration-controlled changes to the system for organization-defined time period; monitor and review activities associated with configuration-controlled changes to the system; and coordinate and provide oversight for configuration change control activities through organization-defined configuration change control element. |
|
| 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 configuration settings for components employed in the system that reflect the most restrictive mode consistent with operational requirements using organization-defined common secure configurations; implement the configuration settings; identify, document, and approve any deviations from established configuration settings for organization-defined system components based on organization-defined operational requirements; and monitor and control changes to the configuration settings in accordance with organizational policies and procedures. |
|
| CM-7: Least Functionality | Configure the system to provide only organization-defined mission essential capabilities; and prohibit or restrict organization-defined functions, system ports, protocols, software, 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.
| 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. 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 and when new vulnerabilities affecting the system are identified. c) Update system vulnerabilities to be scanned 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.
| 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: The hardware, software (for example, firmware, operating systems, and applications), and services of physical and virtual platforms are managed consistent with the organization's risk strategy to protect their confidentiality, integrity, and availability. | 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.
| 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 (for example, 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: Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization. PW.7.2: Perform the code review and/or code analysis based on the organization's secure coding standards, and record and triage all discovered issues and recommended remediations in the development team's workflow or issue tracking 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. |
|
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.
| 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: Assesses Changes in Systems and Technology - The risk identification process considers changes arising from changes in the entity's systems and changes in the technology environment. POF 6: Assesses Changes in Threats and Vulnerabilities - The risk identification process assesses changes in (1) internal and external threats to and vulnerabilities of the components of the entity's systems and (2) the likelihood and magnitude of the resultant risks to the achievement of the entity's objectives. |
|
| 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 - The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events. | POF 1: Implements Detection Policies, Procedures, and Tools - Detection policies, procedures, and tools are defined and implemented on infrastructure and software to identify potential intrusions, inappropriate access, and anomalies in the operation of or unusual activity on systems. Procedures may include (1) a defined governance process for security event detection and management; (2) use of intelligence sources to identify newly discovered threats and vulnerabilities; and (3) logging of unusual system activities. |
|
| 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: Authorizes Changes - A process is in place to authorize system and architecture changes prior to design, development, or acquisition and configuration. POF 7: Tests System Changes - A process is in place to test internally developed and acquired system changes prior to implementation into the production environment. Examples of testing may include unit, integration, regression, static and dynamic application source code, quality assurance, or automated testing (whether point in time or continuous). POF 8: Approves System Changes - A process is in place to approve system changes prior to implementation. POF 16: Protects Confidential Information - The entity protects confidential information during system design, development, testing, implementation, and change processes to support the achievement of the entity's objectives related to confidentiality. |
|
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.
| TISAX requirement | Description | Supported controls |
|---|---|---|
| 1.2.2 To what extent are information security responsibilities organized? | A successful ISMS requires clear responsibilities in the organization. An appropriate organizational separation of responsibilities should be established 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 can 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) to prevent these changes from causing an uncontrolled reduction in the information security level. Information security requirements for changes to the organization, business processes, and IT systems are determined and applied. A formal approval procedure is established. |
|
| 5.2.5 To what extent are vulnerabilities identified and addressed? | Vulnerabilities increase the risk of IT systems being unable to meet the requirements for confidentiality, availability and integrity. Exploitation of vulnerabilities is among the possible ways for attackers to gain access to the IT system or to threaten its operating stability. Information on technical vulnerabilities for the IT systems in use is gathered (for example, information from the manufacturer, system audits, CVS database) and evaluated. For example, Common Vulnerability Scoring System (CVSS). Potentially affected IT systems and software are identified, assessed and any vulnerabilities are addressed. |
|
| 5.3.1 To what extent is information security considered in new or further developed IT systems? | Information security is an integral part of the entire lifecycle of IT systems. This particularly includes consideration of information security requirements in the development or acquisition of IT systems. The information security requirements associated with the design and development of IT systems are determined and considered. The information security requirements associated with the acquisition or extension of IT systems and IT components are determined and considered. Information security requirements associated with changes to developed IT systems are considered. System approval tests are carried out under consideration of the information security requirements. |
|
| 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. |
|