gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/source_code_1/code_risks_1_5/secure_pipeline_instructions.yml

@@ -0,0 +1,62 @@
+---
+id: 1.5.2
+name: secure_pipeline_instructions
+title: Detect and prevent misconfigurations and insecure instructions in CI pipelines
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Detect and prevent misconfigurations and insecure instructions in CI pipelines
+rationale: >-
+  Detecting and fixing misconfigurations or insecure instructions in CI pipelines decreases 
+  the risk for a successful attack through or on the CI pipeline. The more secure the 
+  pipeline, the less risk there is for potential exposure of sensitive data, a deployment 
+  being compromised, or external access mistakenly being granted to the CI infrastructure 
+  or the source code.
+impact: >-
+audit: |
+  For every project:
+    • Identify if one or more CI configuration files exist
+    • Review CI configuration files for misconfigurations or insecure instructions
+    • Review whether the absence of any CI configuration is itself a misconfiguration
+remediation: |
+  For every project identified during the Audit as having misconfigured or insecure CI instructions:
+    • Update the CI instructions
+    • Consider using Scan Execution Policies at the project or group level to enforce security scans
+    • Consider using the Compliance Framework feature to enforce pipeline configuration
+    • Consider procuring and enabling a CI instructions scanning tool to identify and
+    prevent misconfigurations and insecure instructions and scans all CI pipelines.
+default_value:
+references:
+cis_controls:
+  - id: 7.5
+    version: 8
+    name: Perform Automated Vulnerability Scans of Internal Enterprise Assets
+    description: >-
+      Perform automated vulnerability scans of internal enterprise assets on a 
+      quarterly, or more frequent, basis. Conduct both authenticated and 
+      unauthenticated scans, using a SCAP-compliant vulnerability scanning tool.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 7.6
+    version: 8
+    name: Perform Automated Vulnerability Scans of Externally-Exposed Enterprise Assets
+    description: >-
+      Perform automated vulnerability scans of externally-exposed enterprise assets 
+      using a SCAP-compliant vulnerability scanning tool. Perform scans on a monthly, 
+      or more frequent, basis.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 3.1
+    version: 7
+    name: Run Automated Vulnerability Scanning Tools
+    description: >-
+      Utilize an up-to-date SCAP-compliant vulnerability scanning tool to 
+      automatically scan all systems on the network on a weekly or more frequent basis 
+      to identify all potential vulnerabilities on the organization's systems.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/code_risks_1_5/vulnerability_scanning.yml

@@ -0,0 +1,48 @@
+---
+id: 1.5.4
+name: vulnerability_scanning
+title: Ensure scanners are in place for code vulnerabilities
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Detect and prevent known open source vulnerabilities in the code.
+rationale: >-
+  Open source code blocks are used a lot in developed software. This has its own 
+  advantages, but it also has risks. Because the code is open for everyone, it means that 
+  attackers can publish or add malicious code to these open-source code blocks, or use 
+  their knowledge to find vulnerabilities in an existing code. Detecting and fixing such 
+  code vulnerabilities, by SCA (Software Composition Analysis) prevents insecure flaws 
+  from reaching production. It gives another opportunity for developers to secure the 
+  source code before it is deployed in production, where it is far more exposed and 
+  vulnerable to attacks.
+impact: >-
+audit: |
+  For every repository that is in use, verify that a scanning tool is set to identify and prevent code vulnerabilities by performing the following:
+    1. On GitLab, navigate to the main page of the repository.
+    2. Review the CI pipeline configuration to verify that SAST has been configured to run on this project.
+remediation: |
+  For every repository that is in use, set a scanning tool to identify and prevent code vulnerabilities by performing the following:
+    1. On GitLab, navigate to the main page of the repository.
+    2. Configure SAST to run on this project.
+default_value:
+references:
+cis_controls:
+  - id: 16.12
+    version: 8
+    name: Implement Code-Level Security Checks
+    description: >-
+      Apply static and dynamic analysis tools within the application life cycle to verify 
+      that secure coding practices are being followed.
+    implementation_groups:
+      - IG3
+  - id: 18.7
+    version: 7
+    name: Apply Static and Dynamic Code Analysis Tools
+    description: >-
+      Apply static and dynamic analysis tools to verify that secure coding 
+      practices are being adhered to for internally developed software.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/domain_verification.yml

