gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/build_pipelines_2/pipeline_instructions_2_3/build_stage_io.yml

@@ -0,0 +1,49 @@
+---
+id: 2.3.2
+name: build_stage_io
+title: Ensure steps have clearly defined build stage input and output
+profile: 1
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Define clear expected input and output for each build stage.
+rationale: >-
+  In order to have more control over data flow in the build pipeline, clearly define the input 
+  and output of the pipeline steps. If anything malicious happens during the build stage, it 
+  will be recognized more easily and stand out as an anomaly.
+impact: >-
+audit: |
+  For each build stage, verify that the expected input and output are clearly defined.
+    • On the left sidebar, select Code > Repository.
+    • Review the .gitlab-ci.yml file to check if the build stage job input and output are clearly defined.
+remediation: |
+  For each build stage, clearly define what is expected for input and output.
+    • On the left sidebar, select Code > Repository.
+    • Ensure the .gitlab-ci.yml file has build stage job input and output clearly defined.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/pipelines/
+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/build_pipelines_2/pipeline_instructions_2_3/build_steps_as_code.yml

@@ -0,0 +1,42 @@
+---
+id: 2.3.1
+name: build_steps_as_code
+title: Ensure all build steps are defined as code
+profile: 1
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Use pipeline as code for build pipelines and their defined steps.
+rationale: >-
+  Storing pipeline instructions as code in a version control system means automation of 
+  the build steps and less room for human error, which could potentially lead to a security 
+  breach. Additionally, It creates the ability to revert back to a previous pipeline 
+  configuration in order to pinpoint the affected change should a malicious incident occur.
+impact: >-
+audit: |
+  Verify that all build steps are defined as code and stored in a version control system.
+    • On the left sidebar, select Code > Repository.
+    • Check if a .gitlab-ci.yml file is at the root of your repository
+remediation: |
+  Convert pipeline instructions into code-based syntax and upload them to the organization's 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/pipelines/
+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/pipeline_instructions_2_3/limit_pipeline_triggers.yml

@@ -0,0 +1,76 @@
+---
+id: 2.3.5
+name: limit_pipeline_triggers
+title: Ensure access to build process triggering is minimized
+profile: 1
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Restrict access to pipeline triggers.
+rationale: >-
+  Build pipelines are used for multiple reasons. Some are very sensitive, such as 
+  pipelines which deploy to production. In order to protect the environment from malicious 
+  acts or human mistakes, such as a developer deploying a bug to production, it is 
+  important to apply the Least Privilege principle to pipeline triggering. This principle 
+  requires restrictions placed on which users can run which pipeline. It allows for sensitive 
+  pipelines to only be run by administrators, who are generally the most trusted and 
+  skilled members of the organization.
+impact: >-
+audit: |
+  For every pipeline in use, verify only the necessary users have permission to trigger it.
+    • 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, sort by Max role the members have in the group
+    • Review the members to ensure relevant members are allowed to trigger pipelines in protected environments.
+remediation: |
+  For every pipeline in use, grant only the necessary users permission to trigger it.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Settings > CI/CD.
+    • Expand Protected environments.
+    • Select Protect an environment.
+    • From the Environment list, select the environment you want to protect.
+    • In the Allowed to deploy list, select the role, users, or groups you want to give deploy access to. Keep in mind that:
+      • There are two roles to choose from:
+        • Maintainers: Allows access to all of the project's users with the Maintainer role.
+        • Developers: Allows access to all of the project's users with the Maintainer and Developer role.
+      • You can only select groups that are already invited to the project.
+      • Users must have at least the Developer role to appear in the Allowed to deploy list.
+    • In the Approvers list, select the role, users, or groups you want to give deploy access to. Keep in mind that:
+      • There are two roles to choose from:
+        • Maintainers: Allows access to all of the project's users with the Maintainer role.
+        • Developers: Allows access to all of the project's users with the Maintainer and Developer role.
+      • You can only select groups that are already invited to the project.
+      • Users must have at least the Developer role to appear in the Approvers list.
+    • In the Approval rules section:
+      • Ensure that this number is less than or equal to the number of members in the rule.
+      • See Deployment Approvals for more information about this feature.
+    • Select Protect.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/environments/protected_environments.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/build_pipelines_2/pipeline_instructions_2_3/pipeline_misconfiguration_scanning.yml

