gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/deployment_5/deployment_environment_5_2/automate_deployment.yml

@@ -0,0 +1,47 @@
+---
+id: 5.2.1
+name: automate_deployment
+title: Ensure deployments are automated
+profile: 1
+category: deployment
+sub_category: deployment_environment
+description: >-
+  Automate deployments of production environment and application.
+rationale: >-
+  Automating the deployments of both production environment and applications reduces 
+  the risk for human mistakes — such as a wrong configuration or exposure of sensitive 
+  data — because it requires less human interaction or intervention. It also eases 
+  redeployment of the environment. It is best to automate with Infrastructure as Code 
+  (IaC) because it offers more control over changes made to the environment creation 
+  configuration and stores to a version control platform.
+impact: >-
+audit: >-
+  For each deployment process, ensure it is automated.
+remediation: >-
+  Automate each deployment process of the production environment and application.
+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_environment_5_2/disable_default_passwords.yml

@@ -0,0 +1,63 @@
+---
+id: 5.2.4
+name: disable_default_passwords
+title: Ensure default passwords are not used
+profile: 1
+category: deployment
+sub_category: deployment_environment
+description: >-
+  Do not use default passwords of deployment tools and components.
+rationale: >-
+  Many deployment tools and components are provided with default passwords for the 
+  first login. This password is intended to be used only on the first login and should be 
+  changed immediately after. Using the default password substantially increases the 
+  attack risk. It is very important to ensure that default passwords are not used in 
+  deployment tools and components.
+impact: >-
+audit: |
+  GitLab's default root password depends on the installation method, and when the installation occurred:
+    1. When deploying a GitLab instance using the official AWS AMI, the root password to the instance is the EC2 Instance ID
+    2. Most installation methods allow a non-default password to be provided as configuration
+    3. Prior to 14.0 the default password was 5iveL!fe
+    4. Otherwise the default password is unique and randomly generated.
+
+  Attempt to log in as root using a suspected default password to audit whether it has changed.
+  For any other external build tools, ensure the password used is not the default one.
+remediation: >-
+  GitLab's root password can be changed by an administrator using the UI, the 
+  “gitlab:password:reset” rake task, or by using the Rails console. 
+  For each build tool with a default password, change to a unique cryptographically 
+  secure pseudorandom password.
+default_value:
+references:
+cis_controls:
+  - id: 5.2
+    version: 8
+    name: Use Unique Passwords
+    description: >-
+      Use unique passwords for all enterprise assets. Best practice implementation 
+      includes, at a minimum, an 8-character password for accounts using MFA and a 
+      14-character password for accounts not using MFA.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 4.2
+    version: 7
+    name: Change Default Passwords
+    description: >-
+      Before deploying any new asset, change all default passwords to have values 
+      consistent with administrative level accounts.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 4.4
+    version: 7
+    name: example
+    description: >-
+      Use Unique Passwords
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/deployment_5/deployment_environment_5_2/limit_prod_access.yml

@@ -0,0 +1,45 @@
+---
+id: 5.2.3
+name: limit_prod_access
+title: Ensure access to production environment is limited
+profile: 1
+category: deployment
+sub_category: deployment_environment
+description: >-
+  Restrict access to the production environment to a few trusted and qualified users only.
+rationale: >-
+  The production environment is an extremely sensitive one. It directly affects the 
+  customer experience and trust in a product, which has serious effects on the 
+  organization itself. Because of this sensitive nature, it is important to restrict access to 
+  the production environment to only a few trusted and qualified users. This will reduce 
+  the risk of mistakes such as exposure of secrets or misconfiguration. This restriction 
+  also reduces the number of accounts that are vulnerable to hijacking in order to 
+  potentially harm the production environment.
+impact: >-
+  Reducing the number of users who have access to the production environment means 
+  those users would lose their ability to make direct changes to that environment.
+audit: >-
+  Verify that the production environment is accessible only to trusted and qualified users.
+remediation: >-
+  Restrict access to the production environment to trusted and qualified users.
+default_value:
+references:
+cis_controls:
+  - id: 16.8
+    version: 8
+    name: Separate Production and Non-Production Systems
+    description: >-
+      Maintain separate environments for production and non-production systems.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 18.9
+    version: 7
+    name: Separate Production and Non-Production Systems
+    description: >-
+      Maintain separate environments for production and nonproduction systems. 
+      Developers should not have unmonitored access to production environments.
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/deployment_5/deployment_environment_5_2/readme.md

