gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/build_pipelines_2/pipeline_integrity_2_4/readme.md

@@ -0,0 +1,14 @@
+# 2.4 Pipeline Integrity
+
+This section consists of security recommendations for keeping pipeline integrity.
+
+Integrity means ensuring that the pipelines, the dependencies they use, and their artifacts are all authentic and what they intended to be. Securing the pipeline integrity is to verify that every change and process running during the build pipeline run is what it is supposed to be. One way to do that for example is to lock each dependency to a certain secured version. It is important to insist on securing that because this is the way to set trust with the customer.
+
+## Recommendations
+
+* [2.4.1 - sign_artifacts.yml](./sign_artifacts.yml)
+* [2.4.2 - lock_dependencies.yml](./lock_dependencies.yml)
+* [2.4.3 - validate_dependencies.yml](./validate_dependencies.yml)
+* [2.4.4 - create_reproducible_artifacts.yml](./create_reproducible_artifacts.yml)
+* [2.4.5 - pipeline_produces_sbom.yml](./pipeline_produces_sbom.yml)
+* [2.4.6 - pipeline_sign_sbom.yml](./pipeline_signs_sbom.yml)

gitlabcis/recommendations/build_pipelines_2/pipeline_integrity_2_4/sign_artifacts.yml

@@ -0,0 +1,35 @@
+---
+id: 2.4.1
+name: sign_artifacts
+title: Ensure all artifacts on all releases are signed
+profile: 1
+category: build_pipelines
+sub_category: pipeline_integrity
+description: >-
+  Sign all artifacts in all releases with user or organization keys.
+rationale: >-
+  Signing artifacts is used to validate both their integrity and security. Organizations signal 
+  that artifacts may be trusted and they themselves produced them by ensuring that every 
+  artifact is properly signed. The presence of this signature also makes potentially 
+  malicious activity far more difficult.
+impact: >-
+audit: >-
+  Ensure every artifact in every release is signed.
+remediation: >-
+  For every artifact in every release, verify that all are properly signed.
+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: >-

gitlabcis/recommendations/build_pipelines_2/pipeline_integrity_2_4/validate_dependencies.yml

@@ -0,0 +1,63 @@
+---
+id: 2.4.3
+name: validate_dependencies
+title: Ensure dependencies are validated before being used
+profile: 1
+category: build_pipelines
+sub_category: pipeline_integrity
+description: >-
+  Validate every dependency of the pipeline before use.
+rationale: >-
+  To ensure that a dependency used in a pipeline is trusted and has not been infected by 
+  malicious actor (for example, the codecov incident), validate dependencies before using 
+  them. This can be accomplished by comparing the checksum of the dependency to its 
+  checksum in a trusted source. If a difference arises, this is a sign that an unknown actor 
+  has interfered and may have added malevolent code. If this dependency is used, it will 
+  infect the environment, which could end in a massive breach and leave the organization 
+  exposed to data leaks, etc.
+impact: >-
+audit: |
+  For every dependency used in every pipeline, ensure it has been validated.
+    • On the left sidebar, select Code > Repository.
+    • Check if a .gitlab-ci.yml file is at the root of your repository
+    • Verify the following job is included in your .gitlab-ci.yml file:
+      include:
+        - template: Jobs/Dependency-Scanning.gitlab-ci.yml
+    • Go to Build > Pipelines and confirm that the latest pipeline completed successfully.
+remediation: >-
+  For every dependency used in every pipeline, validate each one.
+    • On the left sidebar, select Code > Repository.
+    • Check if a .gitlab-ci.yml file is at the root of your repository
+    • Include the following job is included in your .gitlab-ci.yml file:
+      include:
+        - template: Jobs/Dependency-Scanning.gitlab-ci.yml
+    • Go to Build > Pipelines and confirm that the latest pipeline completed successfully. In the pipeline, dependency scanning runs and the vulnerabilities are detected automatically.
+    • Go to Secure > Vulnerability report.
+    • Select each of the vulnerabilities by selecting the checkbox in each row.
+    • Review the recommended solution for each vulnerability and investigate further if needed.
+    • From the Set status dropdown list select the relevant option and select Change status.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/tutorials/dependency_scanning.html
+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/readme.md