@@ -0,0 +1,65 @@
+---
+id: 1.3.9
+name: domain_verification
+title: Ensure an organization's identity is confirmed with a “Verified” badge
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Confirm the domains an organization owns with a "Verified" badge.
+rationale: >-
+  Verifying the organization's domain gives developers assurance that a given domain is 
+  truly the official home for a public organization. Attackers can pretend to be an 
+  organization and steal information via a faked/spoof domain, therefore the use of a 
+  "Verified" badge instills more confidence and trust between developers and the open-
+  source community.
+impact: >-
+audit: >-
+  On the left sidebar, select Search or go to and find your top-level group. 
+  Select Settings > Domain Verification. 
+  View your domains and if they are verified or unverified.
+remediation: |
+    Step 1:
+      • On the left sidebar, select Search or go to and find your top-level group.
+      • Select Settings > Domain Verification.
+      • In the upper-right corner, select Add Domain.
+      • In Domain, enter the domain name.
+      • In Project, link to a project.
+      • In Certificate:
+        • If you do not have or do not want to use an SSL certificate, leave Automatic certificate management using Let's Encrypt selected.
+        • Optional. Turn on the Manually enter certificate information toggle to add an SSL/TLS certificate. You can also add the certificate and key later.
+      • Select Add Domain.
+    Step 2:
+      • After you create a new domain, the verification code prompts you. Copy the values from GitLab and paste them in your domain's control panel as a TXT record.
+    Step 3:
+      After you have added all the DNS records:
+      • On the left sidebar, select Search or go to and find your group.
+      • Select Settings > Domain Verification.
+      • On the domain table row, Select Retry verification ().
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/enterprise_user/#verified-domains-for-groups
+cis_controls:
+  - id: 16.1
+    version: 8
+    name: Establish and Maintain a Secure Application Development Process
+    description: >-
+      Establish and maintain a secure application development process. In the 
+      process, address such items as: secure application design standards, secure coding 
+      practices, developer training, vulnerability management, security of third-party code, 
+      and application security testing procedures. Review and update documentation 
+      annually, or when significant enterprise changes occur that could impact this 
+      Safeguard.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 18.1
+    version: 7
+    name: Establish Secure Coding Practices
+    description: >-
+      Establish secure coding practices appropriate to the programming language and 
+      development environment being used.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/ensure_2_admins_per_repo.yml

@@ -0,0 +1,56 @@
+---
+id: 1.3.7
+name: ensure_2_admins_per_repo
+title: Ensure two administrators are set for each repository
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Ensure every repository has two users with administrative permissions.
+rationale: >-
+  Repository administrators have the highest permissions to said repository. These 
+  include the ability to add/remove collaborators, change branch protection policy, and 
+  convert to a publicly-accessible repository. Due to the liberal access granted to a 
+  repository administrator, it is highly recommended that only two contributors occupy this 
+  role.
+impact: >-
+  Removing administrative users from a repository would result in them losing high-level 
+  access to that repository.
+audit: |
+  For every group, verify there are two administrators by performing the following:
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Overview > Users.
+    • List users selecting the Admin tab.
+    • Verify that there are only 2 members with Admin permission.
+remediation: |
+  For every group in use, set two administrators by performing the following:
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Overview > Users.
+    • List users selecting the Admin tab.
+    • Find the team or person whose you'd like to revoke admin permissions. To edit a user, in the user's row, select Edit.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/admin_area.html#administering-users
+cis_controls:
+  - id: 3.3
+    version: 8
+    name: Configure Data Access Control Lists
+    description: >-
+      Configure data access control lists based on a user's need to know. Apply data
+      access control lists, also known as access permissions, to local and remote file
+      systems, databases, and applications.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 14.6
+    version: 7
+    name: Protect Information through Access Control Lists
+    description: >-
+      Protect all information stored on systems with file system, network share, 
+      claims, application, or database specific access control lists. These controls will 
+      enforce the principle that only authorized individuals should have access to the 
+      information based on their need to access the information as a part of their 
+      responsibilities.
+    implementation_groups:
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/limit_top_level_group_creation.yml