@@ -0,0 +1,12 @@
+# 5.2 Deployment Environment
+
+This section consists of security recommendations for the management of the deployment environment.
+
+The deployment environment is the orchestrator and the production environment where the application is deployed. It directly affects the customer experience and trust in a product, which has serious effects on the organization itself. Securing it varies from access management to automation.
+
+## Recommendations
+
+* [5.2.1 - automate_deployment.yml](./automate_deployment.yml)
+* [5.2.2 - reproducible_deployment.yml](./reproducible_deployment.yml)
+* [5.2.3 - limit_prod_access.yml](./limit_prod_access.yml)
+* [5.2.4 - disable_default_passwords.yml](./disable_default_passwords.yml)

gitlabcis/recommendations/deployment_5/deployment_environment_5_2/reproducible_deployment.yml

@@ -0,0 +1,50 @@
+---
+id: 5.2.2
+name: reproducible_deployment
+title: Ensure the deployment environment is reproducible
+profile: 1
+category: deployment
+sub_category: deployment_environment
+description: >-
+  Verify that the deployment environment - the orchestrator and the production 
+  environment where the application is deployed - is reproducible. This means that the 
+  environment stays the same in each deployment if the configuration has not changed.
+rationale: >-
+  A reproducible build is a build that produces the same artifact when given the same 
+  input data, and in this case the same environment. Ensuring that the same environment 
+  is produced when given the same input helps verify that no change has been made to it. 
+  This action allows an organization to trust that its deployment environment is built only 
+  from safe code and configuration that has been reviewed and tested and has not been 
+  tainted or changed abruptly.
+impact: >-
+audit: >-
+  Verify that the deployment/production environment is reproducible.
+remediation: >-
+  Adjust the process that deploys the deployment/production environment to build the 
+  same environment each time when the configuration has not changed.
+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/readme.md

@@ -0,0 +1,10 @@
+# 5 Deployment
+
+This section consists of security recommendations for management of the release process, the application deployment, and the configuration files that comes with it.
+
+This is the final phase of the software supply chain. After that, the client already uses the application, and it is running in production. This phase contains the deployment orchestrator, the deployment configuration, the manifest files, and the deployment environment. It is important to secure all of these to deliver the software to the client safely.
+
+## Sections
+
+- [5.1 - Deployment Configuration](./deployment_configuration_5_1)
+- [5.2 - Deployment Environment](./deployment_environment_5_2)

gitlabcis/recommendations/readme.md

@@ -0,0 +1,24 @@
+# Controls
+
+* [1 - Source Code](./source_code_1)
+  * [1.1 - Code Changes](./source_code_1/code_changes_1_1)
+  * [1.2 - Repository Management](./source_code_1/repository_management_1_2)
+  * [1.3 - Contribution Access](./source_code_1/contribution_access_1_3)
+  * [1.4 - Third-Party](./source_code_1/third_party_1_4)
+  * [1.5 - Code Risks](./source_code_1/code_risks_1_5)
+* [2 - Build Pipelines](./build_pipelines_2)
+  * [2.1 - Build Environment](./build_pipelines_2/build_environment_2_1)
+  * [2.2 - Build Worker](./build_pipelines_2/build_worker_2_2)
+  * [2.3 - Pipeline Instructions](./build_pipelines_2/pipeline_instructions_2_3)
+  * [2.4 - Pipeline Integrity](./build_pipelines_2/pipeline_integrity_2_4)
+* [3 - Dependencies](./dependencies_3)
+  * [3.1 - Third-Party Packages](./dependencies_3/third_party_packages_3_1)
+  * [3.2 - Validate Packages](./dependencies_3/validate_packages_3_2)
+* [4 - Artifacts](./artifacts_4)
+  * [4.1 - Verification](./artifacts_4/verification_4_1)
+  * [4.2 - Access to Artifacts](./artifacts_4/access_to_artifacts_4_2)
+  * [4.3 - Package Registries](./artifacts_4/package_registries_4_3)
+  * [4.4 - Origin Traceability](./artifacts_4/origin_traceability_4_4)
+* [5 - Deployment](./deployment_5)
+  * [5.1 - Deployment Configuration](./deployment_5/deployment_configuration_5_1)
+  * [5.2 - Deployment Environment](./deployment_5/deployment_environment_5_2)

gitlabcis/recommendations/source_code_1/code_changes_1_1/audit_branch_protections.yml