@@ -0,0 +1,48 @@
+---
+id: 2.3.6
+name: pipeline_misconfiguration_scanning
+title: Ensure pipelines are automatically scanned for misconfigurations
+profile: 1
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Scan the pipeline for misconfigurations. It is recommended that this be performed 
+  automatically.
+rationale: >-
+  Automatic scans for misconfigurations detect human mistakes and misconfigured tasks. 
+  This protects the environment from backdoors caused by such mistakes, which create 
+  easier access for attackers. For example, a task that mistakenly configures credentials 
+  to persist on the disk makes it easier for an attacker to steal them. This type of incident 
+  can be prevented by auto-scanning.
+impact: >-
+audit: >-
+  For each pipeline, verify that it is automatically scanned for misconfigurations.
+remediation: >-
+  For each pipeline, set automated misconfiguration scanning.
+default_value:
+references:
+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/pipeline_instructions_2_3/pipeline_secret_scanning.yml

@@ -0,0 +1,56 @@
+---
+id: 2.3.8
+name: pipeline_secret_scanning
+title: Ensure scanners are in place to identify and prevent sensitive data in pipeline files
+profile: 2
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Detect and prevent sensitive data, such as confidential ID numbers, passwords, etc., in 
+  pipelines.
+rationale: >-
+  Sensitive data in pipeline configuration, such as cloud provider credentials or repository 
+  credentials, create vulnerabilities with which malicious actors could steal such 
+  information if they gain access to a pipeline. In order to mitigate this, set scanners that 
+  will identify and prevent the existence of sensitive data in the pipeline.
+impact: >-
+audit: |
+  For every pipeline that is in use, verify that scanners are set to identify and prevent the existence of sensitive data within it.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Build > Pipeline editor.
+    • Ensure the following lines are present in your gitlab-ci.yml.
+      include:
+        - template: Jobs/Secret-Detection.gitlab-ci.yml
+remediation: |
+  For every pipeline that is in use, set scanners that will identify and prevent sensitive data within it.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Build > Pipeline editor.
+    • Copy and paste the following to the bottom of the .gitlab-ci.yml file. If an include line already exists, add only the template line below it.
+      include:
+        - template: Jobs/Secret-Detection.gitlab-ci.yml
+    • Select the Validate tab, then select Validate pipeline. The message Simulation completed successfully indicates the file is valid.
+    • Select the Edit tab.
+    • Optional. In the Commit message text box, customize the commit message. In the Branch text box, enter the name of the default branch.
+    • Select Commit changes
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/secret_detection/
+cis_controls:
+  - id: 3.14
+    version: 8
+    name: Log Sensitive Data Access
+    description: >-
+      Log sensitive data access, including modification and disposal.
+    implementation_groups:
+      - IG3
+  - id: 14.5
+    version: 7
+    name: Utilize an Active Discovery Tool to Identify Sensitive Data
+    description: >-
+      Utilize an active discovery tool to identify all sensitive information stored, 
+      processed, or transmitted by the organization's technology systems, including 
+      those located onsite or at a remote service provider and update the organization's 
+      sensitive information inventory.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/pipeline_instructions_2_3/pipeline_vuln_scanning.yml

@@ -0,0 +1,44 @@
+---
+id: 2.3.7
+name: pipeline_vuln_scanning
+title: Ensure pipelines are automatically scanned for vulnerabilities
+profile: 1
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Scan pipelines for vulnerabilities. It is recommended that this be implemented 
+  automatically.
+rationale: >-
+  Automatic scanning for vulnerabilities detects known vulnerabilities in pipeline 
+  instructions and components, allowing faster patching in case one is found. 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: >-
+  For each pipeline, verify that it is automatically scanned for vulnerabilities.
+remediation: >-
+  For each pipeline, set automated vulnerability scanning.
+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: 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/pipeline_instructions_2_3/readme.md

