gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/build_pipelines_2/build_environment_2_1/secure_build_env_webhooks.yml

@@ -0,0 +1,43 @@
+---
+id: 2.1.10
+name: secure_build_env_webhooks
+title: Ensure webhooks of the build environment are secured
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Use secured webhooks of the build environment.
+rationale: >-
+  Webhooks are used for triggering an HTTP request based on an action made in the 
+  platform. Typically, build environment feature webhooks for a pipeline trigger based on 
+  source code event. Since webhooks are an HTTP POST request, they can be 
+  malformed if not secured over SSL. To prevent a potential hack and compromise of the 
+  webhook or to the environment or web server excepting the request, use only secured 
+  webhooks.
+impact: >-
+audit: |
+  For each webhook in use, ensure it is secured (HTTPS) via the following process: 
+    • In your project or group, on the left sidebar, select Settings > Webhooks.
+    • For each webhook, click Edit.
+    • Verify if the Enable SSL verification checkbox is checked.
+    • Select Add webhook.
+remediation: |
+  For each webhook in use, change it to secured (over HTTPS).
+    • In your project or group, on the left sidebar, select Settings > Webhooks.
+    • For each webhook, click Edit.
+    • Ensure the Enable SSL verification checkbox is checked.
+    • Select Save.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#configure-a-webhook-in-gitlab
+cis_controls:
+  - id: 12.6
+    version: 8
+    name: Use of Secure Network Management and Communication Protocols
+    description: >-
+      Use secure network management and communication protocols (e.g., 
+      802.1X, Wi-Fi Protected Access 2 (WPA2) Enterprise or greater).
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_environment_2_1/single_responsibility_pipeline.yml

@@ -0,0 +1,58 @@
+---
+id: 2.1.1
+name: single_responsibility_pipeline
+title: Ensure each pipeline has a single responsibility
+profile: 2
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Ensure each pipeline has a single responsibility in the build process.
+rationale: >-
+  Build pipelines generally have access to multiple secrets depending on their purposes. 
+  There are, for example, secrets of the test environment for the test phase, repository 
+  and artifact credentials for the build phase, etc. Limiting access to these 
+  credentials/secrets is therefore recommended by dividing pipeline responsibilities, as 
+  well as having a dedicated pipeline for each phase with the lowest privilege instead of a 
+  single pipeline for all. This will ensure that any potential damage caused by attacks on a 
+  workflow will be limited.
+impact: >-
+audit: >-
+  For each pipeline, ensure it has only one responsibility in the build process.
+remediation: >-
+  Divide each multi-responsibility pipeline into multiple pipelines, each having a single 
+  responsibility with the least privilege. Additionally, create all new pipelines with a sole 
+  purpose going forward.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/permissions.html#job-permissions
+cis_controls:
+  - id: 4.6
+    version: 8
+    name: Securely Manage Enterprise Assets and Software
+    description: >-
+      Securely manage enterprise assets and software. Example implementations 
+      include managing configuration through version-controlled-infrastructure-as-code 
+      and accessing administrative interfaces over secure network protocols, such as 
+      Secure Shell (SSH) and Hypertext Transfer Protocol Secure (HTTPS). Do not use 
+      insecure management protocols, such as Telnet (Teletype Network) and HTTP, 
+      unless operationally essential.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 16.10
+    version: 8
+    name: Apply Secure Design Principles in Application Architectures
+    description: >-
+      Apply secure design principles in application architectures. Secure design 
+      principles include the concept of least privilege and enforcing mediation to validate 
+      every operation that the user makes, promoting the concept of "never trust user 
+      input." Examples include ensuring that explicit error checking is performed and 
+      documented for all input, including for size, data type, and acceptable ranges or 
+      formats. Secure design also means minimizing the application infrastructure attack 
+      surface, such as turning off unprotected ports and services, removing unnecessary 
+      programs and files, and renaming or removing default accounts.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_environment_2_1/vuln_scanning.yml

