gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/artifacts_4/access_to_artifacts_4_2/external_auth_server.yml

@@ -0,0 +1,51 @@
+---
+id: 4.2.4
+name: external_auth_server
+title: Ensure user management of the package registry is not local
+profile: 1
+category: artifacts
+sub_category: access_to_artifacts
+description: >-
+  Manage users and their access to the package registry with an external authentication 
+  server and not with the package registry itself.
+rationale: >-
+  Some package registries offer a tool for user management, aside from the main 
+  Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server of the 
+  organization. That tool usually offers simple authentication and role-based permissions, 
+  which might not be granular enough. Having multiple user management tools in the 
+  organization could result in confusion and privilege escalation, as there will be more to 
+  manage. To avoid a situation where users escalate their privileges because someone 
+  missed them, manage user access to the package registry via the main authentication 
+  server and not locally on the package registry.
+impact: >-
+audit: >-
+  For each package registry, verify that its user access is not managed locally, but instead 
+  with the main authentication server of the organization.
+remediation: >-
+  For each package registry, use the main authentication server of the organization for 
+  user management and do not manage locally.
+default_value:
+references:
+cis_controls:
+  - id: 3.3
+    version: 8
+    name: Configure Data Access Control Lists
+    description: >-
+      Configure data access control lists based on a user's need to know. Apply data 
+      access control lists, also known as access permissions, to local and remote file 
+      systems, databases, and applications.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 14.6
+    version: 7
+    name: Protect Information through Access Control Lists
+    description: >-
+      Protect all information stored on systems with file system, network share, 
+      claims, application, or database specific access control lists. These controls will 
+      enforce the principle that only authorized individuals should have access to the 
+      information based on their need to access the information as a part of their 
+      responsibilities.
+    implementation_groups:
+additional_info: >-

gitlabcis/recommendations/artifacts_4/access_to_artifacts_4_2/limit_artifact_uploaders.yml

@@ -0,0 +1,57 @@
+---
+id: 4.2.2
+name: limit_artifact_uploaders
+title: Ensure number of permitted users who may upload new artifacts is minimized
+profile: 1
+category: artifacts
+sub_category: access_to_artifacts
+description: >-
+  Minimize ability to upload artifacts to the lowest number of trusted users possible.
+rationale: >-
+  Artifacts might contain sensitive data. Even the simplest mistake can also lead to trust 
+  issues with customers and harm the integrity of the product. To decrease these risks, 
+  allow only trusted and qualified users to upload new artifacts. Those users are less 
+  likely to make mistakes. Having the lowest number of such users possible will also 
+  decrease the risk of hacked user accounts, which could lead to a massive breach or 
+  artifact compromising.
+impact: >-
+audit: |
+  Ensure only trusted and qualified users can upload new artifacts, and that their number is the lowest possible.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • If there are minimum number of members with Owner/Maintainer role in the list, you are compliant.
+remediation: |
+  Allow only trusted and qualified users to upload new artifacts and limit them in number.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • Next to the project member you want to remove, select Remove member.
+default_value:
+references:
+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/artifacts_4/access_to_artifacts_4_2/limit_certifying_artifacts.yml

@@ -0,0 +1,53 @@
+---
+id: 4.2.1
+name: limit_certifying_artifacts
+title: Ensure the authority to certify artifacts is limited
+profile: 1
+category: artifacts
+sub_category: access_to_artifacts
+description: >-
+  Software certification is used to verify the safety of certain software usage and to 
+  establish trust between the supplier and the consumer. Any artifact can be certified. 
+  Limit the authority to certify different artifacts.
+rationale: >-
+  Artifact certification is a powerful tool in establishing trust. Clients use a software 
+  certificate to verify that the artifact is safe to use according to their security policies. 
+  Because of this, certifying artifacts is considered sensitive. If an artifact is for debugging 
+  or internal use, or if it were compromised, the organization would not want certification. 
+  An attacker gaining access to both certificate authority and the artifact registry might 
+  also be able to certify its own artifact and cause a major breach. To prevent these 
+  issues, limit which artifacts can be certified by which platform so there will be minimal 
+  access to certification.
+impact: >-
+audit: >-
+  Ensure only certain artifacts can be certified by certain parties.
+remediation: >-
+  Limit which artifact can be certified by which authority.
+default_value:
+references:
+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/artifacts_4/access_to_artifacts_4_2/minimum_package_registry_admins.yml

