gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/source_code_1/code_changes_1_1/linear_history_required.yml

@@ -0,0 +1,56 @@
+---
+id: 1.1.13
+name: linear_history_required
+title: Ensure linear history is required
+profile: 2
+category: source_code
+sub_category: code_changes
+description: >-
+  Linear history is the name for Git history where all commits are listed in chronological 
+  order, one after another. Such history exists if a merge request is merged either by rebase 
+  merge (re-order the commits history) or squash merge (squashes all commits to one). 
+  Ensure that linear history is required by requiring the use of rebase or squash merge 
+  when merging a merge request.
+rationale: >-
+  Enforcing linear history produces a clear record of activity, and as such it offers specific 
+  advantages: it is easier to follow, easier to revert a change, and bugs can be found 
+  more easily.
+impact: >-
+  Merge requests cannot be merged except squash or rebase merge.
+audit: |
+  For every project, perform the following steps:
+    • Navigate to your project
+    • In the sidebar, select Settings > Merge Requests
+    • Under 'Merge method', if 'Merge Commit' or 'Merge commit with semi-linear history' is selected then the project is not-compliant.
+remediation: |
+  For every project, perform the following steps:
+    • Navigate to your project
+    • In the sidebar, select Settings > Repository
+    • Under 'Merge method', select 'Fast-forward merge'.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/merge_requests/methods/
+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/merging_restrictions.yml

@@ -0,0 +1,65 @@
+---
+id: 1.1.15
+name: merging_restrictions
+title: Ensure pushing or merging of new code is restricted to specific individuals or teams
+profile: 2
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure that only trusted users can push or merge new code to protected branches.
+rationale: >-
+  Requiring that only trusted users may push or merge new changes reduces the risk of 
+  unverified code, especially malicious code, to a protected branch by reducing the 
+  number of trusted users who are capable of doing such.
+impact: >-
+  Only administrators and trusted users can push or merge to the protected branch.
+audit: |
+  For every code repository in use, ensure only trusted and responsible users can push or merge new code by performing the following:
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Repository.
+    3. Expand Protected branches.
+    4. If there are no protected branches, the repository is not compliant.
+    5. For each protected branch, ensure:
+      1. The role(s) and user(s) who are 'Allowed to merge' are trusted
+      2. The role(s) and user(s) who are 'Allowed to push and merge' are trusted
+      3. The 'Allowed to force push' toggle is not selected
+remediation: |
+  Prerequisites:
+    You must have at least the Maintainer role in the group.
+
+  For every code repository in use, allow only trusted and responsible users to push or  merge new code by performing the following:
+    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.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/merge_requests_approvals.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/readme.md

@@ -0,0 +1,26 @@
+# 1.1 Code Changes
+
+This section consists of security recommendations for code changes and how they should be done. It contains recommendations to protect the main branch of the application code. This branch is the most important one, because it contains the actual code that is being delivered to the costumer. It should be protected from any mistake or malicious deed in order to keep the software secured.
+
+## Recommendations
+
+* [1.1.1 - version_control.yml](./version_control.yml)
+* [1.1.2 - code_tracing.yml](./code_tracing.yml)
+* [1.1.3 - code_approvals.yml](./code_approvals.yml)
+* [1.1.4 - code_approval_dismissals.yml](./code_approval_dismissals.yml)
+* [1.1.5 - code_dismissal_restrictions.yml](./code_dismissal_restrictions.yml)
+* [1.1.6 - code_owners.yml](./code_owners.yml)
+* [1.1.7 - code_changes_require_code_owners.yml](./code_changes_require_code_owners.yml)
+* [1.1.8 - stale_branch_reviews.yml](./stale_branch_reviews.yml)
+* [1.1.9 - checks_pass_before_merging.yml](./checks_pass_before_merging.yml)
+* [1.1.10 - branches_updated_before_merging.yml](./branches_updated_before_merging.yml)
+* [1.1.11 - comments_resolved_before_merging.yml](./comments_resolved_before_merging.yml)
+* [1.1.12 - commits_must_be_signed_before_merging.yml](./commits_must_be_signed_before_merging.yml)
+* [1.1.13 - linear_history_required.yml](./linear_history_required.yml)
+* [1.1.14 - branch_protections_for_admins.yml](./branch_protections_for_admins.yml)
+* [1.1.15 - merging_restrictions.yml](./merging_restrictions.yml)
+* [1.1.16 - ensure_force_push_is_denied.yml](./ensure_force_push_is_denied.yml)
+* [1.1.17 - deny_branch_deletions.yml](./deny_branch_deletions.yml)
+* [1.1.18 - auto_risk_scan_merges.yml](./auto_risk_scan_merges.yml)
+* [1.1.19 - audit_branch_protections.yml](./audit_branch_protections.yml)
+* [1.1.20 - default_branch_protected.yml](./default_branch_protected.yml)

