gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/dependencies_3/third_party_packages_3_1/verify_signed_metadata.yml

@@ -0,0 +1,41 @@
+---
+id: 3.1.3
+name: verify_signed_metadata
+title: Ensure signed metadata of the build process is required and verified
+profile: 1
+category: dependencies
+sub_category: third_party_packages
+description: >-
+  Require and verify signed metadata of the build process for all dependencies in use.
+rationale: >-
+  The metadata of a build process lists every action that took place during an artifact 
+  build. It is used to ensure that an artifact has not been compromised during the build, 
+  that no malicious code was injected into it, and that no nefarious dependencies were 
+  added during the build phase. This creates trust between user and vendor that the 
+  software supplied is exactly the software that was promised. Signing this metadata adds 
+  a checksum to ensure there have been no revisions since its creation, as this checksum 
+  changes when the metadata is altered. Verification of proper metadata signature with 
+  Certificate Authority confirms that the signature was produced by a trusted entity.
+impact: >-
+audit: >-
+  For each artifact used, ensure it was supplied with verified and signed metadata of its 
+  build process. The signature should be the organizational signature and should be 
+  verifiable by common Certificate Authority servers.
+remediation: >-
+  For each artifact in use, require and verify signed metadata of the build process.
+default_value:
+references:
+cis_controls:
+  - id: 0.0
+    version: 8
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+  - id: 0.0
+    version: 7
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+additional_info: >-

gitlabcis/recommendations/dependencies_3/validate_packages_3_2/org_wide_dependency_policy.yml

@@ -0,0 +1,47 @@
+---
+id: 3.2.1
+name: org_wide_dependency_policy
+title: Ensure an organization-wide dependency usage policy is enforced
+profile: 1
+category: dependencies
+sub_category: validate_packages
+description: >-
+  Enforce a policy for dependency usage across the organization. For example, disallow 
+  the use of packages less than 60 days old.
+rationale: >-
+  Enforcing a policy for dependency usage in an organization helps to manage 
+  dependencies across the organization and ensure that all usage is compliant with 
+  security policy. If, for example, the policy limits the package managers that can be used, 
+  enforcing it will make sure that every dependency is installed only from these package 
+  managers, and limit the risk of installing from any untrusted source.
+impact: >-
+audit: >-
+  Verify that a policy for dependency usage is enforced across the organization.
+remediation: >-
+  Enforce policies for dependency usage across the organization.
+default_value:
+references:
+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 and Maintain a Secure Application Development Process
+    description: >-
+      Establish secure coding practices appropriate to the programming language and 
+      development environment being used.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/dependencies_3/validate_packages_3_2/package_license_scanning.yml

@@ -0,0 +1,47 @@
+---
+id: 3.2.3
+name: package_license_scanning
+title: Ensure packages are automatically scanned for license implications
+profile: 1
+category: dependencies
+sub_category: validate_packages
+description: >-
+  A software license is a document that provides legal conditions and guidelines for the 
+  use and distribution of software, usually defined by the author. It is recommended to 
+  scan for any legal implications automatically.
+rationale: >-
+  When using packages with software licenses, especially commercial ones which tend to 
+  be the strictest, it is important to verify that the use of the package meets the conditions 
+  of the license. If the use of the package violates the licensing agreement, it exposes the 
+  organization to possible lawsuits. Scanning used packages for such license implications 
+  leads to faster detection and quicker fixes of such violations, and also reduces the risk 
+  for a lawsuit.
+impact: >-
+audit: >-
+  Ensure license implication rules are configured and are scanned automatically. Once 
+  Dependency Scanning is enabled for your project, continuous license scanning is 
+  enabled.
+remediation: |
+  Enable Dependency scanning in order to automatically scan packages for license implications. To enable the analyzer, either:
+    • Enable Auto DevOps, which includes dependency scanning.
+    • Edit the .gitlab-ci.yml file manually. Use this method if your .gitlab-ci.yml file is complex.
+    • Use a preconfigured merge request.
+    • Create a scan execution policy that enforces dependency scanning.
+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_scanning/index.html#enabling-the-analyzer
+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/dependencies_3/validate_packages_3_2/package_ownership_change.yml