@@ -0,0 +1,54 @@
+---
+id: 4.2.6
+name: minimum_package_registry_admins
+title: Ensure minimum number of administrators are set for the package registry
+profile: 1
+category: artifacts
+sub_category: access_to_artifacts
+description: >-
+  Ensure the package registry has a minimum number of administrators.
+rationale: >-
+  Package registry admins have the ability to add/remove users, repositories, packages. 
+  Due to the permissive access granted to an admin, it is highly recommended to keep 
+  the number of administrator accounts as minimal as possible.
+impact: >-
+  Administrator privileges are required to provide and maintain a secure and stable 
+  platform but allowing extraneous administrator accounts can create a vulnerability.
+audit: >-
+  Verify that your package registry has only the minimum number of administrators. For 
+  each project that you administer on GitLab, you can see every team or person with 
+  access to the project. Project-level permissions determine actions such as downloading, 
+  pushing, or deleting packages.
+remediation: >-
+  Set the minimum number of administrators in your package registry. To accomplish this: 
+  For each project that you administer on GitLab, you can see an overview of every team 
+  or person with access to the repository. Provide access to the appropriate people or 
+  teams.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/packages/package_registry
+cis_controls:
+  - id: 5.4
+    version: 8
+    name: Restrict Administrator Privileges to Dedicated Administrator Accounts
+    description: >-
+      Restrict administrator privileges to dedicated administrator accounts on 
+      enterprise assets. Conduct general computing activities, such as internet 
+      browsing, email, and productivity suite use, from the user's primary, non-privileged 
+      account.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 4.3
+    version: 7
+    name: Ensure the Use of Dedicated Administrative Accounts
+    description: >-
+      Ensure that all users with administrative account access use a dedicated or 
+      secondary account for elevated activities. This account should only be used for 
+      administrative activities and not internet browsing, email, or similar activities.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/artifacts_4/access_to_artifacts_4_2/readme.md

@@ -0,0 +1,14 @@
+# 4.2 Access to Artifacts
+
+This section consists of security recommendations for access management of artifacts.
+
+Artifacts are often stored in registries, some external and some internal. Those registries have user entities that control access and permissions. Artifacts are considered sensitive, because they are being delivered to the costumer, and are prune to many attacks: data theft, dependency confusion, malicious packages and more. That's why their access management should be restrictive and careful.
+
+## Recommendations
+
+* [4.2.1 - limit_certifying_artifacts.yml](./limit_certifying_artifacts.yml)
+* [4.2.2 - limit_artifact_uploaders.yml](./limit_artifact_uploaders.yml)
+* [4.2.3 - require_mfa_to_package_registry.yml](./require_mfa_to_package_registry.yml)
+* [4.2.4 - external_auth_server.yml](./external_auth_server.yml)
+* [4.2.5 - restrict_anonymous_access.yml](./restrict_anonymous_access.yml)
+* [4.2.6 - minimum_package_registry_admins.yml](./minimum_package_registry_admins.yml)

gitlabcis/recommendations/artifacts_4/access_to_artifacts_4_2/require_mfa_to_package_registry.yml

