Protecting Against Poisoned Pipeline Execution

Authors:

Table of Contents

The PPE vector exploits permissions within a source code repository to trigger the execution of malicious commands in a build and test pipeline. Harness CI offers multiple features to help secure your build and test pipelines against PPE attacks.

Poisoned Pipeline Execution (PPE) is one of the exploits outlined in the Top 10 CI/CD Security Risks from the Open Worldwide Application Security Project (OWASP). The PPE vector exploits permissions within a source code repository to trigger the execution of malicious commands in a build and test pipeline.

In this blog post, you will learn the different types of PPE attacks, and how to minimize or eliminate the threat to your automation pipelines.

What is Poisoned Pipeline Execution?

Users who can alter configuration files or other files that the pipeline relies on can inject malicious commands into these files, thereby "poisoning" the pipeline and causing it to execute the harmful instructions. Pipelines that execute unreviewed code, such as those triggered directly by pull requests or commits to arbitrary repository branches, are more vulnerable to PPE.

Once an attacker can execute malicious code in your pipeline, any sensitive data or endpoints accessible to the pipeline could be at risk:

Secrets (passwords, access tokens)
Assets (files, databases, cloud storage)
Artifacts (docker images, software packages)
Network access (servers, restricted endpoints)

The three types of PPE attacks are Direct, Indirect, and Public.

What is Direct Poisoned Pipeline Execution?

In a Direct PPE scenario, an attacker modifies the pipeline configuration file in a repository they have access to by either pushing changes to an unprotected branch or submitting a pull request from a branch or fork. These events trigger the pipeline, causing the malicious commands defined in the modified configuration file to execute in the build environment.

Example GitHub Actions Direct PPE attack to obtain AWS credentials

What is Indirect Poisoned Pipeline Execution?

Indirect PPE happens when the attacker cannot modify the pipeline configuration file as with Direct PPE.

In these cases, the attacker can still compromise the pipeline by inserting malicious code into files referenced by the pipeline configuration file. This includes scripts called within the configuration file, code tests, or automated tools like linters and security scanners used in the pipeline.

An Indirect PPE vulnerability was exposed in the CodeBuild pipeline of a website belonging to AWS. Anonymous attackers were able to modify a script executed by the build configuration file with the creation of a pull request, resulting in the compromise of deployment credentials.

Example Jenkins Indirect PPE attack to obtain AWS credentials

What is Public Poisoned Pipeline Execution?

Public PPE is an attack in which anonymous internet users exploit public repositories by submitting pull requests. If the CI pipeline runs this unreviewed code, it becomes vulnerable. If the same CI instance is used for public and private repositories, this can also expose internal assets, like secrets from private projects.

Recommended Actions

Take these steps to protect against PPE attacks:

Create a separate pipeline for pull requests, which does not reference secrets and other sensitive data.
Require pull request changes to be reviewed before a pipeline can execute.
When configuring webhook triggers, ensure that only required events are selected. If supported, configure a secret to authenticate the webhook call.
Store the pipeline configuration file in a separate repository that only trusted users can modify.
Reduce or eliminate commands indirectly run by scripts, tests, or linters. Instead, define the commands directly in the pipeline configuration.
Add branch protection rules to your repository to prevent unreviewed changes from being pushed directly to important branches.

How Harness CI Can Help

Harness CI offers multiple features to help secure your build and test pipelines against PPE attacks.

Harness triggers are managed independently from pipeline configuration. Role-based access controls (RBAC) can ensure that only trusted users can add or modify pipeline triggers.
Pipeline configuration can be managed in a different Git repository, or directly within Harness. This means pipeline configurations can be managed separately from application code.
Adding a manual approval stage at the start of your pipeline ensures that your team always has the opportunity to review code and configuration changes before the pipeline executes.

‍