@@ -0,0 +1,64 @@
+---
+id: 2.1.8
+name: vuln_scanning
+title: Ensure the build infrastructure is automatically scanned for vulnerabilities
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Scan the build infrastructure and its dependencies for vulnerabilities. It is recommended that this be done automatically.
+rationale: >-
+  Automatic scanning for vulnerabilities detects known vulnerabilities in the tooling used 
+  by the build infrastructure and its dependencies. These vulnerabilities can lead to a 
+  potentially massive breach if not handled as fast as possible, as attackers might also be 
+  aware of such vulnerabilities.
+impact: >-
+audit: >-
+  Verify that your build infrastructure is reviewed for vulnerabilities. 
+  GitLab Runner is designed to run user-controlled scripts. To reduce the attack surface if 
+  a job is malicious, you can consider running them in their own network segment. This 
+  would provide network separation from other infrastructure and services.
+remediation: |
+  Ensure security hardening for your build infrastructure.
+  For a cloud environment, this could include:
+    • Configuring runner virtual machines in their own network segment
+    • Blocking SSH access from the Internet to runner virtual machines
+    • Restricting traffic between runner virtual machines
+    • Filtering access to cloud provider metadata endpoints
+  For static host runner, whether bare-metal or virtual machine, you should implement security best practices for the host operating system:
+  Malicious code executed in the context of a CI job could compromise the host, so security protocols can help mitigate the impact. Other points to keep in mind include securing or removing files such as SSH keys from the host system that may enable an attacker to access other endpoints in the environment.
+default_value:
+references:
+  - https://docs.gitlab.com/runner/security/
+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/build_pipelines_2/build_worker_2_2/build_worker_vuln_scanning.yml

@@ -0,0 +1,58 @@
+---
+id: 2.2.6
+name: build_worker_vuln_scanning
+title: Ensure build workers are automatically scanned for vulnerabilities
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  Scan build workers for vulnerabilities. It is recommended that this be done 
+  automatically.
+rationale: >-
+  Automatic scanning for vulnerabilities detects known weaknesses in environmental 
+  sources in use, such as docker images or kernel versions. Such vulnerabilities can lead 
+  to a massive breach if these environments are not replaced as fast as possible, since 
+  attackers also know about these vulnerabilities and often try to take advantage of them. 
+  Setting automatic scanning which scans environmental sources ensures that if any new 
+  vulnerability is revealed, it can be replaced quickly and easily. This protects the worker 
+  from being exposed to attacks.
+impact: >-
+audit: >-
+  If you are using a static host for a runner, whether bare-metal or virtual machine, you 
+  should implement security best practices for the host operating system. 
+  Malicious code executed in the context of a CI job could compromise the host, so 
+  security protocols can help mitigate the impact. Other points to keep in mind include 
+  securing or removing files such as SSH keys from the host system that may enable an 
+  attacker to access other endpoints in the environment.
+remediation: |
+  For each build worker, automatically scan its environmental sources, such as docker image, for vulnerabilities.
+    • Create a new project.
+    • Add a Dockerfile file to the project. This Dockerfile contains minimal configuration required to create a Docker image.
+    • Create pipeline configuration for the new project to create a Docker image from the Dockerfile, build and push a Docker image to the container registry, and then scan the Docker image for vulnerabilities.
+    • Check for reported vulnerabilities.
+    • Update the Docker image and scan the updated image.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/tutorials/container_scanning/
+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: 3.2
+    version: 7
+    name: Perform Authenticated Vulnerability Scanning
+    description: >-
+      Perform authenticated vulnerability scanning with agents running locally on 
+      each system or with remote scanners that are configured with elevated rights on 
+      the system being tested.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_worker_2_2/monitor_worker_resource_consumption.yml