@@ -0,0 +1,52 @@
+---
+id: 4.2.3
+name: require_mfa_to_package_registry
+title: Ensure user access to the package registry utilizes Multi-Factor Authentication (MFA)
+profile: 2
+category: artifacts
+sub_category: access_to_artifacts
+description: >-
+  Enforce Multi-Factor Authentication (MFA) for user access to the package registry.
+rationale: >-
+  By default, every user authenticates to the system by password only. If a user's 
+  password is compromised, the user account and all its related packages are in danger 
+  of data theft and malicious builds. It is therefore recommended that each user enables 
+  Multi-Factor Authentication. This additional step guarantees that the account stays 
+  secure even if the user's password is compromised, as it adds another layer of 
+  authentication.
+impact: >-
+audit: |
+  For each package registry in use, verify that Multi-Factor Authentication is enforced and is the only way to authenticate.
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Settings > General.
+    • Expand Sign-in restrictions:
+    • Check if Enforce two-factor authentication is enabled. If so, you are compliant.
+remediation: |
+  For each package registry in use, enforce Multi-Factor Authentication as the only way to authenticate.
+    • On the left sidebar, at the bottom, select Admin Area.
+    • Select Settings > General.
+    • Expand Sign-in restrictions:
+    • Select Enforce two-factor authentication to enable this feature.
+default_value:
+references:
+cis_controls:
+  - id: 6.3
+    version: 8
+    name: Require MFA for Externally-Exposed Applications
+    description: >-
+      Require all externally-exposed enterprise or third-party applications to enforce 
+      MFA, where supported. Enforcing MFA through a directory service or SSO 
+      provider is a satisfactory implementation of this Safeguard.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 4.5
+    version: 7
+    name: Use Multifactor Authentication For All Administrative Access
+    description: >-
+      Use multi-factor authentication and encrypted channels for all administrative 
+      account access.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/artifacts_4/access_to_artifacts_4_2/restrict_anonymous_access.yml

@@ -0,0 +1,67 @@
+---
+id: 4.2.5
+name: restrict_anonymous_access
+title: Ensure anonymous access to artifacts is revoked
+profile: 1
+category: artifacts
+sub_category: access_to_artifacts
+description: >-
+  For GitLab projets anonymous access is not available. 
+  Verify that all that require access controls are Private or Internal.
+rationale: >-
+  Disable the option to view artifacts as an anonymous user in order to protect private 
+  artifacts from being exposed.
+impact: >-
+  Only logged and authorized users will be able to access artifacts.
+audit: |
+  Reviewing a project's visibility for artifacts:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Settings > General.
+    • Expand Visibility, project features, permissions.
+    • From the Project visibility dropdown list, review the current selection.
+remediation: |
+  Changing a project's visibility for artifacts:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Settings > General.
+    • Expand Visibility, project features, permissions.
+    • From the Project visibility dropdown list, select an option. The visibility setting for a project must be at least as restrictive as the visibility of its parent group.
+    • Select Save changes.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/public_access.html
+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: 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/artifacts_4/origin_traceability_4_4/artifact_origin_info.yml

@@ -0,0 +1,56 @@
+---
+id: 4.4.1
+name: artifact_origin_info
+title: Ensure artifacts contain information about their origin
+profile: 1
+category: artifacts
+sub_category: origin_traceability
+description: >-
+  When delivering artifacts, ensure they have information about their origin. This may be 
+  done by providing a Software Bill of Manufacture (SBOM) or some metadata files.
+rationale: >-
+  Information about artifact origin can be used for verification purposes. Having this kind 
+  of information allows the user to decide if the organization supplying the artifact is 
+  trusted. In a case of potential vulnerability or version update, this can be used to verify 
+  that the organization issuing it is the actual origin and not someone else. If users need 
+  to report problems with the artifact, they will have an address to contact as well.
+impact: >-
+audit: >-
+  For each artifact, ensure it has information about its origin.
+remediation: >-
+  For each artifact supplied, supply information about its origin. For each artifact in use, 
+  ask for information about its origin.
+default_value:
+references:
+cis_controls:
+  - id: 1.1
+    version: 8
+    name: Establish and Maintain Detailed Enterprise Asset Inventory
+    description: >-
+      Establish and maintain an accurate, detailed, and up-to-date inventory of all 
+      enterprise assets with the potential to store or process data, to include: end-user 
+      devices (including portable and mobile), network devices, non-computing/IoT 
+      devices, and servers. Ensure the inventory records the network address (if static), 
+      hardware address, machine name, enterprise asset owner, department for each 
+      asset, and whether the asset has been approved to connect to the network. For 
+      mobile end-user devices, MDM type tools can support this process, where 
+      appropriate. This inventory includes assets connected to the infrastructure 
+      physically, virtually, remotely, and those within cloud environments. Additionally, it 
+      includes assets that are regularly connected to the enterprise's etwork 
+      infrastructure, even if they are not under control of the enterprise. Review and 
+      update the inventory of all enterprise assets bi-annually, or more frequently.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 1.5
+    version: 7
+    name: Maintain Asset Inventory Information
+    description: >-
+      Ensure that the hardware asset inventory records the network address, hardware 
+      address, machine name, data asset owner, and department for each asset and 
+      whether the hardware asset has been approved to connect to the network.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/artifacts_4/origin_traceability_4_4/readme.md

