gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/source_code_1/code_changes_1_1/code_approvals.yml

@@ -0,0 +1,65 @@
+---
+id: 1.1.3
+name: code_approvals
+title: Ensure any change to code receives approval of two strongly authenticated users
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure that every code change is reviewed and approved by two authorized 
+  contributors who are both strongly authenticated - using Multi-Factor Authentication 
+  (MFA), from the team relevant to the code change.
+rationale: >-
+  To prevent malicious or unauthorized code changes, the first layer of protection is the 
+  process of code review. This process involves engineer teammates reviewing each 
+  other's code for errors, optimizations, and general knowledge-sharing. With proper peer 
+  reviews in place, an organization can detect unwanted code changes very early in the 
+  process of release. In order to help facilitate code review, companies should employ 
+  automation to verify that every code change has been reviewed and approved by at 
+  least two team members before it is pushed into the code base. These team members 
+  should be from the team that is related to the code change, so it will be a meaningful 
+  review.
+impact: >-
+  To enforce a code review requirement, verification for a minimum of two reviewers must
+  be put into place. This will ensure new code will not be able to be pushed to the code
+  base before it has received two independent approvals.
+audit: |
+  For every project in use, perform the next steps to verify that two approvals from the specific project team are required to push new code to the code base:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Settings > Merge requests.
+    • In the Merge request approvals section, in the Approval rules section, next to the rule you want to edit, select Edit.
+    • Review the field In Approvals required, if the number is 2 or above, you are compliant.
+remediation: |
+  For every project in use, perform the next steps to require two approvals from the specific project team in order to push new code to the code base:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Settings > Merge requests.
+    • In the Merge request approvals section, in the Approval rules section, next to the rule you want to edit, select Edit.
+    • Edit the field In Approvals required to ensure the value is 2 or above.
+    • Select Update approval rule.
+default_value: 0
+references:
+  - https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-an-approval-rule
+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/source_code_1/code_changes_1_1/code_changes_require_code_owners.yml

@@ -0,0 +1,68 @@
+---
+id: 1.1.7
+name: code_changes_require_code_owners
+title: Ensure code owner's review is required when a change affects owned code
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure trusted code owners are required to review and approve any code change 
+  proposal made to their respective owned areas in the code base.
+rationale: >-
+  Configuring code owners ensures that no code, especially code which could prove 
+  malicious, will slip into the source code or configuration files of a repository. This allows 
+  an organization to mark areas in the code base that are especially sensitive or more 
+  prone to an attack. It can also enforce review by specific individuals who are designated 
+  as owners to those areas so that they may filter out unauthorized or unwanted changes 
+  beforehand.
+impact: >-
+  If an organization enforces code owner-based reviews, some code change proposals 
+  would not be able to be merged to the codebase before specific, trusted individuals 
+  approve them.
+audit: |
+  With merge request approval rules, you can set the minimum number of required approvals by code owners before work can merge into your project.
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Repository.
+    3. Expand Protected branches.
+    4. Next to the default branch, turn on the toggle under Code owner approval.
+remediation: |
+  Prerequisites:
+    • You must have at least the Maintainer role for the project.
+    • To add a group as an approver in GitLab.com, you must be a member of the group or the group must be public.
+  To add a merge request approval rule:
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Merge requests.
+    3. In the Merge request approvals section, in the Approval rules section, select Add approval rule.
+    4. Complete the fields:
+      • In Approvals required, a value of 0 makes the rule optional, and any number greater than 0 creates a required rule. Maximum number of required approvals is 100.
+      • From Add approvers, select users or groups that are eligible to approve. GitLab suggests approvers based on previous authors of the files changed by the merge request.
+    5. Select Add approval rule. You can add multiple approval rules.
+default_value: Code owners are not required to review changes by default.
+references:
+  - https://docs.gitlab.com/ee/user/project/merge_requests/approvals/
+  - https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html
+  - https://docs.gitlab.com/ee/user/project/codeowners/index.html
+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/source_code_1/code_changes_1_1/code_dismissal_restrictions.yml

