gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/source_code_1/contribution_access_1_3/restrict_ip_addresses.yml

@@ -0,0 +1,84 @@
+---
+id: 1.3.12
+name: restrict_ip_addresses
+title: Ensure Git access is limited based on IP addresses
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Limit Git access based on IP addresses by having a allowlist of IP addresses from which connection is possible.
+rationale: >-
+  Allowing access to Git repositories (source code) only from specific IP addresses adds 
+  yet another layer of restriction and reduces the risk of unauthorized connection to the 
+  organization's assets. This will prevent attackers from accessing Source Code 
+  Management (SCM), as they would first need to know the allowed IP addresses to gain 
+  access to them.
+impact: >-
+  Only members with allowlisted IP addresses will be able to access the organization's Git 
+  repositories.
+audit: |
+  To ensure only people from your organization can access particular resources, you can restrict access to groups by IP address. This top-level group setting applies to:
+  The GitLab UI, including subgroups, projects, and issues. It does not apply to GitLab Pages.
+
+  In GitLab 12.3 and later, the API.
+  
+  In self-managed installations of GitLab 15.1 and later, you can also configure globally-allowed IP address ranges at the group level.
+  To determine whether IP restrictions are in place:
+    • On the left sidebar, select Search or go to and find your group.
+    • Select Settings > General.
+    • Expand the Permissions and group features section.
+    • In the Restrict access by IP address text box, view the list of IP addresses.
+remediation: |
+  To restrict group access by IP address:
+    1. On the left sidebar, select Search or go to and find your group.
+    2. Select Settings > General.
+    3. Expand the Permissions and group features section.
+    4. In the Restrict access by IP address text box, enter a list of IPv4 or IPv6 address ranges in CIDR notation. This list:
+      • Has no limit on the number of IP address ranges.
+      • Has a size limit of 1 GB.
+      • Applies to both SSH or HTTP authorized IP address ranges. You cannot split this list by type of authorization.
+    5. Select Save changes.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-ip-address
+cis_controls:
+  - id: 2.5
+    version: 8
+    name: Allowlist Authorized Software
+    description: >-
+      Use technical controls, such as application allowlisting, to ensure that only 
+      authorized software can execute or be accessed. Reassess bi-annually, or more 
+      frequently.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.6
+    version: 8
+    name: Allowlist Authorized Libraries
+    description: >-
+      Use technical controls to ensure that only authorized software libraries, such 
+      as specific .dll, .ocx, .so, etc., files, are allowed to load into a system process. 
+      Block unauthorized libraries from loading into a system process. Reassess bi-
+      annually, or more frequently.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.7
+    version: 7
+    name: Utilize Application Whitelisting
+    description: >-
+      Utilize application whitelisting technology on all assets to ensure that only 
+      authorized software executes and all unauthorized software is blocked from 
+      executing on assets.
+    implementation_groups:
+      - IG3
+  - id: 2.8
+    version: 7
+    name: Implement Application Whitelisting of Libraries
+    description: >-
+      The organization's application whitelisting software must ensure that only 
+      authorized software libraries (such as *.dll, *.ocx, *.so, etc) are allowed to load into 
+      a system process.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/review_and_remove_inactive_users.yml

@@ -0,0 +1,62 @@
+---
+id: 1.3.1
+name: review_and_remove_inactive_users
+title: Ensure inactive users are reviewed and removed periodically
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Track inactive user accounts and periodically remove them.
+rationale: >-
+  User accounts that have been inactive for a long period of time are enlarging the 
+  surface of attack. Inactive users with high-level privileges are of particular concern, as 
+  these accounts are more likely to be targets for attackers. This could potentially allow 
+  access to large portions of an organization should such an attack prove successful. It is 
+  recommended to remove them as soon as possible in order to prevent this.
+impact: >-
+audit: |
+  As an Administrator:
+    • Navigate to the Admin Area
+    • In the sidebar, select Users
+    • Select the 'Deactivated' filter tab
+    • Identify if any users are present
+    • Select the 'Active' filter tab
+    • Sort by 'Oldest updated'
+    • Use the 'Last activity' column to determine which users are inactive
+remediation: |
+  As an Administrator:
+    • Navigate to the Admin Area
+    • In the sidebar, select Users
+    • Next to each inactive user, select the vertical ellipsis
+    • Select either 'Block' (recommended), 'Delete user', or 'Delete user and contributions'
+
+  Perform the following steps as an Administrator to automatically deactivate dormant users:
+    • Navigate to the Admin Area
+    • Select Settings > General.
+    • Expand the Account and limit section.
+    • Under Dormant users, check Deactivate dormant users after a period of inactivity.
+    • Under Days of inactivity before deactivation, enter the number of days before deactivation. Minimum value is 90 days.
+    • Select Save changes.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/moderate_users.html
+cis_controls:
+  - id: 5.3
+    version: 8
+    name: Disable Dormant Accounts
+    description: >-
+      Delete or disable any dormant accounts after a period of 45 days of inactivity, where supported.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 16.9
+    version: 7
+    name: Disable Dormant Accounts
+    description: >-
+      Automatically disable dormant accounts after a set period of inactivity
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/scm_notification_restriction.yml