gitlabcis/recommendations/source_code_1/code_changes_1_1/stale_branch_reviews.yml

@@ -0,0 +1,72 @@
+---
+id: 1.1.8
+name: stale_branch_reviews
+title: Ensure inactive branches are periodically reviewed and removed
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Keep track of code branches that are inactive for a lengthy period of time and 
+  periodically remove them.
+rationale: >-
+  Git branches that have been inactive (i.e., no new changes introduced) for a long period 
+  of time are enlarging the surface of attack for malicious code injection, sensitive data 
+  leaks, and CI pipeline exploitation. They potentially contain outdated dependencies 
+  which may leave them highly vulnerable. They are more likely to be improperly 
+  managed, and could possibly be accessed by a large number of members of the 
+  organization.
+impact: >-
+  Removing inactive Git branches means that any code changes they contain would be 
+  removed along with them, thus work done in the past might not be accessible after 
+  auditing for inactivity.
+audit: |
+  For each project, verify that all existing Git branches are active or have yet to be checked for inactivity by performing the next steps:
+    • Navigate to the main page of the project.
+    • In the sidebar select Code > Branches
+    • Use the navigation at the top of the page to view the Stale branches. The Stale view shows all branches that no one has committed to in the last three months, ordered by the branches with the oldest commits first.
+    • If the list is empty, you are compliant. If the list is not empty, but there is a valid reason the branches listed are not deleted, you are compliant.
+
+  You can perform the next steps to verify that merge request branches are prevented from becoming stale branches by default:
+    • Navigate to the main page of the project.
+    • In the left sidebar select Settings > Merge requests
+    • Verify if 'Enable "Delete source branch" option by default' is selected. If it is not selected, you are more likely to become non-compliant.
+remediation: |
+  For each project, review existing Git branches and remove those which were identified during the audit as being non-compliant by performing the following:
+    • Navigate to the main page of the project.
+    • In the sidebar select Code > Branches
+    • Next to each non-compliant branch select the vertical ellipsis
+    • Select 'Delete branch'
+    • Read the warning
+    • Select 'Yes, delete branch'
+  
+  You can perform the next steps to reduce the likelihood of a stale branches remaining after a merge request:
+    • Navigate to the main page of the project.
+    • In the left sidebar select Settings > Merge requests
+    • Select 'Enable "Delete source branch" option by default'.
+default_value: By default, newly opened Git branches would never be removed, regardless of activity or inactivity.
+references:
+  - https://docs.gitlab.com/ee/user/project/repository/branches/
+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/version_control.yml

@@ -0,0 +1,45 @@
+---
+id: 1.1.1
+name: version_control
+title: Ensure any changes to code are tracked in a version control platform
+profile: 1
+category: source_code
+sub_category: code_changes
+description: |
+  Manage all code projects in a version control platform.
+rationale: |
+  Version control platforms keep track of every modification to code. They represent the 
+  cornerstone of code security, as well as allowing for better code collaboration within 
+  engineering teams. With granular access management, change tracking, and key 
+  signing of code edits, version control platforms are the first step in securing the software 
+  supply chain.
+audit: |
+  Ensure that all code activity is managed in a GitLab repository for every micro-
+  service or application developed by your organization.
+impact: |
+remediation: |
+  Upload existing code projects to a Gitlab group or instance and create an identity for 
+  each active team member who might contribute or need access to it.
+default_value:
+references:
+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.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/source_code_1/code_risks_1_5/dast_api_scanning.yml