@@ -0,0 +1,56 @@
+---
+id: 1.1.19
+name: audit_branch_protections
+title: Ensure any changes to branch protection rules are audited
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure that changes in the branch protection rules are audited.
+rationale: >-
+  Branch protection rules should be configured on every repository. The only users who 
+  may change such rules are administrators. In a case of an attack on an administrator 
+  account or of human error on the part of an administrator, protection rules could be 
+  disabled, and thus decrease source code confidentiality as a result. It is important to 
+  track and audit such changes to prevent potential incidents as soon as possible.
+impact: >-
+audit: |
+  Ensure that changes in the branch protection rules are audited regularly. You can view audit events from user actions across an entire GitLab instance.
+
+  To view instance audit events:
+    1. On the left sidebar, select Search or go to.
+    2. Select Admin Area.
+    3. On the left sidebar, select Monitoring > Audit Events.
+    4. Filter by the following:Event Type protected_branch_updated. This event type is triggered when the setting for protected branches is updated.
+    5. Ensure every action is reasonable and secure and is investigated if not.
+remediation: |
+  Use the audit log to audit changes in branch protection rules by performing the following:
+    1. On the left sidebar, select Search or go to.
+    2. Select Admin Area.
+    3. On the left sidebar, select Monitoring > Audit Events.
+    4. Filter by the following:Event Type protected_branch_updated
+    5. Ensure every action is reasonable and secure and is investigated if not.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/audit_event_streaming/audit_event_types.html
+cis_controls:
+  - id: 8.5
+    version: 8
+    name: Collect Detailed Audit Logs
+    description: >-
+      Configure detailed audit logging for enterprise assets containing sensitive data. 
+      Include event source, date, username, timestamp, source addresses, destination 
+      addresses, and other useful elements that could assist in a forensic investigation.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 6.2
+    version: 8
+    name: Activate audit logging
+    description: >-
+      Ensure that local logging has been enabled on all systems and networking devices.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/code_changes_1_1/auto_risk_scan_merges.yml

@@ -0,0 +1,62 @@
+---
+id: 1.1.18
+name: auto_risk_scan_merges
+title: Ensure any merging of code is automatically scanned for risks
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure that every merge request is required to be scanned for risks.
+rationale: >-
+  Scanning merge requests to detect risks allows for early detection of vulnerable code 
+  and/or dependencies and helps mitigate potentially malicious code.
+impact: >-
+audit: |
+  For each project in use, ensure that every merge request must be scanned for risks by performing the following:
+  On the left sidebar, select Search or go to and search for the go-example-a project.
+    1. Go to Secure > Policies.
+    2. Review your list of existing policies. The Policy Type column will indicate whether you have enabled a Scan Execution Policy for the specified project.
+    3. Click on the Name in order to view the policy details which specifies which scanners run when code is merged.
+remediation: |
+  For each project in use, ensure that every merge request must be scanned for risks by creating a scan execution policy:
+  1. On the left sidebar, select Search or go to and search for the go-example-a project.
+  2. Go to Secure > Policies.
+  3. Select New policy.
+  4. In the Scan execution policy section, select Select policy.
+  5. Complete the fields.
+    • Name: Enforce secret detection.
+    • Policy status: Enabled.
+    • Actions: Run a Secret Detection scan.
+    • Conditions: Triggers every time a pipeline runs for all branches.
+  6. Select Configure with a merge request.
+     The policy project go-example-a - Security project is created, and a merge request is created.
+  7. Optional. Review the generated policy YAML in the merge request's Changes tab.
+  8. Go to the Overview tab and select Merge.
+  9. On the left sidebar, select Search or go to and search for the go-example-a project.
+  10. Go to Secure > Policies.
+
+  You now have a scan execution policy that runs a secret detection scan on every MR,
+  for any branch. Test the policy by creating a merge request in project A.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/application_security/index.html#enforce-scan-execution
+  - https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.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: 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: >-

gitlabcis/recommendations/source_code_1/code_changes_1_1/branch_protections_for_admins.yml

@@ -0,0 +1,60 @@
+---
+id: 1.1.14
+name: branch_protections_for_admins
+title: Ensure branch protection rules are enforced for administrators
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure administrators are subject to branch protection rules.
+rationale: >-
+  Administrators by default are excluded from any branch protection rules. This means 
+  these privileged users (both on the repository and organization levels) are not subject to 
+  protections meant to prevent untrusted code insertion, including malicious code. This is 
+  extremely important since administrator accounts are often targeted for account 
+  hijacking due to their privileged role.
+impact: >-
+  Administrator users won't be able to push code directly to the protected branch without 
+  being compliant with listed branch protection rules.
+audit: |
+  GitLab administrators can validate this privilege for group owners, enforcing the instance-level protection rule:
+    1. Select Settings > Repository.
+    2. On the left sidebar, at the bottom, select Admin Area.
+    3. Expand the Default branch section.
+    4. Ensure that the Allow owners to manage default branch protection per group is unchecked.
+    5. Select Save changes.
+remediation: |
+  GitLab administrators can disable this privilege for group owners, enforcing the instance-level protection rule:
+    1. On the left sidebar, at the bottom, select Admin Area.
+    2. Select Settings > Repository.
+    3. Expand the Default branch section.
+    4. Uncheck Allow owners to manage default branch protection per group checkbox.
+    5. Select Save changes.
+default_value: Administrator accounts are not subject to branch protection rules by default.
+references:
+  - https://docs.gitlab.com/ee/user/project/repository/branches/default.html
+  - https://docs.gitlab.com/ee/user/project/protected_branches.html#who-can-modify-a-protected-branch
+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/branches_updated_before_merging.yml