@@ -0,0 +1,16 @@
+# 2.3 Pipeline Instructions
+
+This section consists of security recommendations for pipeline instructions and commands.
+
+Pipeline instructions are dedicated to taking raw files of source code and running a series of tasks on them to achieve some final artifact as output. They are most of the time written by third-party developers so they should be treated carefully and can also be vulnerable to attack in certain situations. Pipeline instructions files are considered very sensitive, and it is important to secure all their aspects - instructions, access, etc.
+
+## Recommendations
+
+* [2.3.1 - build_steps_as_code.yml](./build_steps_as_code.yml)
+* [2.3.2 - build_stage_io.yml](./build_stage_io.yml)
+* [2.3.3 - secure_pipeline_output.yml](./secure_pipeline_output.yml)
+* [2.3.4 - track_pipeline_files.yml](./track_pipeline_files.yml)
+* [2.3.5 - limit_pipeline_triggers.yml](./limit_pipeline_triggers.yml)
+* [2.3.6 - pipeline_misconfiguration_scanning.yml](./pipeline_misconfiguration_scanning.yml)
+* [2.3.7 - pipeline_vuln_scanning.yml](./pipeline_vuln_scanning.yml)
+* [2.3.8 - pipeline_secret_scanning.yml](./pipeline_secret_scanning.yml)

gitlabcis/recommendations/build_pipelines_2/pipeline_instructions_2_3/secure_pipeline_output.yml

@@ -0,0 +1,52 @@
+---
+id: 2.3.3
+name: secure_pipeline_output
+title: Ensure output is written to a separate, secured storage repository
+profile: 1
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Write pipeline output artifacts to a secured storage repository.
+rationale: >-
+  To maintain output artifacts securely and reduce the potential surface for attack, store 
+  such artifacts separately in secure storage. This separation enforces the Single 
+  Responsibility Principle by ensuring the orchestration platform will not be the same as 
+  the artifact storage, which reduces the potential harm of an attack. Using the same 
+  security considerations as the input (for example, the source code) will protect artifacts 
+  stored and will make it harder for a malicious actor to successfully execute an attack.
+impact: >-
+audit: |
+  For each pipeline that produces output artifacts, ensure that they're written to a secured storage repository.
+  Review where job output artifacts are stored, either locally or in object storage. By default artifacts are stored locally in:
+    • Linux package (Omnibus): /var/opt/gitlab/gitlab-rails/shared/artifacts
+    • Self-compiled (source): /home/git/gitlab/shared/artifacts
+remediation: >-
+  For each pipeline that produces output artifacts, write them to a secured storage repository.
+  One approach is to activate object storage and use an encrypted S3 bucket (or similar).
+
+  Once the storage is configured, these are the steps to activate it for job artifacts:
+
+  Linux package (Omnibus):
+    • Configure the object storage.
+    • Migrate the artifacts: sudo gitlab-rake gitlab:artifacts:migrate
+    • Verify that there are no files on disk in the artifacts directory: sudo find /var/opt/gitlab/gitlab-rails/shared/artifacts -type f | grep -v tmp | wc -l
+
+  Self-compiled (source):
+  • Configure the object storage.
+  • Migrate the artifacts: sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
+  • Verify that there are no files on disk in the artifacts directory: sudo find /home/git/gitlab/shared/artifacts -type f | grep -v tmp | wc -l
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/job_artifacts.html?tab=Self-compiled+%28source%29#migrating-to-object-storage
+cis_controls:
+  - id: 3.12
+    version: 8
+    name: Segment Data Processing and Storage Based on Sensitivity
+    description: >-
+      Segment data processing and storage based on the sensitivity of the data. 
+      Do not process sensitive data on enterprise assets intended for lower sensitivity 
+      data.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/pipeline_instructions_2_3/track_pipeline_files.yml

@@ -0,0 +1,48 @@
+---
+id: 2.3.4
+name: track_pipeline_files
+title: Ensure changes to pipeline files are tracked and reviewed
+profile: 1
+category: build_pipelines
+sub_category: pipeline_instructions
+description: >-
+  Track and review changes to pipeline files.
+rationale: >-
+  Pipeline files are sensitive files. They have the ability to access sensitive data and 
+  control the build process, thus it is just as important to review changes to pipeline files 
+  as it is to verify source code. Malicious actors can potentially add harmful code to these 
+  files, which may lead to sensitive data exposure and hijacking of the build environment 
+  or artifacts.
+impact: >-
+audit: |
+  For each pipeline file, ensure changes to it are being tracked and reviewed.
+    • On the left sidebar, select Code > Repository.
+    • Check if a .gitlab-ci.yml file is at the root of your repository
+    • If it exists, all changes will be tracked via Git.
+    • In the upper-right corner, select History to review the history of the gitlab-ci.yml file
+remediation: |
+  For each pipeline file, track changes to it and review them.
+    • 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:
+cis_controls:
+  - id: 3.14
+    version: 8
+    name: Log Sensitive Data Access
+    description: >-
+      Log sensitive data access, including modification and disposal.
+    implementation_groups:
+      - IG3
+  - id: 14.9
+    version: 7
+    name: Enforce Detail Logging for Access or Changes to Sensitive Data
+    description: >-
+      Enforce detailed audit logging for access to sensitive data or changes to 
+      sensitive data (utilizing tools such as File Integrity Monitoring or Security 
+      Information and Event Monitoring).
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/pipeline_integrity_2_4/create_reproducible_artifacts.yml