@@ -0,0 +1,69 @@
+---
+id: 1.1.5
+name: code_dismissal_restrictions
+title: Ensure there are restrictions on who can dismiss code change reviews
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Only trusted users should be allowed to dismiss code change reviews.
+rationale: >-
+  Dismissing a code change review permits users to merge new suggested code changes 
+  without going through the standard process of approvals. Controlling who can perform 
+  this action will prevent malicious actors from simply dismissing the required reviews to 
+  code changes and merging malicious or dysfunctional code into the code base.
+impact: >-
+  In cases where a code change proposal has been updated since it was last reviewed 
+  and the person who reviewed it isn't available for approval, a general collaborator would 
+  not be able to merge their code changes until a user with "dismiss review" abilities could 
+  dismiss the open review. 
+  Users who are not allowed to dismiss code change reviews will not be permitted to do 
+  so, and thus are unable to waive the standard flow of approvals.
+audit: |
+  For each code repository in use, perform the next steps to verify that only trusted users are allowed to dismiss code change reviews:
+  To verify that restrictions are in place around who can dismiss code change reviews, view your branch protection settings for a project.
+  You must have at least the Maintainer role.
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Repository.
+    3. Expand Protected branches.
+remediation: |
+  Prerequisites:
+
+    You must have at least the Maintainer role. When granting a group Allowed to merge or Allowed to push and merge permissions on a protected branch, the group must be added to the project. To protect a branch:
+      1. On the left sidebar, select Search or go to and find your project.
+      2. Select Settings > Repository.
+      3. Expand Protected branches.
+      4. Select Add protected branch.
+      5. From the Branch dropdown list, select the branch you want to protect.
+      6. From the Allowed to merge list, select a role that can merge into this branch.
+      7. From the Allowed to push and merge list, select a role that can push to this branch.
+  
+  In GitLab Premium and Ultimate, you can also add groups or individual users to Allowed to merge and Allowed to push and merge. Select Protect. The protected branch displays in the list of protected branches.
+default_value: By default, all users who have write access to the code repository are able to dismiss code change reviews.
+references:
+  - https://docs.gitlab.com/ee/user/project/protected_branches.html
+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/source_code_1/code_changes_1_1/code_owners.yml

@@ -0,0 +1,61 @@
+---
+id: 1.1.6
+name: code_owners
+title: Ensure code owners are set for extra sensitive code or configuration
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Code owners are trusted users that are responsible for reviewing and managing an 
+  important piece of code or configuration. An organization is advised to set code owners 
+  for every extremely sensitive code or configuration.
+rationale: >-
+  Configuring code owners protects data by verifying that trusted users will notice and 
+  review every edit, thus preventing unwanted or malicious changes from potentially 
+  compromising sensitive code or configurations.
+impact: >-
+  Code owner users will receive notifications for every change that occurs to the code and
+  subsequently added as reviewers of merge requests automatically.
+audit: |
+  In every project, view the Code Owners of a file or directory:
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Code > Repository.
+    3. Go to the file or directory you want to see the Code Owners for.
+    4. Optional. Select a branch or tag.
+  GitLab shows the Code Owners at the top of the page.
+remediation: |
+  Prerequisites:
+    • You must be able to either push to the default branch or create a merge request.
+  1. Create a CODEOWNERS file in your preferred location.
+  2. Define some rules in the file following the Code Owners syntax reference. Some suggestions:
+    • Configure All eligible approvers approval rule.
+    • Require Code Owner approval on a protected branch.
+  3. Commit your changes, and push them up to GitLab.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/codeowners/
+cis_controls:
+  - id: 6.8
+    version: 8
+    name: Define and Maintain Role-Based Access Control
+    description: >-
+      Define and maintain role-based access control, through determining and 
+      documenting the access rights necessary for each role within the enterprise to 
+      successfully carry out its assigned duties. Perform access control reviews of 
+      enterprise assets to validate that all privileges are authorized, on a recurring 
+      schedule at a minimum annually, or more frequently.
+    implementation_groups:
+      - IG3
+  - id: 14.6
+    version: 7
+    name: Protect Information through Access Control Lists
+    description: >-
+      Protect all information stored on systems with file system, network share, claims, 
+      application, or database specific access control lists. These controls will enforce the 
+      principle that only authorized individuals should have access to the information 
+      based on their need to access the information as a part of their responsibilities.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/code_changes_1_1/code_tracing.yml