@@ -0,0 +1,56 @@
+---
+id: 1.1.10
+name: branches_updated_before_merging
+title: Ensure open Git branches are up to date before they can be merged into code base
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Organizations should make sure each suggested code change is in full sync with the 
+  existing state of its origin code repository before allowing merging.
+rationale: >-
+  Git branches can easily become outdated since the origin code repository is constantly 
+  being edited. This means engineers working on separate code branches can 
+  accidentally include outdated code with potential security issues which might have 
+  already been fixed, overriding the potential solutions for those security issues when 
+  merging their own changes.
+impact: >-
+  If enforced, outdated branches would not be able to be merged into their origin 
+  repository without first being updated to contain any recent changes.
+audit: |
+  For each project, verify that open branches must be updated before merging by performing the following:
+    • Navigate to the main page of the project
+    • In the sidebar, select Settings > Merge requests
+    • Look at the 'Merge method'. If 'Merge commit with semi-linear history' or 'Fast-forward merge' is selected, the project is compliant.
+remediation: |
+  For each project identified as being non-compliant, performing the following:
+    • Navigate to the main page of the project
+    • In the sidebar, select Settings > Merge requests
+    • Under the 'Merge method' select either 'Merge commit with semi-linear history' or 'Fast-forward merge'.
+default_value: By default, there is no requirement to update a branch before merging it.
+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/checks_pass_before_merging.yml

@@ -0,0 +1,57 @@
+---
+id: 1.1.9
+name: checks_pass_before_merging
+title: Ensure all checks have passed before merging new code
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Before a code change request can be merged to the code base, all predefined checks 
+  must successfully pass.
+rationale: >-
+  On top of manual reviews of code changes, a code protect should contain a set of 
+  prescriptive checks which validate each change. Organizations should enforce those 
+  status checks so that changes can only be introduced if all checks have successfully 
+  passed. This set of checks should serve as the absolute quality, stability, and security 
+  conditions which must be met in order to merge new code to a project.
+impact: >-
+  Code changes in which all checks do not pass successfully would not be able to be 
+  pushed into the code base of the specific code repository.
+audit: |
+  Within each project's settings, you can see a list of status check services added to the project:
+    1. In your project, go to Settings > Merge requests section.
+    2. Scroll down to Status checks.
+    3. Ensure that the Status checks must succeed checkbox has been selected.
+remediation: |
+  To block the merging of merge requests when checks fail:
+    1. On the left sidebar, select Search or go to and find your project.
+    2. Select Settings > Merge requests.
+    3. Select the Status checks must succeed checkbox.
+    4. Select Save changes.
+default_value: By default, no checks are defined per project, and thus no enforcement of checks is made.
+references:
+  - https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.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_approval_dismissals.yml

@@ -0,0 +1,62 @@
+---
+id: 1.1.4
+name: code_approval_dismissals
+title: Ensure previous approvals are dismissed when updates are introduced to a code change proposal
+profile: 1
+category: source_code
+sub_category: code_changes
+description: >-
+  Ensure that when a proposed code change is updated, previous approvals are declined, 
+  and new approvals are required.
+rationale: >-
+  An approval process is necessary when code changes are suggested. Through this 
+  approval process, however, changes can still be made to the original proposal even 
+  after some approvals have already been given. This means malicious code can find its 
+  way into the code base even if the organization has enforced a review policy. To ensure 
+  this is not possible, outdated approvals must be declined when changes to the 
+  suggestion are introduced.
+impact: >-
+  If new code changes are pushed to a specific proposal, all previously accepted code 
+  change proposals must be declined.
+audit: |
+  For each code repository in use, perform the next steps to verify that each updated code suggestion declines the previously received approvals:
+    • On GitLab, navigate to the main page of a repository.
+    • Navigate to Settings > Merge Requests.
+    • Click Expand next to the Merge Request Approvals section.
+    • Verify the repository has merge request approvals configured on all protected branches.
+    • Verify that "Remove all approvals" is selected under Approval Settings for "When a commit is added".
+remediation: |
+  For each code repository in use, perform the next steps to enforce dismissal of given approvals to code change suggestions if those suggestions were updated:
+    • On GitLab, navigate to the main page of a repository.
+    • Navigate to Settings > Merge Requests.
+    • Click Expand next to the Merge Request Approvals section.
+    • Configure approval rules and a list of eligible approvers for all protected branches (or all branches).
+    • Select Remove all approvals under "When a commit is added".
+    • Click Save changes
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/merge_requests/approvals/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: >-