gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/artifacts_4/readme.md

@@ -0,0 +1,12 @@
+# 4 Artifacts
+
+This section consists of security recommendations for the management of artifacts produced by build pipelines, as well as ones used by the application in the build process itself.
+
+Artifacts are packaged versions of software. They are stored in package registries (or artifact managers) and require securing from the moment they are created, through the time they are copied and updated, and up to deployment to their relevant environment.
+
+## Sections
+
+- [4.1 - Verification](./verification_4_1/)
+- [4.2 - Access to Artifacts](./access_to_artifacts_4_2/)
+- [4.3 - Package Registries](./package_registries_4_3/)
+- [4.4 - Origin Traceability](./origin_traceability_4_4/)

gitlabcis/recommendations/artifacts_4/verification_4_1/encrypt_artifacts_before_distribution.yml

@@ -0,0 +1,47 @@
+---
+id: 4.1.2
+name: encrypt_artifacts_before_distribution
+title: Ensure artifacts are encrypted before distribution
+profile: 1
+category: artifacts
+sub_category: verification
+description: >-
+  Encrypt artifacts before they are distributed and ensure only trusted platforms have 
+  decryption capabilities.
+rationale: >-
+  Build artifacts might contain sensitive data such as production configurations. In order to 
+  protect them and decrease the risk for breach, it is recommended to encrypt them 
+  before delivery. Encryption makes data unreadable, so even if attackers gain access to 
+  these artifacts, they won't be able to harvest sensitive data from them without the 
+  decryption key.
+impact: >-
+audit: >-
+  Ensure every artifact is encrypted before it is delivered.
+remediation: >-
+  Encrypt every artifact before distribution.
+default_value: Artifacts do not get encrypted by default.
+references:
+cis_controls:
+  - id: 3.11
+    version: 8
+    name: Encrypt Sensitive Data at Rest
+    description: >-
+      Encrypt sensitive data at rest on servers, applications, and databases containing 
+      sensitive data. Storage-layer encryption, also known as server-side encryption, 
+      meets the minimum requirement of this Safeguard. Additional encryption methods 
+      may include application-layer encryption, also known as client-side encryption, 
+      where access to the data storage device(s) does not permit access to the plain-text 
+      data.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 14.8
+    version: 7
+    name: Encrypt Sensitive Information at Rest
+    description: >-
+      Encrypt all sensitive information at rest using a tool that requires a secondary 
+      authentication mechanism not integrated into the operating system, in order to 
+      access the information.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/artifacts_4/verification_4_1/only_authorized_platforms_can_decrypt_artifacts.yml

@@ -0,0 +1,59 @@
+---
+id: 4.1.3
+name: only_authorized_platforms_can_decrypt_artifacts
+title: Ensure only authorized platforms have decryption capabilities of artifacts
+profile: 1
+category: artifacts
+sub_category: verification
+description: >-
+  Grant decryption capabilities of artifacts only to trusted and authorized platforms.
+rationale: >-
+  Build artifacts might contain sensitive data such as production configuration. To protect 
+  them and decrease the risk of a breach, it is recommended to encrypt them before 
+  delivery. This will make them unreadable for every unauthorized user who doesn't have 
+  the decryption key. By implementing this, the decryption capabilities become overly 
+  sensitive in order to prevent a data leak or theft. Ensuring that only trusted and 
+  authorized platforms can decrypt the organization's packages decreases the possibility 
+  for an attacker to gain access to the critical data in artifacts.
+impact: >-
+audit: >-
+  Ensure only trusted and authorized platforms have decryption capabilities of the 
+  organization's artifacts.
+remediation: >-
+  Grant decryption capabilities of the organization's artifacts only for trusted and 
+  authorized platforms.
+default_value:
+references:
+cis_controls:
+  - id: 2.5
+    version: 8
+    name: Allowlist Authorized Software
+    description: >-
+      Use technical controls, such as application allowlisting, to ensure that only 
+      authorized software can execute or be accessed. Reassess bi-annually, or more 
+      frequently.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.6
+    version: 8
+    name: Allowlist Authorized Libraries
+    description: >-
+      Use technical controls to ensure that only authorized software libraries, such 
+      as specific .dll, .ocx, .so, etc., files, are allowed to load into a system process. 
+      Block unauthorized libraries from loading into a system process. Reassess bi-
+      annually, or more frequently.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.7
+    version: 8
+    name: Allowlist Authorized Scripts
+    description: >-
+      Use technical controls, such as digital signatures and version control, to ensure 
+      that only authorized scripts, such as specific .ps1, .py, etc., files, are allowed to 
+      execute. Block unauthorized scripts from executing. Reassess bi-annually, or more 
+      frequently
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/artifacts_4/verification_4_1/readme.md