@@ -0,0 +1,61 @@
+---
+id: 1.3.2
+name: limit_top_level_group_creation
+title: Ensure top-level group creation is limited to specific members
+profile: 1
+category: source_code
+sub_category: contribution_access
+description: >-
+  Limit ability to create teams to trusted and specific users.
+rationale: >-
+  The ability to create new teams should be restricted to specific members in order to 
+  keep the organization orderly and ensure users have access to only the lowest privilege 
+  level necessary. Teams typically inherit permissions from their parent team, thus if base 
+  permissions are less restricted and any user has the ability to create a team, a 
+  permission leverage could occur in which certain data is made available to users who 
+  should not have access to it. Such a situation could potentially lead to the creation of 
+  shadow teams by an attacker. Restricting team creation will also reduce additional 
+  clutter in the organizational structure, and as a result will make it easier to track 
+  changes and anomalies.
+impact: >-
+  Only specific users will be able to create new teams.
+audit: |
+  For every organization, ensure that top-level group creation is limited to specific, trusted users by performing the following:
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Settings > General.
+    • Expand Account and limit.
+    • Verify that the Allow new users to create top-level groups checkbox is not checked.
+remediation: |
+  For every organization, limit top-level group creation to specific, trusted users by performing the following:
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Settings > General.
+    • Expand Account and limit.
+    • Clear the Allow new users to create top-level groups checkbox.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#prevent-new-users-from-creating-top-level-groups
+cis_controls:
+  - id: 5.4
+    version: 8
+    name: Restrict Administrator Privileges to Dedicated Administrator Accounts
+    description: >-
+      Restrict administrator privileges to dedicated administrator accounts on 
+      enterprise assets. Conduct general computing activities, such as internet 
+      browsing, email, and productivity suite use, from the user's primary, non-privileged 
+      account.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 4.3
+    version: 7
+    name: Ensure the Use of Dedicated Administrative Accounts
+    description: >-
+      Ensure that all users with administrative account access use a dedicated or 
+      secondary account for elevated activities. This account should only be used for 
+      administrative activities and not internet browsing, email, or similar activities.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/limit_user_registration_domain.yml

@@ -0,0 +1,58 @@
+---
+id: 1.3.6
+name: limit_user_registration_domain
+title: Ensure new members are required to be invited using company-approved email
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Existing members of an organization can invite new members to join, however new 
+  members must only be invited with their company-approved email.
+rationale: >-
+  Ensuring new members of an organization have company-approved email prevents 
+  existing members of the organization from inviting arbitrary new users to join. Without 
+  this verification, they can invite anyone who is using the organization's version control 
+  system or has an active email account, thus allowing outside users (and potential threat 
+  actors) to easily gain access to company private code and resources. This practice will 
+  subsequently reduce the chance of human error or typos when inviting a new member.
+impact: >-
+  Existing members would not be able to invite new users who do not have a company-
+  approved email address.
+audit: >-
+  For each group in use, verify for every invitation that the invited email address is 
+  company-approved by performing the following: 
+  On the left sidebar, select Search or go to and find your group. 
+  Select Manage > Members. 
+  Members that are not automatically added are displayed on the Invited tab. 
+  Verify that each invitation email is company approved by your company. 
+remediation: >-
+  For each group, allow only users with company-approved email to be invited. If a user 
+  was invited without company-approved email, perform the following: 
+  On the left sidebar, select Search or go to and find your group. 
+  Select Manage > Members. 
+  Members that are not automatically added are displayed on the Invited tab. 
+  Verify that each invitation email is company approved by your company. 
+  To cancel the user's invitation to join your organization, click Cancel invitation.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/group/#add-users-to-a-group
+cis_controls:
+  - id: 6.1
+    version: 8
+    name: Establish an Access Granting Process
+    description: >-
+      Establish and follow a process, preferably automated, for granting access to 
+      enterprise assets upon new hire, rights grant, or role change of a user.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 14.7
+    version: 7
+    name: Enforce Access Control to Data through Automated Tools
+    description: >-
+      Use an automated tool, such as host-based Data Loss Prevention, to 
+      enforce access controls to data even when data is copied off a system.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/minimum_number_of_admins.yml