@@ -0,0 +1,12 @@
+# 2 Build Pipelines
+
+This section consists of security recommendations for the management of application build pipelines developed by an organization.
+
+Build pipelines are a set of instructions dedicated to taking raw files of source code and running a series of tasks on them to achieve some final artifact as output. This artifact represents the final form of the recent version of software, which is subsequently packaged for convenient storing, handling, and deploying. Build pipelines are a general name for the environment in which this compilation process takes place, the pipeline files that orchestrate the process, and all sets of instructions related to them.
+
+## Sections
+
+- [2.1 - Build Environment](./build_environment_2_1)
+- [2.2 - Build Worker](./build_worker_2_2)
+- [2.3 - Pipeline Instructions](./pipeline_instructions_2_3)
+- [2.4 - Pipeline Integrity](./pipeline_integrity_2_4)

gitlabcis/recommendations/dependencies_3/readme.md

@@ -0,0 +1,10 @@
+# 3 Dependencies
+
+This section consists of security recommendations for the management of various dependencies introduced as part of the software build and release process. These are comprised of anything that goes into application code or is used by build pipelines themselves.
+
+Dependencies are a huge part of the software supply chain, as they are integrated in a lot of important phases. They are often written by third-party developers and might be vulnerable to certain attacks, for example the log4j attack. Because of that it is particularly important to secure them and their use in the supply chain.
+
+## Sections
+
+- [3.1 - Third-Party Packages](./third_party_packages_3_1/)
+- [3.2 - Validate Packages](./validate_packages_3_2/)

gitlabcis/recommendations/dependencies_3/third_party_packages_3_1/define_package_managers.yml

@@ -0,0 +1,84 @@
+---
+id: 3.1.5
+name: define_package_managers
+title: Ensure trusted package managers and repositories are defined and prioritized
+profile: 1
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  Prioritize trusted package registries over others when pulling a package.
+rationale: >-
+  When pulling a package by name, the package manager might look for it in several 
+  package registries, some of which may be untrusted or badly configured. If the package 
+  is pulled from such a registry, there is a higher likelihood that it could prove malicious. In 
+  order to avoid this, configure packages to be pulled from trusted package registries.
+impact: >-
+audit: >-
+  For each package registry in use, ensure it is trusted. The GitLab package registry is 
+  enabled by default.
+remediation: >-
+  For each package to be downloaded, configure it to be downloaded from a trusted 
+  source. To view your GitLab package registry and its contents, click on "Deploy" --> 
+  "Package Registry."
+default_value:
+references:
+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: 8
+    name: Allowlist Authorized Scripts
+    description: >-
+      Use technical controls, such as digital signatures and version control, to ensure 
+      that only authorized scripts, such as specific .ps1, .py, etc., files, are allowed to 
+      execute. Block unauthorized scripts from executing. Reassess bi-annually, or more 
+      frequently.
+    implementation_groups:
+      - 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
+  - id: 2.9
+    version: 7
+    name: Implement Application Whitelisting of Scripts
+    description: >-
+      The organization's application whitelisting software must ensure that only 
+      authorized, digitally signed scripts (such as *.ps1, *.py, macros, etc) are allowed to 
+      run on a system.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/dependencies_3/third_party_packages_3_1/dependency_sbom.yml