@@ -0,0 +1,52 @@
+---
+id: 1.1.2
+name: code_tracing
+title: Ensure any change to code can be traced back to its associated task
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Use a task management system to trace any code back to its associated task.
+rationale: >-
+  The ability to trace each piece of code back to its associated task simplifies the Agile 
+  and DevOps process by enabling transparency of any code changes. This allows faster 
+  remediation of bugs and security issues, while also making it harder to push 
+  unauthorized code changes to sensitive projects. Additionally, using a task 
+  management system simplifies achieving compliance, as it is easier to track each 
+  regulation.
+impact: >-
+audit: >-
+  Ensure every code change can be traced back to its origin task in a task management 
+  system.
+remediation: >-
+  Use GitLab issues to manage tasks as the starting point for each code change. Whether 
+  it is a new feature, bug fix, or security fix - all should originate from a dedicated task 
+  (GitLab issue) in your organization's task management system. Tasks (issues) should 
+  be linked to Merge Requests, and Merge requests should be linked to Issues.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/issues/related_issues.html
+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/source_code_1/code_changes_1_1/comments_resolved_before_merging.yml

@@ -0,0 +1,59 @@
+---
+id: 1.1.11
+name: comments_resolved_before_merging
+title: Ensure all open comments are resolved before allowing code change merging
+profile: 2
+category: source_code
+sub_category: code_changes
+description: >-
+  Organizations should enforce a "no open comments" policy before allowing code 
+  change merging.
+rationale: >-
+  In an open code change proposal, reviewers can leave comments containing their 
+  questions and suggestions. These comments can also include potential bugs and 
+  security issues. Requiring all comments on a code change proposal to be resolved 
+  before it can be merged ensures that every concern is properly addressed or 
+  acknowledged before the new code changes are introduced to the code base.
+impact: >-
+  Code change proposals containing open comments would not be able to be merged into 
+  the code base.
+audit: |
+  Ensure that All threads must be resolved before changes in a branch can be merged.
+  To review these settings:
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Merge requests.
+    3. In the Merge checks section, check to see that the All threads must be resolved checkbox has been selected.
+remediation: |
+  You can prevent merge requests from being merged until all threads are resolved.
+  When this setting is enabled, the Unresolved threads counter in a merge request is shown in orange when at least one thread remains unresolved.
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Merge requests.
+    3. In the Merge checks section, select the All threads must be resolved checkbox.
+    4. Select Save changes.
+default_value: By default, code changes with open comments on them are able to be merged into the code base
+references:
+  - https://docs.gitlab.com/ee/user/project/merge_requests/index.html#prevent-merge-unless-all-threads-are-resolved
+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/source_code_1/code_changes_1_1/commits_must_be_signed_before_merging.yml