@@ -0,0 +1,56 @@
+---
+id: 1.3.3
+name: minimum_number_of_admins
+title: Ensure minimum number of administrators are set for the organization
+profile: 1
+category: source_code
+sub_category: contribution_access
+description: >-
+  Ensure the organization has a minimum number of administrators.
+rationale: >-
+  Organization administrators have the highest level of permissions, including the ability 
+  to add/remove collaborators, create or delete repositories, change branch protection 
+  policy, and convert to a publicly-accessible repository. Due to the permissive access 
+  granted to an organization administrator, it is highly recommended to keep the number 
+  of administrator accounts as minimal as possible.
+impact: >-
+audit: |
+  Verify the minimum number of administrators in your project by performing the following:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • If there are minimum number of members with Owner/Maintainer role in the list, you are compliant.
+remediation: |
+  Set the minimum number of administrators in your project by performing the following:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • Next to the project member you want to remove, select Remove member.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/members/#filter-and-sort-project-members
+cis_controls:
+  - id: 5.4
+    version: 8
+    name: Restrict Administrator Privileges to Dedicated Administrator Accounts
+    description: >-
+      Restrict administrator privileges to dedicated administrator accounts on 
+      enterprise assets. Conduct general computing activities, such as internet 
+      browsing, email, and productivity suite use, from the user's primary, non-privileged 
+      account.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 4.3
+    version: 7
+    name: Ensure the Use of Dedicated Administrative Accounts
+    description: >-
+      Ensure that all users with administrative account access use a dedicated or
+      secondary account for elevated activities. This account should only be used for
+      administrative activities and not internet browsing, email, or similar activities.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/org_provided_ssh_certs.yml

@@ -0,0 +1,70 @@
+---
+id: 1.3.11
+name: org_provided_ssh_certs
+title: Ensure an organization provides SSH certificates
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  As an organization, become an SSH Certificate Authority and provide SSH keys for 
+  accessing repositories.
+rationale: >-
+  There are two ways for remotely working with Source Code Management: via HTTPS, 
+  which requires authentication by user/password, or via SSH, which requires the use of 
+  SSH keys. SSH authentication is better in terms of security; key creation and 
+  distribution, however, must be done in a secure manner. This can be accomplished by 
+  implementing SSH certificates, which are used to validate the server's identity. A 
+  developer will not be able to connect to a Git server if its key cannot be verified by the 
+  SSH Certificate Authority (CA) server. As an organization, one can verify the SSH 
+  certificate signature used to authenticate if a CA is defined and used. This ensures that 
+  only verified developers can access organization repositories, as their SSH key will be 
+  the only one signed by the CA certificate. This reduces the risk of misuse and malicious 
+  code commits.
+impact: >-
+  Members with unverified keys will not be able to clone organization repositories. 
+  Signing, certification, and verification might also slow down the development process.
+audit: |
+  GitLab allows you to restrict the allowed SSH key technology as well as specify the minimum key length for each technology:
+    1. On the left sidebar, at the bottom, select Admin Area.
+    2. Select Settings > General .
+    3. Expand Visibility and access controls
+    4. If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the requirement. Any existing keys that don't meet it are disabled but not removed and users cannot pull or push code using them.
+remediation: |
+  If you do not have an existing SSH key pair, generate a new one:
+    1. Open a terminal.
+    2. Run ssh-keygen -t followed by the key type and an optional comment. This comment is included in the .pub file that's created.
+    3. Press Enter.
+    4. Accept the suggested filename and directory, unless you are generating a deploy key or want to save in a specific directory where you store other keys.
+    5. Specify a passphrase
+    6. A confirmation is displayed, including information about where your files are stored. A public and private key are generated.
+    7. Add the public SSH key to your GitLab account and keep the private key secure.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/ssh.html#generate-an-ssh-key-pair
+  - https://docs.gitlab.com/ee/security/ssh_keys_restrictions.html
+cis_controls:
+  - id: 12.5
+    version: 8
+    name: Centralize Network Authentication, Authorization, and Auditing (AAA)
+    description: >-
+      Centralize network AAA.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 12.7
+    version: 8
+    name: Ensure Remote Devices Utilize a VPN and are Connecting to an Enterprise's AAA Infrastructure
+    description: >-
+      Require users to authenticate to enterprise-managed VPN and authentication 
+      services prior to accessing enterprise resources on end-user devices.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 1.8
+    version: 7
+    name: Utilize Client Certificates to Authenticate Hardware Assets
+    description: >-
+      Use client certificates to authenticate hardware assets connecting to the organization's trusted network.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/readme.md