@@ -0,0 +1,84 @@
+---
+id: 3.1.6
+name: dependency_sbom
+title: Ensure a signed Software Bill of Materials (SBOM) of the code is supplied
+profile: 1
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  A Software Bill of Materials (SBOM) is a file that specifies each component of software 
+  or a build process. When using a dependency, demand its SBOM and ensure it is 
+  signed for validation purposes.
+rationale: >-
+  A Software Bill of Materials (SBOM) creates trust between its provider and its users by 
+  ensuring that the software supplied is the software described, without any potential 
+  interference in between. Signing an SBOM creates a checksum for it, which will change 
+  if the SBOM's content was changed. With that checksum, a software user can be 
+  certain nothing had happened to it during the supply chain, engendering trust in the 
+  software. When there is no such trust in the software, the risk surface is increased 
+  because one cannot know if the software is potentially vulnerable. Demanding a signed 
+  SBOM and validating it decreases that risk.
+impact: >-
+audit: >-
+  For every artifact supplied, ensure it has a validated, signed Software Bill of Materials. 
+  To view the SBOMs associated with your projects, Navigate to 
+  Secure --> Dependency list 
+  You may export the SBOM in .json format
+remediation: |
+  For every artifact supplied, require and verify a signed Software Bill of Materials from its supplier.
+    1. To create an SBOM, you must run a dependency scan.
+    2. Enable dependency scanning, and an SBOM will be automatically generated for your project.
+default_value:
+references:
+cis_controls:
+  - id: 2.1
+    version: 8
+    name: Establish and Maintain a Software Inventory
+    description: >-
+      Establish and maintain a detailed inventory of all licensed software installed on 
+      enterprise assets. The software inventory must document the title, publisher, initial 
+      install/use date, and business purpose for each entry; where appropriate, include 
+      the Uniform Resource Locator (URL), app store(s), version(s), deployment 
+      mechanism, and decommission date. Review and update the software inventory bi-
+      annually, or more frequently.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 2.2
+    version: 8
+    name: Ensure Authorized Software is Currently Supported
+    description: >-
+      Ensure that only currently supported software is designated as authorized in the 
+      software inventory for enterprise assets. If software is unsupported, yet necessary 
+      for the fulfillment of the enterprise's mission, document an exception detailing 
+      mitigating controls and residual risk acceptance. For any unsupported software 
+      without an exception documentation, designate as unauthorized. Review the 
+      software list to verify software support at least monthly, or more frequently.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 2.1
+    version: 7
+    name: Maintain Inventory of Authorized Software
+    description: >-
+      Maintain an up-to-date list of all authorized software that is required in the 
+      enterprise for any business purpose on any business system.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 2.2
+    version: 7
+    name: Ensure Software is Supported by Vendor
+    description: >-
+      Ensure that only software applications or operating systems currently supported 
+      by the software's vendor are added to the organization's authorized software 
+      inventory. Unsupported software should be tagged as unsupported in the inventory 
+      system.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/dependencies_3/third_party_packages_3_1/monitor_dependencies.yml

@@ -0,0 +1,61 @@
+---
+id: 3.1.4
+name: monitor_dependencies
+title: Ensure dependencies are monitored between open-source components
+profile: 1
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  Monitor, or ask software suppliers to monitor, dependencies between open-source components in use.
+rationale: >-
+  Monitoring dependencies between open-source components helps to detect if software 
+  has fallen victim to attack on a common open-source component. Swift detection can 
+  aid in quick application of a fix. It also helps find potential compliance problems with 
+  components usage. Some dependencies might not be compatible with the 
+  organization's policies, and other dependencies might have a license that is not 
+  compatible with how the organization uses this specific dependency. If dependencies 
+  are monitored, such situations can be detected and mitigated sooner, potentially 
+  deterring malicious attacks.
+impact: >-
+audit: |
+  For each project, ensure that dependency scanning and container scanning are enabled in order to monitor dependencies.
+    1. On GitLab, navigate to the main page of the repository.
+    2. Review the CI pipeline configuration to verify that Dependency Scanning and that Container Scanning have been configured to run on this project.
+remediation: |
+  For every repository that is in use, set a dependency scanning and container scanning tools to detect, prevent, and monitor vulnerabilities in project packages and container images by performing the following:
+    1. On GitLab, navigate to the main page of the repository.
+    2. Configure Dependency Scanning and Container Scanning to run on this project
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration
+  - https://docs.gitlab.com/ee/user/application_security/container_scanning/#configuration
+cis_controls:
+  - id: 2.4
+    version: 8
+    name: Utilize Automated Software Inventory Tools
+    description: >-
+      Utilize software inventory tools, when possible, throughout the enterprise to 
+      automate the discovery and documentation of installed software.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.3
+    version: 7
+    name: Utilize Software Inventory Tools
+    description: >-
+      Utilize software inventory tools throughout the organization to automate the 
+      documentation of all software on business systems.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.4
+    version: 7
+    name: Track Software Inventory Information
+    description: >-
+      The software inventory system should track the name, version, publisher, and 
+      install date for all software, including operating systems authorized by the 
+      organization.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/dependencies_3/third_party_packages_3_1/packages_over_60_days_old.yml