@@ -0,0 +1,11 @@
+# 4.1 Verification
+
+This section consists of security recommendations for managing verification of artifacts.
+
+When build artifacts are being pushed to the registry, a lot of different attacks can happen: a malicious artifact with the same name can be pushed, the artifact can be stolen over the network or if the registry is hacked, etc. It is important to secure artifacts by ensuring various verification methods, listed in the recommendations in this section, are available.
+
+## Recommendations
+
+* [4.1.1 - sign_artifacts_in_build_pipeline.yml](./sign_artifacts_in_build_pipeline.yml)
+* [4.1.2 - encrypt_artifacts_before_distribution.yml](./encrypt_artifacts_before_distribution.yml)
+* [4.1.3 - only_authorized_platforms_can_decrypt_artifacts.yml](./only_authorized_platforms_can_decrypt_artifacts.yml)

gitlabcis/recommendations/artifacts_4/verification_4_1/sign_artifacts_in_build_pipeline.yml

@@ -0,0 +1,40 @@
+---
+id: 4.1.1
+name: sign_artifacts_in_build_pipeline
+title: Ensure all artifacts are signed by the build pipeline itself
+profile: 2
+category: artifacts
+sub_category: verification
+description: >-
+  Configure the build pipeline to sign every artifact it produces and verify that each artifact 
+  has the appropriate signature.
+rationale: >-
+  A cryptographic signature can be used to verify artifact authenticity. The signature 
+  created with a certain key is unique and not reversible, thus making it unique to the 
+  author. This means that an attacker tampering with a signed artifact will be noticed 
+  immediately using a simple verification step because the signature will change. Signing 
+  artifacts by the build pipeline that produces them ensures the integrity of those artifacts.
+impact: >-
+audit: >-
+  Verify that the build pipeline signs every new artifact it produces and all artifacts are signed. 
+  There are many different signing tools or options each have there own method or 
+  commands to verify that the code or package created is signed.
+remediation: >-
+  Sign every artifact produced with the build pipeline that created it. Configure the build 
+  pipeline to sign each artifact.
+default_value: Artifacts are not signed by Default.
+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/build_pipelines_2/build_environment_2_1/authenticate_build_access.yml