@@ -0,0 +1,21 @@
+# 1.3 Contribution Access
+
+This section consists of security recommendations for managing access to the application code. This includes managing both internal and external access, administrator accounts, permissions, identification methods, etc. Securing these items is important for software safety because every security constraint on access is an obstacle in the way of attacks.
+
+This section differentiates between the common user account and an admin account. It is important to understand that due to the high permissions of the admin account, it should be used only for administrative work and not for everyday tasks.
+
+## Recommendations
+
+* [1.3.1 - review_and_remove_inactive_users.yml](./review_and_remove_inactive_users.yml)
+* [1.3.2 - limit_top_level_group_creation.yml](./limit_top_level_group_creation.yml)
+* [1.3.3 - minimum_number_of_admins.yml](./minimum_number_of_admins.yml)
+* [1.3.4 - require_mfa_for_contributors.yml](./require_mfa_for_contributors.yml)
+* [1.3.5 - require_mfa_at_org_level.yml](./require_mfa_at_org_level.yml)
+* [1.3.6 - limit_user_registration_domain.yml](./limit_user_registration_domain.yml)
+* [1.3.7 - ensure_2_admins_per_repo.yml](./ensure_2_admins_per_repo.yml)
+* [1.3.8 - strict_permissions_for_repo.yml](./strict_permissions_for_repo.yml)
+* [1.3.9 - domain_verification.yml](./domain_verification.yml)
+* [1.3.10 - scm_notification_restriction.yml](./scm_notification_restriction.yml)
+* [1.3.11 - org_provided_ssh_certs.yml](./org_provided_ssh_certs.yml)
+* [1.3.12 - restrict_ip_addresses.yml](./restrict_ip_addresses.yml)
+* [1.3.13 - track_code_anomalies.yml](./track_code_anomalies.yml)

gitlabcis/recommendations/source_code_1/contribution_access_1_3/require_mfa_at_org_level.yml