@@ -0,0 +1,63 @@
+---
+id: 1.1.12
+name: commits_must_be_signed_before_merging
+title: Ensure verification of signed commits for new changes before merging
+profile: 2
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure every commit in a merge request is signed and verified before merging.
+rationale: >-
+  Signing commits, or requiring to sign commits, gives other users confidence about the 
+  origin of a specific code change. It ensures that the author of the change is not hidden 
+  and is verified by the version control system, thus the change comes from a trusted 
+  source.
+impact: >-
+  Merge requests with unsigned commits cannot be merged.
+audit: |
+  Identify which projects permit unsigned commits by performing the following steps for each project:
+    • Navigate to the main page of the project.
+    • In the sidebar, select Settings > Repository.
+    • Expand the Push rules section.
+    • Identify the Select push rules section.
+    • If 'Reject unsigned commits' is selected the project is compliant.
+remediation: |
+  Ensure only signed commits can be merged for every branch via branch protection rules by performing the following steps for each project:
+    • Navigate to the main page of the project.
+    • In the sidebar, select Settings > Repository.
+    • Expand the Push rules section.
+    • Under Select push rules select 'Reject unsigned commits'.
+    • Select 'Save push rules'.
+  
+  As an administrator you can configure a secure default for new projects by performing the following steps:
+    • Navigate to the Admin Area.
+    • In the sidebar, select Push Rules.
+    • Select 'Reject unsigned commits'.
+    • Select 'Save push rules'.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/repository/push_rules.html
+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/source_code_1/code_changes_1_1/default_branch_protected.yml

@@ -0,0 +1,85 @@
+---
+id: 1.1.20
+name: default_branch_protected
+title: Ensure branch protection is enforced on the default branch
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Enforce branch protection on the default and main branch.
+rationale: >-
+  The default or main branch of repositories is considered very important, as it is
+  eventually gets deployed to the production. Therefore it needs protection. By enforcing
+  branch protection rules on this branch, it is secured from unwanted or unauthorized
+  changes. It can also be protected from untested and unreviewed changes and more.
+impact: >-
+audit: |
+  The default branch of GitLab repositories are protected by default. This setting can be overridden at the instance, group, or project level.
+
+  To verify that branch protection is enabled for the main or default branch at the project level:
+    1. Navigate to the main page of the GitLab repository.
+    2. Select Settings > Repository.
+    3. Expand Protected branches.
+    4. Verify that initial default branch protection is applied to the "main" or default branch.
+
+  GitLab Group Owners can also perform the following to ensure branch protection is enabled by default for new projects at the group level:
+    1. Navigate to the main page for your GitLab group.
+    2. Select Settings > Repository.
+    3. Under Default branch, verify that initial default branch protection is applied to the "main" or default branch.
+
+  GitLab administrators can perform the following to ensure branch protection is enabled by default for the main or default branch of all new projects at the instance level (self-managed GitLab only):
+    1. Navigate to Admin Area.
+    2. Select Settings > Repository.
+    3. Under Default branch, verify that initial default branch protection is applied to the "main" or default branch.
+remediation: |
+  Perform the following to enforce branch protection on the main or default branch at the project level:
+    1. Navigate to your project page.
+    2. Select Settings > Repository.
+    3. Expand Protected branches.
+    4. Select Add protected branch.
+    5. From the Branch dropdown list, select the project's main or default branch.
+    6. Choose the roles who should be Allowed to merge and Allowed to push and merge for this protected default branch.
+    7. Select Protect.
+
+  Perform the following to enforce branch protection on the main or default branch of new projects at the group level:
+    1. Navigate to the main page for your GitLab group.
+    2. Select Settings > Repository.
+    3. Expand Default branch
+    4. Enable initial default branch protection for the "main" or default branch of new repositories created in the group.
+    5. Select Save changes.
+
+  Perform the following to enforce branch protection on the main branch of new projects at the instance level (self-managed GitLab administrators only):
+    1. Navigate to Admin Area.
+    2. Select Settings > Repository.
+    3. Expand Default branch.
+    4. Enable initial default branch protection for the "main" or default branch of new repositories created on this GitLab instance.
+    5. Select Save changes.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/api/protected_branches.html
+  - https://docs.gitlab.com/ee/api/group_protected_branches.html
+  - https://docs.gitlab.com/ee/api/settings.html
+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/source_code_1/code_changes_1_1/deny_branch_deletions.yml