@@ -0,0 +1,52 @@
+---
+id: 2.4.4
+name: create_reproducible_artifacts
+title: Ensure the build pipeline creates reproducible artifacts
+profile: 1
+category: build_pipelines
+sub_category: pipeline_integrity
+description: >-
+  Verify that the build pipeline creates reproducible artifacts, meaning that an artifact of 
+  the build pipeline is the same in every run when given the same input.
+rationale: >-
+  A reproducible build is a build that produces the same artifact when given the same 
+  input data. Ensuring that the build pipeline produces the same artifact when given the 
+  same input helps verify that no change has been made to the artifact. This action allows 
+  an organization to trust that its artifacts are built only from safe code that has been 
+  reviewed and tested and has not been tainted or changed abruptly.
+impact: >-
+audit: |
+  Ensure that build pipelines create reproducible artifacts.
+    • On the left sidebar, select Build > Artifacts.
+    • Review the artifacts associated to your build pipelines
+remediation: |
+  Create build pipelines that produce the same artifact given the same input (for example, artifacts that do not rely on timestamps).
+    • On the left sidebar, select Code > Repository.
+    • Check if a .gitlab-ci.yml file is at the root of your repository
+    • To create job artifacts, use the artifacts keyword in your .gitlab-ci.yml file, as in this example:
+
+      pdf:
+      script: xelatex mycv.tex
+      artifacts:
+      paths:
+      - mycv.pdf
+
+  In this example, a job named pdf calls the xelatex command to build a PDF file from the LaTeX source file, mycv.tex.
+  The paths keyword determines which files to add to the job artifacts. All paths to files and directories are relative to the repository where the job was created.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/jobs/job_artifacts.html#create-job-artifacts
+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/pipeline_integrity_2_4/lock_dependencies.yml

@@ -0,0 +1,59 @@
+---
+id: 2.4.2
+name: lock_dependencies
+title: Ensure all external dependencies used in the build process are locked
+profile: 1
+category: build_pipelines
+sub_category: pipeline_integrity
+description: >-
+  External dependencies may be public packages needed in the pipeline, or perhaps the 
+  public image being used for the build worker. Lock these external dependencies in 
+  every build pipeline.
+rationale: >-
+  External dependencies are sources of code that aren't under organizational control. 
+  They might be intentionally or unintentionally infected with malicious code or have 
+  known vulnerabilities, which could result in sensitive data exposure, data harvesting, or 
+  the erosion of trust in an organization. Locking each external dependency to a specific, 
+  safe version gives more control and less chance for risk.
+impact: >-
+audit: |
+  Ensure every external dependency being used in pipelines is locked.
+    • Go to Code > Repository in your project
+    • Review the following files at the root of your repository:
+      • Gemfiles
+      • package.jsons
+      • go.sum
+    • Review the versions of the external dependencies
+remediation: |
+  For all external dependencies being used in pipelines, verify they are locked.
+    • Go to Code > Repository in your project
+    • Review the following files at the root of your repository:
+      • Gemfiles
+      • package.jsons
+      • go.sum
+    • Ensure the version of the external dependencies corresponds to your internal
+    policies
+default_value:
+references:
+cis_controls:
+  - id: 16.5
+    version: 8
+    name: Use Up-to-Date and Trusted Third-Party Software Components
+    description: >-
+      Use up-to-date and trusted third-party software components. When possible, 
+      choose established and proven frameworks and libraries that provide adequate 
+      security. Acquire these components from trusted sources or evaluate the software 
+      for vulnerabilities before use.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 18.4
+    version: 7
+    name: Only Use Up-to-date And Trusted Third-Party Components
+    description: >-
+      Only use up-to-date and trusted third-party components for the software 
+      developed by the organization.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/pipeline_integrity_2_4/pipeline_produces_sbom.yml