@@ -0,0 +1,42 @@
+---
+id: 3.2.4
+name: package_ownership_change
+title: Ensure packages are automatically scanned for ownership change
+profile: 1
+category: dependencies
+sub_category: validate_packages
+description: >-
+  Scan every package automatically for ownership change.
+rationale: >-
+  A change in package ownership is not a regular action. In some cases it can lead to a 
+  massive problem (for example, the "event-stream" incident). Open-source contributors 
+  are not always trusted, since by its very nature everyone can contribute. This means 
+  malicious actors can become contributors as well. Package maintainers might transfer 
+  their ownership to someone they do not know if maintaining the package is too much for 
+  them, in some cases without the other user's knowledge. This has led to known security 
+  breaches in the past. It is best to be aware of such activity as soon as it happens and to 
+  carefully examine the situation before continuing using the package in order to 
+  determine its safety.
+impact: >-
+audit: >-
+  Ensure automatic scanning of packages for ownership change is set.
+remediation: >-
+  Set automatic scanning of packages for ownership change.
+default_value:
+references:
+  - https://blog.npmjs.org/post/182828408610/the-security-risks-of-changing-package-owners.html
+  - https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident
+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/dependencies_3/validate_packages_3_2/package_vuln_scanning.yml

@@ -0,0 +1,62 @@
+---
+id: 3.2.2
+name: package_vuln_scanning
+title: Ensure packages are automatically scanned for known vulnerabilities
+profile: 1
+category: dependencies
+sub_category: validate_packages
+description: >-
+  Automatically scan every package for vulnerabilities.
+rationale: >-
+  Automatic scanning for vulnerabilities detects known vulnerabilities in packages and 
+  dependencies in use, allowing faster patching when one is found. Such vulnerabilities 
+  can lead to a massive breach if not handled as fast as possible, as attackers will also 
+  know about those vulnerabilities and swiftly try to take advantage of them. Scanning 
+  packages regularly for vulnerabilities can also verify usage compliance with the 
+  organization's security policy.
+impact: >-
+audit: >-
+  Once Dependency Scanning is enabled for your project, continuous scanning of 
+  packages for dependency vulnerabilities is enabled.
+remediation: |
+  Enable Dependency scanning in order to automatically scan packages for vulnerabilities. To enable the analyzer, either:
+    • Enable Auto DevOps, which includes dependency scanning.
+    • Edit the .gitlab-ci.yml file manually. Use this method if your .gitlab-ci.yml file is complex.
+    • Use a preconfigured merge request.
+    • Create a scan execution policy that enforces dependency scanning.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/continuous_vulnerability_scanning/
+  - https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html#enabling-the-analyzer
+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
+additional_info: >-

gitlabcis/recommendations/dependencies_3/validate_packages_3_2/readme.md

@@ -0,0 +1,10 @@
+# 3.2 Validate Packages
+
+This section consists of security recommendations for managing package validations and checks. Third-party packages and dependencies might put the organization in danger, not only by being vulnerable to attacks, but also by being improperly used and harming license conditions. To protect the software supply chain from these dangers, it is important to validate packages and understand how and if to use them. This section's recommendations cover this topic.
+
+## Recommendations
+
+* [3.2.1 - org_wide_dependency_policy.yml](./org_wide_dependency_policy.yml)
+* [3.2.2 - package_vuln_scanning.yml](./package_vuln_scanning.yml)
+* [3.2.3 - package_license_scanning.yml](./package_license_scanning.yml)
+* [3.2.4 - package_ownership_change.yml](./package_ownership_change.yml)

gitlabcis/recommendations/deployment_5/deployment_configuration_5_1/audit_deployment_config.yml

@@ -0,0 +1,46 @@
+---
+id: 5.1.2
+name: audit_deployment_config
+title: Ensure changes in deployment configuration are audited
+profile: 1
+category: deployment
+sub_category: deployment_configuration
+description: >-
+  Audit and track changes made in deployment configuration.
+rationale: >-
+  Deployment configuration is sensitive in nature. The tiniest mistake can lead to 
+  downtime or bugs in production, which consequently may have a direct effect on both 
+  product integrity and customer trust. Misconfigurations might also be used by malicious 
+  actors to attack the production platform. Because of this, every change in the 
+  configuration needs a review and possible "revert" in case of a mistake or malicious 
+  change. Auditing every change and tracking them helps detect and fix such incidents 
+  more quickly.
+impact: >-
+audit: >-
+  For each deployment configuration, ensure changes made to it are audited and tracked.
+remediation: >-
+  For each deployment configuration, track and audit changes made to it.
+default_value:
+references:
+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/deployment_5/deployment_configuration_5_1/limit_deployment_config_access.yml

@@ -0,0 +1,51 @@
+---
+id: 5.1.4
+name: limit_deployment_config_access
+title: Limit access to deployment configurations
+profile: 1
+category: deployment
+sub_category: deployment_configuration
+description: >-
+  Restrict access to the deployment configuration to trusted and qualified users only.
+rationale: >-
+  Deployment configurations are sensitive in nature. The tiniest mistake can lead to 
+  downtime or bugs in production, which can have a direct effect on the product's integrity 
+  and customer trust. Misconfigurations might also be used by malicious actors to attack 
+  the production platform. To avoid such harm as much as possible, ensure only trusted 
+  and qualified users have access to such configurations. This will also reduce the 
+  number of accounts that might affect the environment in case of an attack.
+impact: >-
+  Reducing the number of users who have access to the deployment configuration means 
+  those users would lose their ability to make direct changes to that configuration.
+audit: >-
+  Verify each deployment configuration is accessible only to known and authorized users.
+remediation: >-
+  Restrict access to the deployment configuration to trusted and qualified users.
+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/deployment_5/deployment_configuration_5_1/pin_deployment_config_manifests.yml