@@ -0,0 +1,46 @@
+---
+id: 1.3.10
+name: scm_notification_restriction
+title: Ensure Source Code Management (SCM) email notifications are restricted to verified domains
+profile: 2
+category: source_code
+sub_category: contribution_access
+description: >-
+  Restrict the Source Code Management (SCM) organization's email notifications to approved domains only.
+rationale: >-
+  Restricting Source Code Management email notifications to verified domains only 
+  prevents data leaks, as personal emails and custom domains are more prone to 
+  account takeover via DNS hijacking or password breach.
+impact: >-
+  Only members with approved email would be able to receive Source Code Management 
+  notifications.
+audit: |
+  Ensure Source Code Management email notifications are restricted to approved domains only by performing the following:
+    • On the left sidebar, select Search or go to and find your top-level group.
+    • Select Settings > Domain Verification.
+    • When viewing Domain Verification, select the project listed next to the relevant domain.
+    • Check if access is limited to the relevant domains.
+remediation: |
+  Restrict Source Code Management email notifications to approved domains only by performing the following:
+    • On the left sidebar, select Search or go to and find your top-level group.
+    • Select Settings > Domain Verification.
+    • When viewing Domain Verification, select the project listed next to the relevant domain.
+    • Ensure access is limited to the relevant domains.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/enterprise_user/#verified-domains-for-groups
+  - https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-domain
+cis_controls:
+  - id: 0.0
+    version: 8
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+  - id: 0.0
+    version: 7
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/strict_permissions_for_repo.yml

@@ -0,0 +1,62 @@
+---
+id: 1.3.8
+name: strict_permissions_for_repo
+title: Ensure strict base permissions are set for repositories
+profile: 1
+category: source_code
+sub_category: contribution_access
+description: >-
+  Base permissions define the permission level automatically granted to all organization 
+  members. Define strict base access permissions for all of the repositories in the 
+  organization, including new ones.
+rationale: >-
+  Defining strict base permissions is the best practice in every role-based access control 
+  (RBAC) system. If the base permission is high — for example, "write" permission — 
+  every member of the organization will have "write" permission to every repository in the 
+  organization. This will apply regardless of the specific permissions a user might need, 
+  which generally differ between organization repositories. The higher the permission, the 
+  higher the risk for incidents such as bad code commit or data breach. It is therefore 
+  recommended to set the base permissions to the strictest level possible.
+impact: >-
+  Users might not be able to access organization repositories or perform some acts as 
+  commits. These specific permissions should be granted individually for each user or 
+  team, as needed.
+audit: |
+  Verify that strict base permissions are set for the organization groups by doing 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.
+
+    In GitLab, you set the specific role for each new user in your group. Check the roles of your users to determine if it matches the least-privilege principle.
+remediation: |
+  Set strict base permissions for the organization groups with the next steps:
+    • 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.
+    In GitLab, you set the specific role for each new user in your group. Ensure the roles for your users match the least-privilege principle.
+default_value: Read permission
+references:
+cis_controls:
+  - id: 16.7
+    version: 8
+    name: Use Standard Hardening Configuration Templates for Application Infrastructure
+    description: >-
+      Use standard, industry-recommended hardening configuration templates for 
+      application infrastructure components. This includes underlying servers, databases, 
+      and web servers, and applies to cloud containers, Platform as a Service (PaaS) 
+      components, and SaaS components. Do not allow in-house developed software to 
+      weaken configuration hardening.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 18.11
+    version: 7
+    name: Use Standard Hardening Configuration Templates for Databases
+    description: >-
+      For applications that rely on a database, use standard hardening configuration
+      templates. All systems that are part of critical business processes should also be
+      tested.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/contribution_access_1_3/track_code_anomalies.yml