@@ -0,0 +1,59 @@
+---
+id: 2.2.8
+name: monitor_worker_resource_consumption
+title: Ensure resource consumption of build workers is monitored
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  Monitor the resource consumption of build workers and set alerts for high consumption 
+  that can lead to resource exhaustion.
+rationale: >-
+  Resource exhaustion is when machine resources or services are highly consumed until 
+  exhausted. Resource exhaustion may lead to DOS (Denial of Service). When such a 
+  situation happens to build workers, it slows down and even stops the build process, 
+  which harms the production of artifacts and the organization's ability to deliver software 
+  on schedule. To prevent that, it is recommended to monitor resources consumption in 
+  the build workers and set alerts to notify when they are highly consumed. That way 
+  resource exhaustion can be acknowledged and prevented at an early stage.
+impact: >-
+audit: |
+  Verify that there is monitoring of resources consumption for each build worker.
+  GitLab Runner is instrumented with native Prometheus metrics, which can be exposed via an embedded HTTP server on the /metrics path. The server - if enabled - can be scraped by the Prometheus monitoring system or accessed with any other HTTP client.
+
+  This is the list of available metrics:
+    • #HELP gitlab_runner_api_request_statuses_total The total number of api requests, partitioned by runner, endpoint and status.
+    • #HELP gitlab_runner_autoscaling_machine_creation_duration_seconds Histogram of machine creation time.
+    • #HELP gitlab_runner_autoscaling_machine_states The current number of machines per state in this provider.
+    • #HELP gitlab_runner_concurrent The current value of concurrent setting
+    • #HELP gitlab_runner_errors_total The number of caught errors.
+    • #HELP gitlab_runner_limit The current value of limit setting
+    • #HELP gitlab_runner_request_concurrency The current number of concurrent requests for a new job
+    • #HELP gitlab_runner_request_concurrency_exceeded_total Count of excess requests above the configured request_concurrency limit
+    • #HELP gitlab_runner_version_info A metric with a constant '1' value labeled by different build stats fields.
+remediation: |
+  Set resources consumption monitoring for each build worker.
+  To learn how to set up a Prometheus server to scrape this HTTP endpoint and make use of the collected metrics, see Prometheus's Getting started guide. Once this is done, the following information will be exposed:
+  
+  The exposed information includes:
+    • Runner business logic metrics (e.g., the number of currently running jobs)
+    • Go-specific process metrics (garbage collection stats, goroutines, memstats, etc.)
+    • general process metrics (memory usage, CPU usage, file descriptor usage, etc.)
+    • build version information
+default_value:
+references:
+  - https://docs.gitlab.com/runner/monitoring/index.html
+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/build_pipelines_2/build_worker_2_2/pass_worker_envs_and_commands.yml