@@ -0,0 +1,76 @@
+---
+id: 1.1.17
+name: deny_branch_deletions
+title: Ensure branch deletions are denied
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure that users with only push access are incapable of deleting a protected branch.
+rationale: >-
+  When enabling deletion of a protected branch, any user with at least push access to the 
+  repository can delete a branch. This can be potentially dangerous, as a simple human 
+  mistake or a hacked account can lead to data loss if a branch is deleted. It is therefore 
+  crucial to prevent such incidents by denying protected branch deletion.
+impact: >-
+audit: |
+  For each repository that is being used, verify that protected branches cannot be deleted by performing the following:
+    • View your protected branches by going to the left sidebar and selecting Search or go to the Homepage and find your project.
+    • Select Settings > Repository.
+    • Expand Protected branches to view a list of protected branches
+remediation: |
+  For each repository that is being used, protect a branch in order to block the option to delete branches. To protect a branch for one project:
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Repository.
+    3. Expand Protected branches.
+    4. Select Add protected branch.
+    5. From the Branch dropdown list, select the branch you want to protect.
+    6. From the Allowed to merge list, select a role that can merge into this branch.
+    7. From the Allowed to push and merge list, select a role that can push to this branch.
+
+  Group owners can create protected branches at the group level. These settings are
+  inherited by all projects in the group and can't be overridden by project settings. If a
+  specific branch is configured with Allowed to force push settings at both the group and
+  project levels, the Allowed to force push setting at the project level is ignored in favor
+  of the group level setting.
+
+  • You must have the Owner role in the group.
+
+  To protect a branch for all the projects in a group:
+    1. On the left sidebar, select Search or go to and find your group.
+    2. Select Settings > Repository.
+    3. Expand Protected branches.
+    4. Select Add protected branch.
+    5. In the Branch text box, type the branch name or a wildcard. Branch names and wildcards are case-sensitive.
+    6. From the Allowed to merge list, select a role that can merge into this branch.
+    7. From the Allowed to push and merge list, select a role that can push to this branch.
+    8. Select Protect.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/protected_branches.html
+cis_controls:
+  - id: 3.3
+    version: 8
+    name: Configure Data Access Control Lists
+    description: >-
+      Configure data access control lists based on a user's need to know. Apply data 
+      access control lists, also known as access permissions, to local and remote file 
+      systems, databases, and applications.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 14.6
+    version: 7
+    name: Protect Information through Access Control Lists
+    description: >-
+      Protect all information stored on systems with file system, network share, 
+      claims, application, or database specific access control lists. These controls will 
+      enforce the principle that only authorized individuals should have access to the 
+      information based on their need to access the information as a part of their 
+      responsibilities.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/code_changes_1_1/ensure_force_push_is_denied.yml

@@ -0,0 +1,59 @@
+---
+id: 1.1.16
+name: ensure_force_push_is_denied
+title: Ensure force push code to branches is denied
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  The "Force Push" option allows users with "Push" permissions to force their changes 
+  directly to the branch without a merge request, and thus should be disabled.
+rationale: >-
+  The "Force Push" option allows users to override the existing code with their own code. 
+  This can lead to both intentional and unintentional data loss, as well as data infection 
+  with malicious code. Disabling the "Force Push" option prohibits users from forcing their 
+  changes to the master branch, which ultimately prevents malicious code from entering 
+  source code.
+impact: >-
+  Users cannot force push to protected branches.
+audit: |
+  For every code repository in use, validate that no one can force push code by performing the following:
+    • On GitLab, navigate to the main page of the repository.
+    • Navigate to Settings > Repository.
+    • Click Expand next to the Protected Branches section.
+    • Verify that your repository's main (or default) branch is protected.
+    • Verify that "Allowed to force push" is toggled off.
+remediation: |
+  For each repository in use, block the option to "Force Push" code by performing the following:
+    • On GitLab, navigate to the main page of the repository.
+    • Navigate to Settings > Repository .
+    • Click Expand next to the Protected Branches section.
+    • Ensure your project's default branch is protected.
+    • Toggle "Allowed to force push" off.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/protected_branches.html
+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: >-