@@ -0,0 +1,59 @@
+---
+id: 5.1.7
+name: pin_deployment_config_manifests
+title: Ensure deployment configuration manifests are pinned to a specific, verified version
+profile: 1
+category: deployment
+sub_category: deployment_configuration
+description: >-
+  Deployment configuration is often stored in a version control system and is pulled from 
+  there. Pin the configuration used to a specific, verified version or commit Secure Hash 
+  Algorithm (SHA). Avoid referring configuration without its version tag specified.
+rationale: >-
+  Deployment configuration manifests are often stored in version control systems and 
+  pulled from there either by automation platforms, for example Ansible, or GitOps 
+  platforms, such as ArgoCD. When a manifest is pulled from a version control system 
+  without tag or commit Secure Hash Algorithm (SHA) specified, it is pulled from the 
+  HEAD revision, which is equal to the 'latest' tag, and pulls the last change made. This 
+  increases the risk of encountering a new, potentially malicious configuration. If an 
+  attacker pushes malicious configuration to the version control system, the next user who 
+  pulls the HEAD revision will pull it and risk attack. To avoid that risk, use a version tag of 
+  verified version or a commit SHA of a trusted commit, which will ensure this is the only 
+  version pulled.
+impact: >-
+  Changes in deployment configuration will not be pulled unless their version tag or 
+  commit Secure Hash Algorithm (SHA) is specified. This might slow down the 
+  deployment process.
+audit: >-
+  For every deployment configuration manifest in use, ensure it is pinned to a specific 
+  version or commit Secure Hash Algorithm (SHA).
+remediation: >-
+  For every deployment configuration manifest in use, pin to a specific version or commit 
+  Secure Hash Algorithm (SHA).
+default_value:
+references:
+cis_controls:
+  - id: 4.1
+    version: 8
+    name: Establish and Maintain a Secure Configuration Process
+    description: >-
+      Establish and maintain a secure configuration process for enterprise assets 
+      (end-user devices, including portable and mobile, non-computing/IoT devices, and 
+      servers) and software (operating systems and applications). Review and update 
+      documentation annually, or when significant enterprise changes occur that could 
+      impact this Safeguard.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 5.1
+    version: 7
+    name: Establish Secure Configurations
+    description: >-
+      Maintain documented, standard security configuration standards for all 
+      authorized operating systems and software.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/deployment_5/deployment_configuration_5_1/readme.md

@@ -0,0 +1,13 @@
+# 5.1 Deployment Configuration
+
+This section consists of security recommendations for the management of the deployment configuration. This consists of the files, instructions, and access management of the deployment configuration. Usually, the configuration files are stored in a version control system, so they need to be protected in it as well.
+
+## Recommendations
+
+* [5.1.1 - separate_deployment_config.yml](./separate_deployment_config.yml)
+* [5.1.2 - audit_deployment_config.yml](./audit_deployment_config.yml)
+* [5.1.3 - secret_scan_deployment_config.yml](./secret_scan_deployment_config.yml)
+* [5.1.4 - limit_deployment_config_access.yml](./limit_deployment_config_access.yml)
+* [5.1.5 - scan_iac.yml](./scan_iac.yml)
+* [5.1.6 - verify_deployment_config.yml](./verify_deployment_config.yml)
+* [5.1.7 - pin_deployment_config_manifests.yml](./pin_deployment_config_manifests.yml)

gitlabcis/recommendations/deployment_5/deployment_configuration_5_1/scan_iac.yml

@@ -0,0 +1,72 @@
+---
+id: 5.1.5
+name: scan_iac
+title: Detect and prevent misconfigurations or insecure instructions in Infrastructure as Code (IaC) files, such as Terraform files.
+profile: 2
+category: deployment
+sub_category: deployment_configuration
+description: >-
+  Detect and prevent misconfigurations or insecure instructions in Infrastructure as Code 
+  (IaC) files, such as Terraform files.
+rationale: >-
+  Infrastructure as Code (IaC) files are used for production environment and application 
+  deployment. These are sensitive parts of the software supply chain because they are 
+  always in touch with customers, and thus might affect their opinion of or trust in the 
+  product. Attackers often target these environments. Detecting and fixing 
+  misconfigurations and/or insecure instructions in IaC 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 might 
+  ultimately lead to easier ways to attack and steal organization data.
+impact: >-
+audit: >-
+  For every Infrastructure as Code (IaC) instructions file, verify that scanners are set to 
+  identify and prevent misconfigurations and insecure instructions.
+remediation: >-
+  For every Infrastructure as Code (IaC) instructions file, set scanners to identify and 
+  prevent misconfigurations and insecure instructions.
+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: 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: >-