@@ -0,0 +1,43 @@
+---
+id: 1.3.13
+name: track_code_anomalies
+title: Ensure anomalous code behavior is tracked
+profile: 1
+category: source_code
+sub_category: contribution_access
+description: >-
+  Track code anomalies.
+rationale: >-
+  Carefully analyze any code anomalies within the organization. For example, a code 
+  anomaly could be a push made outside of working hours. Such a code push has a 
+  higher likelihood of being the result of an attack, as most if not all members of the 
+  organization would likely be outside the office. Another example is an activity that 
+  exceeds the average activity of a particular user. Tracking and auditing such behaviors 
+  creates additional layers of security and can aid in early detection of potential attacks.
+impact: >-
+audit: >-
+  For every project in use, ensure code anomalies relevant to the organization are 
+  promptly investigated.
+remediation: >-
+  For every project in use, track and investigate anomalous code behavior and activity.
+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/readme.md

@@ -0,0 +1,13 @@
+# 1 Source Code
+
+This section consists of security recommendations for proper source code management of any application developed by the organization. This is the first phase of the software supply chain, and is considered the single source of truth for the rest of the process.
+
+It is critical to secure both the source code itself, as well as the platform with which it is managed, in order to protect the integrity of a software release. From the developers who commit changes, to the sensitive data or vulnerabilities that could be placed within it, and ultimately to the source code management platform in which it is stored, verification of the integrity of the source code is imperative in order to keep every software update secure.
+
+## Sections
+
+- [1.1 - Code Changes](./code_changes_1_1)
+- [1.2 - Repository Management](./repository_management_1_2)
+- [1.3 - Contribution Access](./contribution_access_1_3)
+- [1.4 - Third Party](./third_party_1_4)
+- [1.5 - Code Risks](./code_risks_1_5)

gitlabcis/recommendations/source_code_1/repository_management_1_2/limit_issue_deletions.yml

@@ -0,0 +1,57 @@
+---
+id: 1.2.4
+name: limit_issue_deletions
+title: Ensure issue deletion is limited to specific users
+profile: 1
+category: source_code
+sub_category: repository_management
+description: >-
+  Ensure only trusted and responsible users can delete issues.
+rationale: >-
+  Issues are a way to keep track of things happening in repositories, such as setting new 
+  milestones or requesting urgent fixes. Deleting an issue is not a benign activity, as it 
+  might harm the development workflow or attempt to hide malicious behavior. Because 
+  of this, it should be restricted and allowed only by trusted and responsible users.
+impact: >-
+  Certain users will not be permitted to delete issues.
+audit: |
+  Verify that only a limited number of trusted users can delete issues by performing either of the following steps:
+    • 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: |
+  Enforce issue deletion by a few trusted and responsible users only by performing either of the following steps:
+    • 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: Only organization owners or members with admin privileges can delete issues.
+references:
+  - https://docs.gitlab.com/ee/user/permissions.html#project-features-permissions
+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:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/repository_management_1_2/limit_repo_creations.yml