@@ -0,0 +1,95 @@
+---
+id: 3.1.8
+name: packages_over_60_days_old
+title: Ensure all packages used are more than 60 days old
+profile: 2
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  Use packages that are more than 60 days old.
+rationale: >-
+  Third-party packages are a major risk since an organization cannot control their source 
+  code, and there is always the possibility these packages could be malicious. It is 
+  therefore good practice to remain cautious with any third-party or open-source package, 
+  especially new ones, until they can be verified that they are safe to use. Avoiding a new 
+  package allows the organization to fully examine it, its maintainer, and its behavior, and 
+  gives enough time to determine whether or not to use it.
+impact: >-
+  Developers may not use packages that are less than 60 days old.
+audit: >-
+  For every package used, ensure it is more than 60 days old.
+remediation: >-
+  If a package used is less than 60 days old, stop using it and find another solution.
+default_value:
+references:
+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: 8
+    name: Allowlist Authorized Scripts
+    description: >-
+      Use technical controls, such as digital signatures and version control, to ensure 
+      that only authorized scripts, such as specific .ps1, .py, etc., files, are allowed to 
+      execute. Block unauthorized scripts from executing. Reassess bi-annually, or more 
+      frequently.
+    implementation_groups:
+      - IG3
+  - 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: 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
+  - id: 2.9
+    version: 7
+    name: Implement Application Whitelisting of Scripts
+    description: >-
+      The organization's application whitelisting software must ensure that only 
+      authorized, digitally signed scripts (such as *.ps1, *.py, macros, etc) are allowed to 
+      run on a system.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/dependencies_3/third_party_packages_3_1/pin_dependency_version.yml

@@ -0,0 +1,48 @@
+---
+id: 3.1.7
+name: pin_dependency_version
+title: Ensure dependencies are pinned to a specific, verified version
+profile: 1
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  Pin dependencies to a specific version. Avoid using the "latest" tag or broad version.
+rationale: >-
+  When using a wildcard version of a package, or the "latest" tag, the risk of encountering 
+  a new, potentially malicious package increases. The "latest" tag pulls the last package 
+  pushed to the registry. This means that if an attacker pushes a new, malicious package 
+  successfully to the registry, the next user who pulls the "latest" will pull it and risk attack. 
+  This same rule applies to a wildcard version - assuming one is using version v1.*, it will 
+  install the latest version of the major version 1, meaning that if an attacker can push a 
+  malicious package with that same version, those using it will be subject to possible 
+  attack. By using a secure, verified version, use is restricted to this version only and no 
+  other may be pulled, decreasing the risk for any malicious package.
+impact: >-
+audit: >-
+  For every dependency in use, ensure it is pinned to a specific version.
+remediation: >-
+  For every dependency in use, pin to a specific version.
+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/dependencies_3/third_party_packages_3_1/readme.md