@@ -0,0 +1,48 @@
+---
+id: 2.2.2
+name: pass_worker_envs_and_commands
+title: Ensure build worker environments and commands are passed and not pulled
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  A worker's environment can be passed (for example, a pod in a Kubernetes cluster in 
+  which an environment variable is passed to it). It also can be pulled, like a virtual 
+  machine that is installing a package. Ensure that the environment and commands are 
+  passed to the workers and not pulled from it.
+rationale: >-
+  Passing an environment means additional configuration happens in the build time phase 
+  and not in run time. It will also pass locally and not remotely. Passing a worker 
+  environment, instead of pulling it from an outer source, reduces the possibility for an 
+  attacker to gain access and potentially pull malicious code into it. By passing locally and 
+  not pulling from remote, there is also less chance of an attack based on the remote 
+  connection, such as a man-in-the-middle or malicious scripts that can run from remote. 
+  This therefore prevents possible infection of the build worker.
+impact: >-
+audit: |
+  For each build worker, ensure its environment and commands are passed and not pulled.
+    1. Review .gitlab-ci.yml and Runner Configurations: Check your project's .gitlab-ci.yml file and any associated Runner configurations to ensure that all necessary environment variables, commands, and configurations are explicitly defined and passed to the Runner. This involves reviewing the job definitions to confirm they do not rely on external sources for configuration at runtime.
+    2. Examine Runner Execution Environment: Verify that the execution environment of the Runner (whether it's a Docker container, a Kubernetes pod, or a virtual machine) receives its configuration from the .gitlab-ci.yml file or the GitLab project settings directly, without pulling from external sources during the job execution.
+    3. Check for External Dependencies: Ensure that any external dependencies, such as third-party libraries or tools, are explicitly defined and version-controlled within the project repository or through secure, trusted registries. Avoid configurations that allow the Runner to dynamically fetch or update these dependencies during the build process without strict version controls.
+remediation: |
+  For each build worker, pass its environment and commands to it instead of pulling it.
+    1. Update .gitlab-ci.yml: Amend your .gitlab-ci.yml file to include all necessary environment variables and configurations directly within the file or through secure, project-level settings in GitLab. Avoid dynamic fetching of configurations from external sources during runtime.
+    2. Secure Runner Environment: Configure your GitLab Runner environments (Docker, Kubernetes, VMs, etc.) to use pre-defined images and configurations that do not require pulling additional settings or scripts during execution. Use trusted, version-controlled base images and scripts.
+    3. Utilize Secure Variables and Templates: Leverage GitLab's features for secure variables and include templates for common configurations to ensure that environment settings and commands are passed securely and consistently across all projects.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/#the-gitlab-ciyml-file
+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/build_pipelines_2/build_worker_2_2/readme.md

@@ -0,0 +1,16 @@
+# 2.2 Build Worker
+
+This section consists of security recommendations for build workers management and use.
+
+Build workers are often called Runners. They are the infrastructure on which the pipeline runs. Build workers are considered sensitive because usually they have access to multiple, if not all, software supply chain components. One worker can run code checkout with source code management access, run tests, and push to the registry which requires access to it. Also, some of the pipeline commands running in a build worker can be vulnerable to attack and enlarge the attack surface. Because of all of that, it is especially important to ensure that the build workers are protected.
+
+## Recommendations
+
+* [2.2.1 - single_use_workers.yml](./single_use_workers.yml)
+* [2.2.2 - pass_worker_envs_and_commands.yml](./pass_worker_envs_and_commands.yml)
+* [2.2.3 - segregate_worker_duties.yml](./segregate_worker_duties.yml)
+* [2.2.4 - restrict_worker_connectivity.yml](./restrict_worker_connectivity.yml)
+* [2.2.5 - worker_runtime_security.yml](./worker_runtime_security.yml)
+* [2.2.6 - build_worker_vuln_scanning.yml](./build_worker_vuln_scanning.yml)
+* [2.2.7 - store_worker_config.yml](./store_worker_config.yml)
+* [2.2.8 - monitor_worker_resource_consumption.yml](./monitor_worker_resource_consumption.yml)

gitlabcis/recommendations/build_pipelines_2/build_worker_2_2/restrict_worker_connectivity.yml

@@ -0,0 +1,61 @@
+---
+id: 2.2.4
+name: restrict_worker_connectivity
+title: Ensure build workers have minimal network connectivity
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  Ensure that build workers have minimal network connectivity.
+rationale: >-
+  Restricting the network connectivity of build workers decreases the possibility that an 
+  attacker would be capable of entering the organization from the outside. If the build 
+  workers are connected to the public internet without any restriction, it is far simpler for 
+  attackers to compromise them. Limiting network connectivity between build workers 
+  also protects the organization in case an attacker was successful and subsequently 
+  attempts to spread the attack to other components of the environment.
+impact: >-
+  Developers will not have connectivity to every resource they might need from the 
+  outside. Workers will also only be able to exchange data through shareable storage.
+audit: |
+  Verify that build workers, environment, and any other components have only the required minimum of network connectivity.
+
+  Review these configuration measures for your self-managed runners:
+    • Configuring runner virtual machines in their own network segment
+    • Blocking SSH access from the Internet to runner virtual machines
+    • Restricting traffic between runner virtual machines
+    • Filtering access to cloud provider metadata endpoints
+remediation: |
+  Limit the network connectivity of build workers, environment, and any other components to the necessary minimum.
+
+  Ensure these configuration measures are in place for your self-managed runners:
+    • Configuring runner virtual machines in their own network segment
+    • Blocking SSH access from the Internet to runner virtual machines
+    • Restricting traffic between runner virtual machines
+    • Filtering access to cloud provider metadata endpoints
+default_value:
+references:
+  - https://docs.gitlab.com/runner/security/#network-segmentation
+cis_controls:
+  - id: 13.5
+    version: 8
+    name: Manage Access Control for Remote Assets
+    description: >-
+      Manage access control for assets remotely connecting to enterprise resources. 
+      Determine amount of access to enterprise resources based on: up-to-date anti-
+      malware software installed, configuration compliance with the enterprise's secure 
+      configuration process, and ensuring the operating system and applications are up-
+      to-date.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 12.12
+    version: 7
+    name: Manage All Devices Remotely Logging into Internal Network
+    description: >-
+      Scan all enterprise devices remotely logging into the organization's network 
+      prior to accessing the network to ensure that each of the organization's security 
+      policies has been enforced in the same manner as local network devices.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_worker_2_2/segregate_worker_duties.yml

@@ -0,0 +1,78 @@
+---
+id: 2.2.3
+name: segregate_worker_duties
+title: Ensure the duties of each build worker are segregated
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  Separate responsibilities in the build workflow, such as testing, compiling, pushing 
+  artifacts, etc., to different build workers so that each worker will have a single duty.
+rationale: >-
+  Separating duties and allocating them to many workers makes it easier to verify each 
+  step in the build process and ensure there is no corruption. It also limits the effect of an 
+  attack on a build worker, as such an attack would be less critical if the worker has less 
+  access and duties that are subject to harm.
+impact: >-
+audit: |
+  To ensure separation of duties, you can have runner only running jobs for a specific project or a specific group.
+
+  For a group:
+    • On the left sidebar, select Search or go to and find your group.
+    • Select Settings > CI/CD.
+    • Expand the Runners section.
+    • Review the Runners related to your specific group.
+
+  For a project:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Settings > CI/CD.
+    • Expand the Runners section.
+    • Review the Runners related to your specific project.
+remediation: |
+  To ensure separation of duties, create runners dedicated to a single group or project.
+
+  For a group:
+    • On the left sidebar, select Search or go to and find your group.
+    • Select Build > Runners.
+    • Select New group runner.
+    • Select the operating system where GitLab Runner is installed.
+    • In the Tags section, in the Tags field, enter the job tags to specify jobs the runner can run. If there are no job tags for this runner, select Run untagged.
+    • Optional. In the Runner description field, add a runner description that displays in GitLab.
+    • Optional. In the Configuration section, add additional configurations.
+    • Select Create runner.
+    • Follow the on-screen instructions to register the runner from the command line.
+      • When prompted by the command line:
+        • For the GitLab instance URL, use the URL for your GitLab instance. For example, if your project is hosted on gitlab.example.com/yourname/yourproject, your GitLab instance URL is https://gitlab.example.com.
+        • For the executor, enter the type of executor. The executor is the environment where the runner executes the job.
+
+  For a project:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Settings > CI/CD.
+    • Expand the Runners section.
+    • Select New project runner.
+    • Select the operating system where GitLab Runner is installed.
+    • In the Tags section, in the Tags field, enter the job tags to specify jobs the runner can run. If there are no job tags for this runner, select Run untagged.
+    • Optional. In the Runner description field, add a description for the runner that displays in GitLab.
+    • Optional. In the Configuration section, add additional configurations.
+    • Select Create runner.
+    • Follow the on-screen instructions to register the runner from the command line.
+      • When prompted by the command line:
+        • For the GitLab instance URL, use the URL for your GitLab instance. For example, if your project is hosted on gitlab.example.com/yourname/yourproject, your GitLab instance URL is https://gitlab.example.com.
+        • For the executor, enter the type of executor. The executor is the environment where the runner executes the job.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/runners/runners_scope.html
+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/build_pipelines_2/build_worker_2_2/single_use_workers.yml

@@ -0,0 +1,47 @@
+---
+id: 2.2.1
+name: single_use_workers
+title: Ensure build workers are single-used
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  Use a clean instance of build worker for every pipeline run.
+rationale: >-
+  Using a clean instance of build worker for every pipeline run eliminates the risks of data 
+  theft, data integrity breaches, and unavailability. It limits the pipeline's access to data 
+  stored on the file system from previous runs, and the cache is volatile. This prevents 
+  malicious changes from affecting other pipelines or the Continuous 
+  Integration/Continuous Delivery system itself.
+impact: >-
+  Data and cache will not be saved in different pipeline runs.
+audit: >-
+  Ensure that every pipeline that is being run has its own clean, new runner. 
+  In GitLab, each of your jobs runs in a newly provisioned VM, which is dedicated to the 
+  specific job. 
+  The VM is active only for the duration of the job and immediately deleted. 
+  This means that any changes that your job makes to the virtual machine will not be 
+  available to a subsequent job. 
+  The virtual machine where your job runs has sudo access with no password.
+remediation: >-
+  Create a clean build worker for every pipeline that is being run, or use build platform-
+  hosted runners, as they typically offer a clean instance for every run. 
+  In GitLab, use Runner SaaS to ensure all of these settings are available by default and 
+  that each job runs in a dedicated VM.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/runners/index.html
+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/build_pipelines_2/build_worker_2_2/store_worker_config.yml

@@ -0,0 +1,62 @@
+---
+id: 2.2.7
+name: store_worker_config
+title: Ensure build workers' deployment configuration is stored in a version control platform
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  Store the deployment configuration of build workers in a version control platform, such 
+  as GitLab.
+rationale: >-
+  Build workers are a sensitive part of the build phase. They generally have access to the 
+  code repository, the Continuous Integration platform, the deployment platform, etc. This 
+  means that an attacker gaining access to a build worker may compromise other 
+  platforms in the organization and cause a major incident. One thing that can protect 
+  workers is to ensure that their deployment configuration is safe and well-configured. 
+  Storing the deployment configuration in version control enables more observability of 
+  these configurations because everything is catalogued in a single place. It adds another 
+  layer of security, as every change will be reviewed and noticed, and thus malicious 
+  changes will theoretically occur less. In the case of a mistake, bug, or security incident, 
+  it also offers an easier way to "revert" back to a safe version or add a "hot fix" quickly.
+impact: >-
+  Changes in deployment configuration may only be applied by declaration in the version 
+  control platform. This could potentially slow down the development process.
+audit: |
+  Verify that the deployment configuration of build workers is stored in a version control platform.
+    • On the left sidebar, select Code > Repository.
+    • Check if a .gitlab-ci.yml file is at the root of your repository.
+remediation: |
+  Document and store every deployment configuration of build workers in a version control platform.
+    • On the left sidebar, select Code > Repository.
+    • Above the file list, select the branch you want to commit to. If you're not sure, leave master or main. Then select the plus icon () and New file:
+    • For the Filename, type .gitlab-ci.yml.
+    • Select Commit changes.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/quick_start/index.html
+cis_controls:
+  - id: 4.1
+    version: 8
+    name: Establish and Maintain a Secure Configuration Process
+    description: >-
+      Establish and maintain a secure configuration process for enterprise assets 
+      (end-user devices, including portable and mobile, non-computing/IoT devices, and 
+      servers) and software (operating systems and applications). Review and update 
+      documentation annually, or when significant enterprise changes occur that could 
+      impact this Safeguard.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 5.1
+    version: 7
+    name: Establish Secure Configurations
+    description: >-
+      Maintain documented, standard security configuration standards for all 
+      authorized operating systems and software.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_worker_2_2/worker_runtime_security.yml

@@ -0,0 +1,37 @@
+---
+id: 2.2.5
+name: worker_runtime_security
+title: Ensure run-time security is enforced for build workers
+profile: 1
+category: build_pipelines
+sub_category: build_worker
+description: >-
+  Add traces to build workers' operating systems and installed applications so that in run 
+  time, collected events can be analyzed to detect suspicious behavior patterns and 
+  malware.
+rationale: >-
+  Build workers are exposed to data exfiltration attacks, code injection attacks, and more 
+  while running. It is important to secure them from such attacks by enforcing run-time 
+  security on the build worker itself. This will identify attempted attacks in real time and 
+  prevent them.
+impact: >-
+audit: >-
+  Verify that a run-time security solution is enforced on every active build worker.
+remediation: >-
+  Deploy and enforce a run-time security solution on build workers.
+default_value:
+references:
+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: >-