@@ -0,0 +1,50 @@
+---
+id: 1.5.8
+name: dast_api_scanning
+title: Ensure scanners are in place for API runtime security weaknesses
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Dynamic Application Security Testing (DAST) runs automated penetration tests to find 
+  vulnerabilities in your APIs as they are running. DAST automates a hacker's approach 
+  and simulates real-world attacks for critical threats such as cross-site scripting (XSS), 
+  SQL injection (SQLi), and cross-site request forgery (CSRF) to uncover vulnerabilities 
+  and misconfigurations that other security tools cannot detect.
+rationale: >-
+impact: >-
+audit: |
+  Ensure a dynamic API scanning tool is set up to identify API-specific 
+  vulnerabilities and that every project that contains an APi is scanned by it. 
+    • The DAST-API template must be configured for your project. 
+    • A successful pipeline was run on the default branch. You should not change the default behavior of allowing the application security jobs to fail. 
+    • Review the output from the scan in Secure > Vulnerability Report
+remediation: |
+  1. Include the DAST-API.gitlab-ci.yml template in your .gitlab-ci.yml file.
+  2. The configuration file has several testing profiles defined with different checks enabled. Select a profile and provide it by adding the DAST_API_PROFILE CI/CD variable to your .gitlab-ci.yml file.
+  3. Provide the location of the OpenAPI Specification as either a file or URL. Specify the location by adding the DAST_API_OPENAPI variable.
+  4. The target API instance's base URL is also required. Provide it by using the DAST_API_TARGET_URL variable or an environment_url.txt file.
+  5. After configuration, the analyzer will run in your pipeline.
+  6. View the results in the Vulnerability report and remediate the vulnerabilities.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/dast_api/
+cis_controls:
+  - id: 16.12
+    version: 8
+    name: Implement Code-Level Security Checks
+    description: >-
+      Apply static and dynamic analysis tools within the application life cycle to 
+      verify that secure coding practices are being followed.
+    implementation_groups:
+      - IG3
+  - id: 18.7
+    version: 7
+    name: Apply Static and Dynamic Code Analysis Tools
+    description: >-
+      Apply static and dynamic analysis tools to verify that secure coding 
+      practices are being adhered to for internally developed software.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/code_risks_1_5/dast_web_scanning.yml

@@ -0,0 +1,51 @@
+---
+id: 1.5.7
+name: dast_web_scanning
+title: Ensure scanners are in place for web application runtime security weaknesses
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Dynamic Application Security Testing (DAST) runs automated penetration tests to find 
+  vulnerabilities in your web applications as they are running. DAST automates a hacker's 
+  approach and simulates real-world attacks for critical threats such as cross-site scripting 
+  (XSS), SQL injection (SQLi), and cross-site request forgery (CSRF) to uncover 
+  vulnerabilities and misconfigurations that other security tools cannot detect.
+rationale: >-
+impact: >-
+audit: |
+  Ensure Browser-based DAST is set up to identify dynamic vulnerabilities in web 
+  applications that cannot be detected by other tools earlier in the SDLC. Ensure that 
+  every project that contains a web application is scanned by DAST. 
+    • The DAST template must be configured for your project. 
+    • Review the output from the previous scan on your default branch in Secure > 
+  Vulnerability Report.
+remediation: |
+  1. Include the DAST.gitlab-ci.yml template in your .gitlab-ci.yml file.
+  2. Add a dast stage to your GitLab CI/CD stages configuration.
+  3. Define the URL to be scanned by DAST by setting the DAST_WEBSITE CI/CD variable.
+  4. Add any additionally desired CI variables to customize the test.
+  5. After configuration, the analyzer will run in your pipeline.
+  6. View the results in the Vulnerability report and remediate the vulnerabilities.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/dast/browser/configuration/customize_settings.html
+cis_controls:
+  - id: 16.12
+    version: 8
+    name: Implement Code-Level Security Checks
+    description: >-
+      Apply static and dynamic analysis tools within the application life cycle to 
+      verify that secure coding practices are being followed.
+    implementation_groups:
+      - IG3
+  - id: 18.7
+    version: 7
+    name: Apply Static and Dynamic Code Analysis Tools
+    description: >-
+      Apply static and dynamic analysis tools to verify that secure coding 
+      practices are being adhered to for internally developed software.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/code_risks_1_5/dependency_scanning.yml