@@ -0,0 +1,81 @@
+---
+id: 2.4.5
+name: pipeline_produces_sbom
+title: Ensure pipeline steps produce a Software Bill of Materials (SBOM)
+profile: 1
+category: build_pipelines
+sub_category: pipeline_integrity
+description: >-
+  SBOM (Software Bill of Materials) is a file that specifies each component of software or 
+  a build process. Generate an SBOM after each run of a pipeline.
+rationale: >-
+  Generating a Software Bill of Materials after each run of a pipeline will validate the 
+  integrity and security of that pipeline. Recording every step or component role in the 
+  pipeline ensures that no malicious acts have been committed during the pipeline's run.
+impact: >-
+audit: |
+  For each pipeline, ensure it produces a Software Bill of Materials on every run.
+    • Check if your gitlab-ci.yml file contains the following:
+      include:
+      - template: Jobs/Dependency-Scanning.gitlab-ci.yml
+    If your project has the following structure:
+      .
+      ├── ruby-project/
+      │   └── Gemfile.lock
+      ├── ruby-project-2/
+      │   └── Gemfile.lock
+      ├── php-project/
+      │   └── composer.lock
+      └── go-project/
+          └── go.sum
+    Then the Gemnasium scanner generates the following CycloneDX SBOMs:
+      .
+      ├── ruby-project/
+      │   ├── Gemfile.lock
+      │   └── gl-sbom-gem-bundler.cdx.json
+      ├── ruby-project-2/
+      │   ├── Gemfile.lock
+      │   └── gl-sbom-gem-bundler.cdx.json
+      ├── php-project/
+      │   ├── composer.lock
+      │   └── gl-sbom-packagist-composer.cdx.json
+      └── go-project/
+          ├── go.sum
+          └── gl-sbom-go-go.cdx.json
+    • Review if these files exists in your environment
+remediation: |
+  For each pipeline, configure it to produce a Software Bill of Materials on every run.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Build > Pipeline editor.
+    • If no .gitlab-ci.yml file exists, select Configure pipeline, then delete the example content.
+    • Copy and paste the following to the bottom of the .gitlab-ci.yml file. If an include line already exists, add only the template line below it.
+      include:
+        - template: Jobs/Dependency-Scanning.gitlab-ci.yml
+    • Select the Validate tab, then select Validate pipeline. The message Simulation completed successfully confirms the file is valid.
+    • Select the Edit tab.
+    • Complete the fields. Do not use the default branch for the Branch field.
+    • Select the Start a new merge request with these changes checkbox, then select Commit changes.
+    • Complete the fields according to your standard workflow, then select Create merge request.
+    • Review and edit the merge request according to your standard workflow, then select Merge.
+
+    The CycloneDX SBOMs are:
+    • Named gl-sbom--.cdx.json.
+    • Available as job artifacts of the dependency scanning job.
+    • Saved in the same directory as the detected lock or build files.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/dependency_scanning/
+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/pipeline_integrity_2_4/pipeline_signs_sbom.yml

@@ -0,0 +1,38 @@
+---
+id: 2.4.6
+name: pipeline_sign_sbom
+title: Ensure pipeline steps sign the Software Bill of Materials (SBOM) produced
+profile: 1
+category: build_pipelines
+sub_category: pipeline_integrity
+description: >-
+  SBOM (Software Bill of Materials) is a file that specifies each component of software or 
+  a build process. It should be generated after every pipeline run. After it is generated, it 
+  must then be signed.
+rationale: >-
+  Software Bill of Materials (SBOM) is a file used to validate the integrity and security of a 
+  build pipeline. Signing it ensures that no one tampered with the file when it was 
+  delivered. Such interference can happen if someone tries to hide unusual activity. 
+  Validating the SBOM signature can detect this activity and prevent much greater 
+  incident.
+impact: >-
+audit: >-
+  For each pipeline, ensure it signs the Software Bill of Materials it produces on every run.
+remediation: >-
+  For each pipeline, configure it to sign its produced Software Bill of Materials on every run.
+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: >-