@@ -0,0 +1,7 @@
+# 4.4 Origin Traceability
+
+This section consists of security recommendations for managing the traceability of artifacts. This means ensuring that both the organization and its customers know where this artifact came from, for example with an SBOM (Software Bill Of Materials), and also verifying that it came from the registry it was supposed.
+
+## Recommendations
+
+* [4.4.1 - artifact_origin_info.yml](./artifact_origin_info.yml)

gitlabcis/recommendations/artifacts_4/package_registries_4_3/all_artifact_versions_signed.yml

@@ -0,0 +1,70 @@
+---
+id: 4.3.2
+name: all_artifact_versions_signed
+title: Ensure all versions of an existing artifact have their signatures validated
+profile: 1
+category: artifacts
+sub_category: package_registries
+description: >-
+  Validate the signature of all versions of an existing artifact.
+rationale: >-
+  In order to be certain a version of an existing and trusted artifact is not malicious or 
+  delivered by someone looking to interfere with the supply chain, it is a good practice to 
+  validate the signatures of each version. Doing so decreases the risk of using a 
+  compromised artifact, which might lead to a breach.
+impact: >-
+audit: |
+  For each artifact, ensure that all of its versions are signed and validated before it is uploaded or used.
+  Ensure every artifact in the package registry has been validated with its signature.
+  1. On the left sidebar, select Search or go to and find your project.
+    • To review commits for a project, select Code > Commits.
+    • To review commits for a merge request, select Code > Merge requests, then select your merge request.
+  2. Select Commits.
+  3. Identify the commit you want to review. Signed commits show either a Verified or Unverified badge, depending on the verification status of the signature. Unsigned commits do not display a badge.
+remediation: >-
+  For each artifact, sign and validate each version before uploading or using the artifact.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/repository/signed_commits/
+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
+  - 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/artifacts_4/package_registries_4_3/audit_package_registry_config.yml

@@ -0,0 +1,46 @@
+---
+id: 4.3.3
+name: audit_package_registry_config
+title: Ensure changes in package registry configuration are audited
+profile: 1
+category: artifacts
+sub_category: package_registries
+description: >-
+  Audit changes of the package registry configuration.
+rationale: >-
+  The package registry is a crucial component in the software supply chain. It stores 
+  artifacts with potentially sensitive data that will eventually be deployed and used in 
+  production. Every change made to the package registry configuration must be examined 
+  carefully to ensure no exposure of the registry's sensitive data. This examination also 
+  ensures no malicious actors have performed modifications to a stored artifact. Auditing 
+  the configuration and its changes helps in decreasing such risks.
+impact: >-
+audit: >-
+  Verify that all changes to the packages registry configuration are audited.
+remediation: >-
+  Audit the changes to the package registry configuration.
+default_value: GitHub audits this by default.
+references:
+  - https://docs.gitlab.com/ee/administration/audit_event_types.html
+cis_controls:
+  - id: 8.5
+    version: 8
+    name: Collect Detailed Audit Logs
+    description: >-
+      Configure detailed audit logging for enterprise assets containing sensitive data. 
+      Include event source, date, username, timestamp, source addresses, destination 
+      addresses, and other useful elements that could assist in a forensic investigation.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 6.3
+    version: 7
+    name: Enable Detailed Logging
+    description: >-
+      Enable system logging to include detailed information such as an event source, 
+      date, user, timestamp, source addresses, destination addresses, and other useful 
+      elements.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/artifacts_4/package_registries_4_3/readme.md