@@ -0,0 +1,64 @@
+---
+id: 1.2.2
+name: limit_repo_creations
+title: Ensure repository creation is limited to specific members
+profile: 1
+category: source_code
+sub_category: repository_management
+description: >-
+  Limit the ability to create repositories to trusted users and teams.
+rationale: >-
+  Restricting repository creation to trusted users and teams is recommended in order to 
+  keep the organization properly structured, track fewer items, prevent impersonation, and 
+  to not overload the version-control system. It will allow administrators easier source 
+  code tracking and management capabilities, as they will have fewer repositories to 
+  track. The process of detecting potential attacks also becomes far more straightforward, 
+  as well, since the easier it is to track the source code, the easier it is to detect malicious 
+  acts within it. Additionally, the possibility of a member creating a public repository and 
+  sharing the organization's data externally is significantly decreased.
+impact: >-
+  Specific users will not be permitted to create repositories.
+audit: |
+  Verify that only trusted users and teams can create repositories by performing the following. As an administrator:
+    • Navigate to the Admin Area
+    • In the sidebar, select Settings > General
+    • Expand the Sign-up restrictions section
+    • If 'Sign up enabled' is disabled, the instance is compliant.
+    • If 'Sign-up enabled' and 'Require admin approval for new sign-ups' are selected, and if 'Email confirmation settings' is set to Hard, the instance is compliant.
+remediation: |
+  Ensure that only trusted users and teams can create repositories by performing the following. As an administrator:
+    • Navigate to the Admin Area
+    • In the sidebar, select Settings > General
+    • Expand the Sign-up restrictions section
+    • (Option 1) Deselect 'Sign-up enabled', OR
+    • (Option 2) Select 'Sign-up enabled', select 'Require admin approval for new sign-ups' are selected, and under 'Email confirmation settings' select 'Hard'
+    • Select 'Save changes'
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html
+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:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/repository_management_1_2/limit_repo_deletions.yml

@@ -0,0 +1,57 @@
+---
+id: 1.2.3
+name: limit_repo_deletions
+title: Ensure repository deletion is limited to specific users
+profile: 1
+category: source_code
+sub_category: repository_management
+description: >-
+  Ensure only a limited number of trusted users can delete repositories.
+rationale: >-
+  Restricting the ability to delete repositories protects the organization from intentional 
+  and unintentional data loss. This ensures that users cannot delete repositories or cause 
+  other potential damage — whether by accident or due to their account being hacked — 
+  unless they have the correct privileges.
+impact: >-
+  Certain users will not be permitted to delete repositories.
+audit: |
+  Verify that only a limited number of trusted users can delete repositories by performing either of the following steps:
+    • 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: |
+  Enforce repository deletion by a few trusted and responsible users only by performing either of the following steps:
+    • 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: Only organization owners or members with admin privileges can delete repositories.
+references:
+  - https://docs.gitlab.com/ee/user/permissions.html
+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:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/repository_management_1_2/public_repos_have_security_file.yml

@@ -0,0 +1,59 @@
+---
+id: 1.2.1
+name: public_repos_have_security_file
+title: Ensure all public repositories contain a SECURITY.md file
+profile: 1
+category: source_code
+sub_category: repository_management
+description: >-
+  A SECURITY.md file is a security policy file that offers instruction on reporting security 
+  vulnerabilities in a project. When someone creates an issue within a specific project, a 
+  link to the SECURITY.md file will subsequently be shown.
+rationale: >-
+  A SECURITY.md file provides users with crucial security information. It can also serve 
+  an important role in project maintenance, encouraging users to think ahead about how 
+  to properly handle potential security issues, updates, and general security practices.
+impact: >-
+audit: |
+  Verify that each public repository has a SECURITY.md file by performing the following:
+    • Navigate to the main page of a GitLab repository.
+    • Verify that the repository has a SECURITY.md file with crucial security information at the top-level.
+remediation: |
+  Ensure that each public repository has a SECURITY.md file by performing the following:
+    • Navigate to the main page of a repository without a SECURITY.md file in GitLab.
+    • Create a SECURITY.md file (in the web UI or locally) with security information like supported versions of your project and how to report a vulnerability.
+    • Commit this file to the repository and push your changes.
+    • If you open a merge request to add the SECURITY.md file, make sure this change is merged to your repository's default branch.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/api/projects.html
+  - https://docs.gitlab.com/ee/api/repository_files.html
+cis_controls:
+  - id: 16.2
+    version: 8
+    name: Establish and Maintain a Process to Accept and Address Software Vulnerabilities
+    description: >-
+      Establish and maintain a process to accept and address reports of software 
+      vulnerabilities, including providing a means for external entities to report. The 
+      process is to include such items as: a vulnerability handling policy that identifies 
+      reporting process, responsible party for handling vulnerability reports, and a process 
+      for intake, assignment, remediation, and remediation testing. As part of the process, 
+      use a vulnerability tracking system that includes severity ratings, and metrics for 
+      measuring timing for identification, analysis, and remediation of 
+      vulnerabilities. Review and update documentation annually, or when significant 
+      enterprise changes occur that could impact this Safeguard. Third-party application 
+      developers need to consider this an externally-facing policy that helps to set 
+      expectations for outside stakeholders.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 18.8
+    version: 7
+    name: Establish a Process to Accept and Address Reports of Software Vulnerabilities
+    description: >-
+      Establish a process to accept and address reports of software vulnerabilities, 
+      including providing a means for external entities to contact your security group.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/repository_management_1_2/readme.md

