> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/appsec-rules/ci-cd-security/ppe/appsec-cicd-40.md).

# 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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/appsec-rules/ci-cd-security/ppe/appsec-cicd-40.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.