Direct Poisoned Pipeline Execution

Rule Details

Cortex AppSec Rule ID	APPSEC_CICD_40
Category	PPE
Severity	HIGH

Impact

Poisoned Pipeline Execution (PPE) risks refer to the ability of an attacker with access to source control systems - and without access to the build environment, to manipulate the build process by injecting malicious code/commands into the build pipeline configuration, essentially 'poisoning' the pipeline and running malicious code as part of the build process. The PPE vector abuses permissions against an SCM repository, in a way that causes a CI pipeline to execute malicious commands. Users that have permissions to manipulate the CI configuration files, or other files which the CI pipeline job relies on, can modify them to contain malicious commands, ultimately "poisoning" the CI pipeline executing these commands. Pipelines executing unreviewed code, for example those which are triggered directly off of pull requests or commits to arbitrary repository branches, are more susceptible to PPE. The reason is that these scenarios, by design, contain code which has not undergone any reviews or approvals. Once able to execute malicious code within the CI pipeline, the attacker can conduct a wide array of malicious operations, all within the context of the pipeline's identity. In a D-PPE scenario, the attacker modifies the CI config file in a repository they have access to, either by pushing the change directly to an unprotected remote branch on the repo, or by submitting a PR with the change from a branch or a fork. Since the CI pipeline execution is triggered off of the "push" or "PR" events, and the pipeline execution is defined by the commands in the modified CI configuration file, the attacker's malicious commands ultimately run in the build node once the build pipeline is triggered.

Recommended Solution - Buildtime

• To prevent the manipulating of the CI configuration file to run malicious code in the pipeline, ensure that each CI configuration file that runs a pipeline is reviewed before the pipeline runs
• Whenever the preference is for developers to manage the CI configuration file inside the same branch as the code being built in the pipeline, ensure that each branch that is configured to trigger a pipeline in the CI system has a correlating branch protection rule in the VCS.
• An equally secure alternative solution is to manage the CI configuration file in a remote branch, separate from the branch containing the code being built in the pipeline. The remote branch should be configured as protected.
• Wherever possible, avoid triggering builds directly off pull requests. Wherever triggering builds off pull requests is compulsory, limit the damage that can be caused by a malicious configuration file:

  • If possible, store the CI configuration file in a remote protected branch, as described above
  • Avoid storing credentials in the CI system which are globally accessible
  • Restrict the CI pipeline to run on specific nodes only, which have no permissions to sensitive systems and environments
  • Remove permissions granted on the repository from users that do not need them