gitlabcis/recommendations/deployment_5/deployment_configuration_5_1/secret_scan_deployment_config.yml

@@ -0,0 +1,45 @@
+---
+id: 5.1.3
+name: secret_scan_deployment_config
+title: Ensure scanners are in place to identify and prevent sensitive data in deployment configuration
+profile: 1
+category: deployment
+sub_category: deployment_configuration
+description: >-
+  Detect and prevent sensitive data - such as confidential ID numbers, passwords, etc. -
+  in deployment configurations.
+rationale: >-
+  Sensitive data in deployment configurations might create a major incident if an attacker 
+  gains access to it, as this can cause data loss and theft. It is important to keep sensitive 
+  data safe and to not expose it in the configuration. In order to prevent a possible 
+  exposure, set scanners that will identify and prevent such data in deployment 
+  configurations.
+impact: >-
+audit: >-
+  For each deployment configuration file, verify that scanners are set to identify and 
+  prevent the existence of sensitive data within it.
+remediation: >-
+  For each deployment configuration file, set scanners to identify and prevent sensitive 
+  data within it.
+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: 3.1
+    version: 7
+    name: Run Automated Vulnerability Scanning Tools
+    description: >-
+      Utilize an up-to-date SCAP-compliant vulnerability scanning tool to 
+      automatically scan all systems on the network on a weekly or more frequent basis 
+      to identify all potential vulnerabilities on the organization's systems.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/deployment_5/deployment_configuration_5_1/separate_deployment_config.yml

@@ -0,0 +1,50 @@
+---
+id: 5.1.1
+name: separate_deployment_config
+title: Ensure deployment configuration files are separated from source code
+profile: 2
+category: deployment
+sub_category: deployment_configuration
+description: >-
+  Deployment configurations are often stored in a version control system. Separate 
+  deployment configuration files from source code repositories.
+rationale: >-
+  Deployment configuration manifests are often stored in version control systems. Storing 
+  them in dedicated repositories, separately from source code repositories, has several 
+  benefits. First, it adds order to both maintenance and version control history. This 
+  makes it easier to track code or manifest changes, as well as spot any malicious code 
+  or misconfigurations. Second, it helps achieve the Least Privilege principle. Because 
+  access can be configured differently for each repository, fewer users will have access to 
+  this configuration, which is typically sensitive.
+impact: >-
+audit: >-
+  Ensure each deployment configuration file is stored separately from source code.
+remediation: >-
+  Store each deployment configuration file in a dedicated repository separately from 
+  source code.
+default_value:
+references:
+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 and Maintain a Secure Application Development Process
+    description: >-
+      Establish secure coding practices appropriate to the programming language and 
+      development environment being used.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/deployment_5/deployment_configuration_5_1/verify_deployment_config.yml

@@ -0,0 +1,49 @@
+---
+id: 5.1.6
+name: verify_deployment_config
+title: Ensure deployment configuration manifests are verified
+profile: 1
+category: deployment
+sub_category: deployment_configuration
+description: >-
+  Verify the deployment configuration manifests.
+rationale: >-
+  To ensure that the configuration manifests used are trusted and have not been infected 
+  by malicious actors before arriving at the platform, it is important to verify the manifests. 
+  This may be done by comparing the checksum of the manifest file to its checksum in a 
+  trusted source. If a difference arises, this is a sign that an unknown actor has interfered 
+  and may have added malicious instructions. If this manifest is used, it might harm the 
+  environment and application deployment, which could end in a massive breach and 
+  leave the organization exposed to data leaks, etc.
+impact: >-
+audit: >-
+  For each deployment configuration manifest in use, ensure it has been verified.
+remediation: >-
+  Verify each deployment configuration manifest in use.
+default_value:
+references:
+cis_controls:
+  - id: 4.1
+    version: 8
+    name: Establish and Maintain a Secure Configuration Process
+    description: >-
+      Establish and maintain a secure configuration process for enterprise assets 
+      (end-user devices, including portable and mobile, non-computing/IoT devices, and 
+      servers) and software (operating systems and applications). Review and update 
+      documentation annually, or when significant enterprise changes occur that could 
+      impact this Safeguard.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 5.1
+    version: 7
+    name: Establish Secure Configurations
+    description: >-
+      Maintain documented, standard security configuration standards for all 
+      authorized operating systems and software
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-