@@ -0,0 +1,89 @@
+---
+id: 1.3.5
+name: require_mfa_at_org_level
+title: Ensure the organization is requiring members to use Multi-Factor Authentication (MFA)
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Require members of the organization to use Multi-Factor Authentication (MFA) in 
+  addition to a standard user name and password when authenticating to the source code 
+  management platform.
+rationale: >-
+  By default every user authenticates within the system by password only. If the password 
+  of a user is compromised, however, the user account and every repository to which they 
+  have access are in danger of data loss, malicious code commits, and data theft. It is 
+  therefore recommended that each user has Multi-Factor Authentication enabled. This 
+  adds an additional layer of protection to ensure the account remains secure even if the 
+  user's password is compromised.
+impact: >-
+  Members will be removed from the organization if they don't have Multi-Factor 
+  Authentication already enabled. If this is the case, it is recommended that an invitation 
+  be sent to reinstate the user's access and former privileges. They must enable Multi-
+  Factor Authentication to accept the invitation.
+audit: |
+  For every organization that exists in your GitLab platform, verify that Two-Factor Authentication is enforced and is the only way to authenticate. Administrators can enforce 2FA for all users in two different ways:
+  • Enforce on next sign in.
+  • Suggest on next sign in, but allow a grace period before enforcing.
+
+  Use the UI:
+    1. On the left sidebar, select Search or go to.
+    2. Select Admin Area.
+    3. On the left sidebar, select Settings > General.
+    4. Expand the Sign-in restrictions section:
+    5. Verify that Enforce two-factor authentication is enabled.
+remediation: |
+  Use the UI:
+    1. On the left sidebar, select Search or go to.
+    2. Select Admin Area.
+    3. On the left sidebar, select Settings > General.
+    4. Expand the Sign-in restrictions section:
+      • Select Enforce two-factor authentication to enable this feature.
+      • In Two-factor grace period, enter a number of hours. If you want to enforce 2FA on next sign-in attempt, enter 0.
+
+  Use the API:
+  Use the application settings API to modify the following settings:
+    • require_two_factor_authentication, set to TRUE.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/security/two_factor_authentication.html
+cis_controls:
+  - id: 6.3
+    version: 8
+    name: Require MFA for Externally-Exposed Applications
+    description: >-
+      Require all externally-exposed enterprise or third-party applications to enforce 
+      MFA, where supported. Enforcing MFA through a directory service or SSO 
+      provider is a satisfactory implementation of this Safeguard.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 6.4
+    version: 8
+    name: Require MFA for Remote Network Access
+    description: >-
+      Require MFA for remote network access
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 6.5
+    version: 8
+    name: Require MFA for Administrative Access
+    description: >-
+      Require MFA for all administrative access accounts, where supported, on all 
+      enterprise assets, whether managed on-site or through a third-party provider.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 16.3
+    version: 7
+    name: Require Multi-factor Authentication
+    description: >-
+      Require multi-factor authentication for all user accounts, on all systems, 
+      whether managed onsite or by a third-party provider.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/require_mfa_for_contributors.yml

@@ -0,0 +1,76 @@
+---
+id: 1.3.4
+name: require_mfa_for_contributors
+title: Ensure Multi-Factor Authentication (MFA) is required for contributors of new code
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Require collaborators from outside the organization to use Multi-Factor Authentication 
+  (MFA) in addition to a standard user name and password when authenticating to the 
+  source code management platform.
+rationale: >-
+  By default every user authenticates within the system by password only. If the password 
+  of a user is compromised, however, the user account and every repository to which they 
+  have access are in danger of data loss, malicious code commits, and data theft. It is 
+  therefore recommended that each user has Multi-Factor Authentication enabled. This 
+  adds an additional layer of protection to ensure the account remains secure even if the 
+  user's password is compromised.
+impact: >-
+  A member without enabled Multi-Factor Authentication cannot contribute to the project. 
+  They must enable Multi-Factor Authentication a before they can contribute any code.
+audit: |
+  For your top-level group, verify that Multi-Factor Authentication is enforced for contributors and is the only way to authenticate, by doing the following:
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Settings > General.
+    • Expand Sign-in restrictions:
+    • Check if Enforce two-factor authentication is enabled. If so, you are compliant.
+remediation: |
+  For your top-level group, enforce that Multi-Factor Authentication is enforced for contributors and is the only way to authenticate, by doing the following:
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Settings > General.
+    • Expand Sign-in restrictions:
+    • Select Enforce two-factor authentication to enable this feature.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/security/two_factor_authentication.html
+cis_controls:
+  - id: 6.3
+    version: 8
+    name: Require MFA for Externally-Exposed Applications
+    description: >-
+      Require all externally-exposed enterprise or third-party applications to enforce 
+      MFA, where supported. Enforcing MFA through a directory service or SSO 
+      provider is a satisfactory implementation of this Safeguard.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 6.4
+    version: 8
+    name: Require MFA for Remote Network Access
+    description: >-
+      Require MFA for remote network access
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 6.5
+    version: 8
+    name: Require MFA for Administrative Access
+    description: >-
+      Require MFA for all administrative access accounts, where supported, on all 
+      enterprise assets, whether managed on-site or through a third-party provider.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 16.3
+    version: 7
+    name: Require Multi-factor Authentication
+    description: >-
+      Require multi-factor authentication for all user accounts, on all systems, 
+      whether managed onsite or by a third-party provider.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-