@@ -0,0 +1,55 @@
+---
+id: 2.1.6
+name: authenticate_build_access
+title: Ensure users must authenticate to access the build environment
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Require users to login in to access the build environment - where the orchestrator, the
+  pipeline executer, where the build workers are running, etc.
+rationale: >-
+  Requiring users to authenticate and disabling anonymous access to the build 
+  environment allows organization to track every action on that environment, good or bad, 
+  to its actor. This will help recognizing attack and its attacker becuase the authentication 
+  is required.
+impact: >-
+  Anonymous users won't be able to access the build environment.
+audit: |
+  Ensure authentication is required to access the build environment.
+  In GitLab, viewing environments in private projects is limited to Reporter roles at least and you must have at least the Developer role to create a new environment. Both require prior authentication.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • If there are minimum number of members with Reporter/Developer role or above in the list, you are compliant.
+remediation: |
+  Require authentication to access the build environment and disable anonymous access.
+  In GitLab, viewing environments in private projects is limited to Reporter roles at least and you must have at least the Developer role to create a new environment. Both require prior authentication.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • Next to the project member you want to remove, select Remove member
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/environments/#environment-permissions
+cis_controls:
+  - id: 2.5
+    version: 8
+    name: Allowlist Authorized Software
+    description: >-
+      Use technical controls, such as application allowlisting, to ensure that only 
+      authorized software can execute or be accessed. Reassess bi-annually, or more 
+      frequently.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.7
+    version: 7
+    name: Utilize Application Whitelisting
+    description: >-
+      Utilize application whitelisting technology on all assets to ensure that only 
+      authorized software executes and all unauthorized software is blocked from 
+      executing on assets.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_environment_2_1/build_automation.yml

@@ -0,0 +1,54 @@
+---
+id: 2.1.4
+name: build_automation
+title: Ensure the creation of the build environment is automated
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Automate the creation of the build environment.
+rationale: >-
+  Automating the deployment of the build environment reduces the risk for human 
+  mistakes — such as a wrong configuration or exposure of sensitive data — because it 
+  requires less human interaction and intervention. It also eases re-deployment of the 
+  environment. It is best to automate with Infrastructure as Code because it offers more 
+  control over changes made to the environment creation configuration and stores to a 
+  version control platform.
+impact: >-
+audit: |
+  Verify that the deployment of the build environment is automated and can be easily redeployed.
+  In GitLab, build environments are automatically created for each CI/CD pipeline. To verify that a build environment has been automatically created, do the following:
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Operate > Environments.
+    • Review the environments.
+remediation: >-
+  Automate the deployment of the build environment. 
+  In GitLab, build environments are automatically created for each CI/CD pipeline. 
+  To automate a deployment of the build environment, you need to create a CI/CD pipeline using the gitlab-ci.yml file.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/environments/
+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/build_pipelines_2/build_environment_2_1/build_env_admins.yml

@@ -0,0 +1,55 @@
+---
+id: 2.1.11
+name: build_env_admins
+title: Ensure minimum number of administrators are set for the build environment
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Ensure the build environment has a minimum number of administrators.
+rationale: >-
+  Build environment administrators have the highest level of permissions, including the 
+  ability to add/remove users, create or delete pipelines, control build workers, change 
+  build trigger permissions and more. Due to the permissive access granted to a build 
+  environment administrator, it is highly recommended to keep the number of 
+  administrator accounts as minimal as possible.
+impact: >-
+audit: |
+  Verify that the build environment has only the minimum number of administrators.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • If there are minimum number of members with Owner/Maintainer role in the list, you are compliant.
+remediation: |
+  Set the minimum number of administrators in the build environment.
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • Next to the project member you want to remove, select Remove member.
+default_value:
+references:
+cis_controls:
+  - id: 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/build_pipelines_2/build_environment_2_1/build_logging.yml

@@ -0,0 +1,49 @@
+---
+id: 2.1.3
+name: build_logging
+title: Ensure the build environment is logged
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Keep build logs of the build environment detailing configuration and all activity within it.
+  Also, consider to store them in a centralized organizational log store.
+rationale: >-
+  Logging the environment is important for two primary reasons: one, for debugging and 
+  investigating the environment in case of a bug or security incident; and two, for 
+  reproducing the environment easily when needed. Storing these logs in a centralized 
+  organizational log store allows the organization to generate useful insights and identify 
+  anomalies in the build process faster.
+impact: >-
+audit: |
+  Verify that the build environment is logged and stored in a centralized organizational log store.
+  When a build environment is created, all information related to the environment is logged as part of the job logs.
+  Depending on the stage in the build environment lifecycle, the path to retrieve the logs will differ:
+
+    • When a job is running: #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
+    • After a job is finished: #{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
+    • After a log is archived: #{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
+remediation: >-
+  Keep logs of the build environment. Also, store the logs in a centralized organizational log store. 
+  This is automatically done by GitLab and can be retrieved in the paths mentioned in the audit section.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/job_logs.html
+cis_controls:
+  - id: 3.14
+    version: 8
+    name: Log Sensitive Data Access
+    description: >-
+      Log sensitive data access, including modification and disposal.
+    implementation_groups:
+      - IG3
+  - id: 14.9
+    version: 7
+    name: Enforce Detail Logging for Access or Changes to Sensitive Data
+    description: >-
+      Enforce detailed audit logging for access to sensitive data or changes to 
+      sensitive data (utilizing tools such as File Integrity Monitoring or Security 
+      Information and Event Monitoring).
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_environment_2_1/disable_build_tools_default_passwords.yml