@@ -0,0 +1,15 @@
+# 1.2 Repository Management
+
+This section consists of security recommendations for proper code repository management.
+
+Code repositories are where the application code is stored and organized. It is important to keep code repositories organized and maintained to avoid data loss, data theft and other attacks that may happen unknowingly when a repository is not maintained well. The recommendations of this section are setting guides to do so.
+
+## Recommendations
+
+* [1.2.1 - public_repos_have_security_file.yml](./public_repos_have_security_file.yml)
+* [1.2.2 - limit_repo_creations.yml](./limit_repo_creations.yml)
+* [1.2.3 - limit_repo_deletions.yml](./limit_repo_deletions.yml)
+* [1.2.4 - limit_issue_deletions.yml](./limit_issue_deletions.yml)
+* [1.2.5 - track_forks.yml](./track_forks.yml)
+* [1.2.6 - track_project_visibility_status.yml](./track_project_visibility_status.yml)
+* [1.2.7 - review_and_archive_stale_repos.yml](./review_and_archive_stale_repos.yml)

gitlabcis/recommendations/source_code_1/repository_management_1_2/review_and_archive_stale_repos.yml

@@ -0,0 +1,65 @@
+---
+id: 1.2.7
+name: review_and_archive_stale_repos
+title: Ensure inactive repositories are reviewed and archived periodically
+profile: 1
+category: source_code
+sub_category: repository_management
+description: >-
+  Track inactive repositories and remove them periodically.
+rationale: >-
+  Inactive repositories (i.e., no new changes introduced for a long period of time) can 
+  enlarge the surface of a potential attack or data leak. These repositories are more likely 
+  to be improperly managed, and thus could possibly be accessed by a large number of 
+  users in an organization.
+impact: >-
+  Bug fixes and deployment of necessary changes could prove complicated for archived repositories.
+audit: |
+  Perform the following to ensure that all the projects in the organization are active. For each group:
+    • Navigate to the group homepage.
+    • Expand any sub-groups.
+    • For each project, review the updated date and ensure it has been updated within the last 6 months.
+remediation: |
+  Perform the following to remediate the presence of inactive projects. For each inactive project identified during the audit:
+    • Navigate to the project homepage.
+    • In the sidebar, select Settings > General.
+    • In the 'Advanced' section, select 'Expand'.
+    • Select 'Archive project'.
+    • Read the warning.
+    • Select 'Archive project'.
+  
+    To automate the deletion of inactive projects, perform the following steps as an Administrator:
+      • On the left sidebar, at the bottom, select Admin Area.
+      • Select Settings > Repository.
+      • Expand Repository maintenance.
+      • In the Inactive project deletion section, select Delete inactive projects.
+      • Configure the settings.
+        • The warning email is sent to users who have the Owner and Maintainer role for the inactive project.
+        • The email duration must be less than the Delete project after duration.
+      • Select Save changes.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/inactive_project_deletion.html
+cis_controls:
+  - id: 4.8
+    version: 8
+    name: Uninstall or Disable Unnecessary Services on Enterprise Assets and Software
+    description: >-
+      Uninstall or disable unnecessary services on enterprise assets and software, 
+      such as an unused file sharing service, web application module, or service function.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 13.2
+    version: 8
+    name: Remove Sensitive Data or Systems Not Regularly Accessed by Organization
+    description: >-
+      Remove sensitive data or systems not regularly accessed by the organization 
+      from the network. These systems shall only be used as stand alone systems 
+      (disconnected from the network) by the business unit needing to occasionally use 
+      the system or completely virtualized and powered off until needed.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-