@@ -0,0 +1,84 @@
+---
+id: 1.5.5
+name: dependency_scanning
+title: Ensure scanners are in place for open-source vulnerabilities in used packages
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Detect, prevent and monitor known open-source vulnerabilities in packages that are 
+  being used.
+rationale: >-
+  Open-source vulnerabilities might exist before one starts to use a package, but they are 
+  also discovered over time. New attacks and vulnerabilities are announced every now 
+  and then. It is important to keep track of these and to monitor whether the dependencies 
+  used are affected by the recent vulnerability. Detecting and fixing those packages' 
+  vulnerabilities decreases the attack surface within deployed and running applications 
+  that use such packages. It prevents security flaws from reaching the production 
+  environment which could eventually lead to a security breach.
+impact: >-
+audit: |
+  For every repository that is in use, verify that a dependency scanning tool is set to detect, prevent, and monitor vulnerabilities in project dependencies by performing the following:
+    1. On GitLab, navigate to the main page of the repository.
+    2. Review the CI pipeline configuration to verify that Dependency Scanning has been configured to run on this project.
+remediation: |
+  For every repository that is in use, set a dependency scanning tool to detect, prevent, and monitor vulnerabilities in project packages by performing the following:
+    1. On GitLab, navigate to the main page of the repository.
+    2. Configure Dependency Scanning to run on this project.
+default_value:
+references:
+cis_controls:
+  - id: 7.5
+    version: 8
+    name: Perform Automated Vulnerability Scans of Internal Enterprise Assets
+    description: >-
+      Perform automated vulnerability scans of internal enterprise assets on a 
+      quarterly, or more frequent, basis. Conduct both authenticated and 
+      unauthenticated scans, using a SCAP-compliant vulnerability scanning tool.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 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: 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: 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: 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: >-
+  GitLab Dependency Scanning is only available in GitLab Ultimate. If you're not 
+  using GitLab Ultimate, consider using a free open-source dependency scanner as part 
+  of your CI pipeline.

gitlabcis/recommendations/source_code_1/code_risks_1_5/enable_secret_detection.yml

@@ -0,0 +1,45 @@
+---
+id: 1.5.1
+name: enable_secret_detection
+title: Ensure scanners are in place to identify and prevent sensitive data in code
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Detect and prevent sensitive data in code, such as confidential ID numbers, passwords, etc.
+rationale: >-
+  Having sensitive data in the source code makes it easier for attackers to maliciously use 
+  such information. In order to avoid this, designate scanners to identify and prevent the 
+  existence of sensitive data in the code.
+impact: >-
+audit: |
+  For every repository in use, verify that scanners are set to identify and prevent the existence of sensitive data in code by performing the following:
+    1. On GitLab, navigate to the main page of the repository.
+    2. Review the CI pipeline configuration to verify that Secret Detection has been enabled on this project.
+remediation: |
+  For every repository in use, designate scanners to identify and prevent sensitive data in code by performing the following:
+    1. On GitLab, navigate to the main page of the repository.
+    2. Enable secret detection for this project.
+default_value:
+references:
+cis_controls:
+  - id: 16.12
+    version: 8
+    name: Implement Code-Level Security Checks
+    description: >-
+      Apply static and dynamic analysis tools within the application life cycle to 
+      verify that secure coding practices are being followed.
+    implementation_groups:
+      - IG3
+  - id: 18.7
+    version: 8
+    name: Apply Static and Dynamic Code Analysis Tools
+    description: >-
+      Apply static and dynamic analysis tools to verify that secure coding 
+      practices are being adhered to for internally developed software.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-
+  By January 2023, this feature is supposed to be open to all plans. Until then it is only for 
+  enterprise users.

gitlabcis/recommendations/source_code_1/code_risks_1_5/license_scanning.yml