@@ -0,0 +1,14 @@
+# 3.1 Third-Party Packages
+
+This section consists of security recommendations for the use and management of third-party dependencies and packages. As a consumer of various third-party packages, you need to ensure certain conditions exist to trust them and use them safely. Using third-party packages affects not only the software, but also its costumers, so it is important to carefully examine each one of these packages.
+
+## Recommendations
+
+* [3.1.1 - verify_artifacts.yml](./verify_artifacts.yml)
+* [3.1.2 - third_party_sbom_required.yml](./third_party_sbom_required.yml)
+* [3.1.3 - verify_signed_metadata.yml](./verify_signed_metadata.yml)
+* [3.1.4 - monitor_dependencies.yml](./monitor_dependencies.yml)
+* [3.1.5 - define_package_managers.yml](./define_package_managers.yml)
+* [3.1.6 - dependency_sbom.yml](./dependency_sbom.yml)
+* [3.1.7 - pin_dependency_version.yml](./pin_dependency_version.yml)
+* [3.1.8 - packages_over_60_days_old.yml](./packages_over_60_days_old.yml)

gitlabcis/recommendations/dependencies_3/third_party_packages_3_1/third_party_sbom_required.yml

@@ -0,0 +1,70 @@
+---
+id: 3.1.2
+name: third_party_sbom_required
+title: Ensure Software Bill of Materials (SBOM) is required from all third-party suppliers
+profile: 1
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  A Software Bill Of Materials (SBOM) is a file that specifies each component of software 
+  or a build process. Require an SBOM from every third-party provider.
+rationale: >-
+  A Software Bill of Materials (SBOM) for every third-party artifact helps to ensure an 
+  artifact is safe to use and fully compliant. This file lists all important metadata, especially 
+  all the dependencies of an artifact, and allows for verification of each dependency. If 
+  one of the dependencies/artifacts are attacked or has a new vulnerability (for example, 
+  the "SolarWinds" or even "log4j" attacks), it is easier to detect what has been affected 
+  by this incident because dependencies in use are listed in the SBOM file.
+impact: >-
+audit: >-
+  For every third-party dependency in use, ensure it has a Software Bill of Materials.
+remediation: >-
+  For every third-party dependency in use, require a Software Bill of Materials from its supplier.
+default_value:
+references:
+cis_controls:
+  - id: 2.1
+    version: 8
+    name: Establish and Maintain a Software Inventory
+    description: >-
+      Establish and maintain a detailed inventory of all licensed software installed on 
+      enterprise assets. The software inventory must document the title, publisher, initial 
+      install/use date, and business purpose for each entry; where appropriate, include 
+      the Uniform Resource Locator (URL), app store(s), version(s), deployment 
+      mechanism, and decommission date. Review and update the software inventory bi-
+      annually, or more frequently.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - 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: 2.4
+    version: 7
+    name: Track Software Inventory Information
+    description: >-
+      The software inventory system should track the name, version, publisher, and 
+      install date for all software, including operating systems authorized by the 
+      organization.
+    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/dependencies_3/third_party_packages_3_1/verify_artifacts.yml

@@ -0,0 +1,45 @@
+---
+id: 3.1.1
+name: verify_artifacts
+title: Ensure third-party artifacts and open-source libraries are verified
+profile: 1
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  Ensure third-party artifacts and open-source libraries in use are trusted and verified.
+rationale: >-
+  Verify third-party artifacts used in code are trusted and have not been infected by a 
+  malicious actor before use. This can be accomplished, for example, by comparing the 
+  checksum of the dependency to its checksum in a trusted source. If a difference arises, 
+  this may be a sign that someone interfered and added malicious code. If this 
+  dependency is used, it will infect the environment and could end in a massive breach, 
+  leaving the organization exposed to data leaks and more.
+impact: >-
+audit: >-
+  Ensure third-party artifacts and open-source libraries are verified.
+remediation: >-
+  Set third-party artifacts and open-source libraries to be verified.
+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: >-