@@ -0,0 +1,12 @@
+# 4.3 Package Registries
+
+This section consists of security recommendations for management of package registries and artifacts that are stored in them.
+
+Package registries are where the organization artifacts are stored. To keep an artifact safe, you must keep the registry where it is stored safe too. furthermore, you need to ensure that every artifact that reaches the registry is safe to use and doesn't put the registry in danger.
+
+## Recommendations
+
+* [4.3.1 - validate_signed_artifacts_on_upload.yml](./validate_signed_artifacts_on_upload.yml)
+* [4.3.2 - all_artifact_versions_signed.yml](./all_artifact_versions_signed.yml)
+* [4.3.3 - audit_package_registry_config.yml](./audit_package_registry_config.yml)
+* [4.3.4 - secure_repo_webhooks.yml](./secure_repo_webhooks.yml)

gitlabcis/recommendations/artifacts_4/package_registries_4_3/secure_repo_webhooks.yml

@@ -0,0 +1,50 @@
+---
+id: 4.3.4
+name: secure_repo_webhooks
+title: Ensure webhooks of the repository are secured
+profile: 1
+category: artifacts
+sub_category: package_registries
+description: >-
+  Use secured webhooks to reduce the possibility of malicious payloads.
+rationale: >-
+  Webhooks are used for triggering an HTTP request based on an action made in the 
+  platform. Typically, package registries feature webhooks when a package receives an 
+  update. 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 registry or web server excepting the request, use only secured webhooks.
+impact: >-
+  Reduces the payloads that the web hook can listen for and receive.
+audit: >-
+remediation: >-
+  For each webhook in use, change it to secured (over HTTPS).
+default_value:
+references:
+cis_controls:
+  - id: 3.10
+    version: 8
+    name: Encrypt Sensitive Data in Transit
+    description: >-
+      Encrypt sensitive data in transit. Example implementations can include: 
+      Transport Layer Security (TLS) and Open Secure Shell (OpenSSH).
+    implementation_groups:
+      - IG2
+      - IG3
+  - 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
+  - id: 14.4
+    version: 7
+    name: Encrypt All Sensitive Information in Transit
+    description: >-
+      Encrypt all sensitive information in transit.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/artifacts_4/package_registries_4_3/validate_signed_artifacts_on_upload.yml

@@ -0,0 +1,72 @@
+---
+id: 4.3.1
+name: validate_signed_artifacts_on_upload
+title: Ensure all signed artifacts are validated upon uploading the package registry
+profile: 1
+category: artifacts
+sub_category: package_registries
+description: >-
+  Validate artifact signatures before uploading to the package registry.
+rationale: >-
+  Cryptographic signature is a tool to verify artifact authenticity. Every artifact is supposed 
+  to be signed by its creator in order to confirm that it was not compromised before 
+  reaching the client. Validating an artifact signature before delivering it is another level of 
+  protection which ensures the signature has not been changed, meaning no one tried or 
+  succeeded in tampering with the artifact. This creates trust between the supplier and the 
+  client.
+impact: >-
+audit: |
+  Ensure every artifact in the package registry has been validated with its signature.
+  1. On the left sidebar, select Search or go to and find your project.
+    • To review commits for a project, select Code > Commits.
+    • To review commits for a merge request, select Code > Merge requests, then select your merge request.
+  2. Select Commits.
+  3. Identify the commit you want to review. Signed commits show either a Verified or Unverified badge, depending on the verification status of the signature. Unsigned commits do not display a badge.
+remediation: >-
+  Validate every artifact with its signature before uploading it to the package registry. It is 
+  recommended to do so automatically.
+default_value: Artifacts are not scanned by default.
+references:
+  - https://docs.gitlab.com/ee/user/project/repository/signed_commits/
+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
+  - 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: >-