@@ -0,0 +1,54 @@
+---
+id: 2.1.9
+name: disable_build_tools_default_passwords
+title: Ensure default passwords are not used
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Do not use default passwords of build tools and components.
+rationale: >-
+  Sometimes build 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 especially important to ensure that default passwords are not used in 
+  build 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
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_environment_2_1/immutable_pipeline_infrastructure.yml

@@ -0,0 +1,60 @@
+---
+id: 2.1.2
+name: immutable_pipeline_infrastructure
+title: Ensure all aspects of the pipeline infrastructure and configuration are immutable
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Ensure the pipeline orchestrator and its configuration are immutable.
+rationale: >-
+  An immutable infrastructure is one that cannot be changed during execution of the 
+  pipeline. This can be done, for example, by using Infrastructure as Code for configuring 
+  the pipeline and the pipeline environment. Utilizing such infrastructure creates a more 
+  predictable environment because updates will require re-deployment to prevent any 
+  previous configuration from interfering. Because it is dependent on automation, it is 
+  easier to revert changes. Testing code is also simpler because it is based on 
+  virtualization. Most importantly, an immutable pipeline infrastructure ensures that a 
+  potential attacker seeking to compromise the build environment itself would not be able 
+  to do so if the orchestrator, its configuration, and any other component cannot be 
+  changed. Verifying that all aspects of the pipeline infrastructure and configuration are 
+  immutable therefore keeps them safe from malicious tampering attempts.
+impact: >-
+audit: >-
+  Verify that the pipeline orchestrator, its configuration, and all other aspects of the build 
+  environment are immutable.
+remediation: >-
+  Use an immutable pipeline orchestrator and ensure that its configuration and all other 
+  aspects of the built environment are immutable, as well.
+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: 8
+    name: Establish and Maintain a Penetration Testing Program
+    description: >-
+      Establish and maintain a penetration testing program appropriate to the size, 
+      complexity, and maturity of the enterprise. Penetration testing program 
+      characteristics include scope, such as network, web application, Application 
+      Programming Interface (API), hosted services, and physical premise controls; 
+      frequency; limitations, such as acceptable hours, and excluded attack types; point of 
+      contact information; remediation, such as how findings will be routed internally; and 
+      retrospective requirements.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/build_pipelines_2/build_environment_2_1/limit_build_access.yml