@@ -0,0 +1,47 @@
+---
+id: 1.5.6
+name: license_scanning
+title: Ensure scanners are in place for open-source license issues in used packages
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Detect open-source license problems in used dependencies and fix them.
+rationale: >-
+  A software license is a legal document that establishes several key conditions between 
+  a software company or developer and a user in order to allow the use of software. 
+  Software licenses have the potential to create code dependencies. Not following the 
+  conditions in the software license can also lead to lawsuits. When using packages with 
+  a software license, especially commercial ones (which are the most permissive), it is 
+  important to verify what is allowed by that license in order to be protected against 
+  lawsuits.
+impact: >-
+audit: |
+  Ensure a license scanning tool is set up to identify open-source license problems and that every package you use is scanned by it.
+    • The Dependency Scanning or Container Scanning CI job must be configured for your project.
+    • Your project uses at least one of the languages and package managers supported by Gemnasium.
+    • A successful pipeline was run on the default branch. You should not change the default behavior of allowing the application security jobs to fail.
+    • Review the output from the scan in Secure > Dependency list.
+remediation: |
+  The Dependency Scanning or Container Scanning CI job must be configured for your project.
+    • Your project uses at least one of the languages and package managers supported by Gemnasium.
+    • A successful pipeline was run on the default branch. You should not change the default behavior of allowing the application security jobs to fail.
+    • Take necessary actions based on the outcome of the scan in Secure > Dependency list.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/index.html
+  - https://docs.gitlab.com/ee/user/application_security/dependency_list/index.html
+cis_controls:
+  - id: 0.0
+    version: 8
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+  - id: 0.0
+    version: 7
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+additional_info: >-

gitlabcis/recommendations/source_code_1/code_risks_1_5/readme.md

@@ -0,0 +1,14 @@
+# 1.5 Code Risks
+
+This section consists of recommendations for many security code scanners. This includes for example, looking for hardcoded secrets, common misconfigurations that are vulnerable to attack or restrictive licenses. Because an application code has a lot of components, it is important to scan each part that can lead to attack - from secrets to licenses.
+
+## Recommendations
+
+* [1.5.1 - enable_secret_detection.yml](./enable_secret_detection.yml)
+* [1.5.2 - secure_pipeline_instructions.yml](./secure_pipeline_instructions.yml)
+* [1.5.3 - secure_iac_instructions.yml](./secure_iac_instructions.yml)
+* [1.5.4 - vulnerability_scanning.yml](./vulnerability_scanning.yml)
+* [1.5.5 - dependency_scanning.yml](./dependency_scanning.yml)
+* [1.5.6 - license_scanning.yml](./license_scanning.yml)
+* [1.5.7 - dast_web_scanning.yml](./dast_web_scanning.yml)
+* [1.5.8 - dast_api_scanning.yml](./dast_api_scanning.yml)

gitlabcis/recommendations/source_code_1/code_risks_1_5/secure_iac_instructions.yml

@@ -0,0 +1,81 @@
+---
+id: 1.5.3
+name: secure_iac_instructions
+title: Ensure scanners are in place to secure Infrastructure as Code (IaC) instructions
+profile: 2
+category: source_code
+sub_category: code_risks
+description: >-
+  Detect and prevent misconfigurations or insecure instructions in Infrastructure as Code (IaC) files, such as Terraform files.
+rationale: >-
+  Detecting and fixing misconfigurations and/or insecure instructions in IaC (Infrastructure 
+  as Code) files decreases the risk for data leak or data theft. It is important to secure IaC 
+  instructions in order to prevent further problems of deployment, exposed assets, or 
+  improper configurations, which can ultimately lead to easier ways to attack and steal 
+  organization data.
+impact: >-
+audit: |
+  For every repository that holds IaC instructions files, verify that a scanning tool such as GitLab's Infrastructure as Code scanning is configured to identify and prevent misconfigurations and insecure instructions.
+    1. On GitLab, navigate to the main page of the repository.
+    2. Review the CI pipeline configuration to verify that IaC scanning has been enabled on this project.
+remediation: |
+  For every repository that holds IaC instructions files, configure GitLab's Infrastructure as Code scanning (or another IaC scanning tool) to identify and prevent misconfigurations and insecure instructions.
+    1. On GitLab, navigate to the main page of the repository.
+    2. Enable IaC scanning for this project.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/iac_scanning/#enable-the-scanner
+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: 16.7
+    version: 8
+    name: Use Standard Hardening Configuration Templates for Application Infrastructure
+    description: >-
+      Use standard, industry-recommended hardening configuration templates for 
+      application infrastructure components. This includes underlying servers, databases, 
+      and web servers, and applies to cloud containers, Platform as a Service (PaaS) 
+      components, and SaaS components. Do not allow in-house developed software to 
+      weaken configuration hardening.
+    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: 18.11
+    version: 7
+    name: Use Standard Hardening Configuration Templates for Databases
+    description: >-
+      For applications that rely on a database, use standard hardening configuration 
+      templates. All systems that are part of critical business processes should also be 
+      tested.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-