@@ -0,0 +1,64 @@
+---
+id: 2.1.5
+name: limit_build_access
+title: Ensure access to build environments is limited
+profile: 1
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Restrict access to the build environment (orchestrator, pipeline executor, their 
+  environment, etc.) to trusted and qualified users only.
+rationale: >-
+  A build environment contains sensitive data such as environment variables, secrets, 
+  and the source code itself. Any user that has access to this environment can make 
+  changes to the build process, including changes to the code within it. Restricting access 
+  to the build environment to trusted and qualified users only will reduce the risk for 
+  mistakes such as exposure of secrets or misconfiguration. Limiting access also reduces 
+  the number of accounts that are vulnerable to hijacking in order to potentially harm the 
+  build environment.
+impact: >-
+  Reducing the number of users who have access to the build process means those
+  users would lose their ability to make direct changes to that process.
+audit: |
+  Verify each build environment is accessible only to known and authorized users.
+  In GitLab, viewing environments in private projects is limited to Reporter roles at least and you must have at least the Developer role to create a new environment
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • If there are minimum number of members with Reporter/Developer role or above in the list, you are compliant.
+remediation: |
+  Restrict access to the build environment to trusted and qualified users.
+
+  In GitLab, viewing environments in private projects is limited to Reporter roles at least and you must have at least the Developer role to create a new environment
+    • On the left sidebar, select Search or go to and find your project.
+    • Select Manage > Members.
+    • At the top of the member list, from the dropdown list, select Max role the members have in the group and descending order.
+    • Next to the project member you want to remove, select Remove member
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/environments/#environment-permissions
+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/build_pipelines_2/build_environment_2_1/limit_build_secrets_scope.yml

@@ -0,0 +1,56 @@
+---
+id: 2.1.7
+name: limit_build_secrets_scope
+title: Ensure build secrets are limited to the minimal necessary scope
+profile: 2
+category: build_pipelines
+sub_category: build_environment
+description: >-
+  Build tools providers offer a secure way to store secrets that should be used during the 
+  build process. These secrets will often be credentials used to access other tools, for 
+  example for pulling code or for uploading artifacts. Access to these secrets can be 
+  defined on various scopes. To protect these critical assets it is important to choose the 
+  most restrictive scope necessary.
+rationale: >-
+  Allowing over permissive access to these secrets may affect on their exposure. For 
+  example if a secret is defined in an organization level, and users can create new 
+  repositories, there is a scenario where a user can create a new repo and run a 
+  controlled build just to exfiltrate these secrets.
+impact: >-
+  Increased risk of exposure of build related secrets.
+audit: |
+  In the gitlab-ci.yml file, review the secrets permission scope defined in either a file or in 
+  an external secrets manager.
+remediation: >-
+  In the gitlab-ci.yml file, review the secrets defined in either a file or in an external secrets 
+  manager and change over permissive scopes to more restrictive ones based on the 
+  required access.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/ci/yaml/index.html#secrets
+  - https://docs.gitlab.com/ee/ci/secrets/index.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/build_pipelines_2/build_environment_2_1/readme.md

@@ -0,0 +1,19 @@
+# 2.1 Build Environment
+
+This section consists of security recommendations for the build pipelines environment.
+
+Build environment is everything related to the infrastructure of the organization's artifacts build - the orchestrator, the pipeline executer, where the build workers are running, while pipeline is a set of commands that runs in the build environment. Most of the build environment recommendations are relevant for self-hosted build platforms only. For example, instance of CircleCi that is self-hosted.
+
+## Recommendations
+
+* [2.1.1 - single_responsibility_pipeline.yml](./single_responsibility_pipeline.yml)
+* [2.1.2 - immutable_pipeline_infrastructure.yml](./immutable_pipeline_infrastructure.yml)
+* [2.1.3 - build_logging.yml](./build_logging.yml)
+* [2.1.4 - build_automation.yml](./build_automation.yml)
+* [2.1.5 - limit_build_access.yml](./limit_build_access.yml)
+* [2.1.6 - authenticate_build_access.yml](./authenticate_build_access.yml)
+* [2.1.7 - limit_build_secrets_scope.yml](./limit_build_secrets_scope.yml)
+* [2.1.8 - vuln_scanning.yml](./vuln_scanning.yml)
+* [2.1.9 - disable_build_tools_default_passwords.yml](./disable_build_tools_default_passwords.yml)
+* [2.1.10 - secure_build_env_webhooks.yml](./secure_build_env_webhooks.yml)
+* [2.1.11 - build_env_admins.yml](./build_env_admins.yml)