Branches configured to trigger a pipeline exposed to secrets has a correlating branch protection rule in the SCM

Certain pipelines may be triggered by a push of commits to a branch. If the branch is not protected, commits may contain unexpected code (for example, changes in commands in the triggered pipeline itself, or in scripts invoked by the pipeline).

For sensitive pipelines such as those that are exposed to secrets, deployment to registries or provisioning into cloud, ensure that each branch that is configured to trigger a pipeline in the CI system has a correlating branch protection rule in the SCM imposing checks like a code review; this way, the actors capable to modify the target branch will be limited.

Triggering a pipeline with a tailored commit pushed to an unprotected branch that gives access to sensitive information or actions without specific security checks is an insufficient flow control issue, and can lead to poisoned pipeline execution.

Poisoned Pipeline Execution (PPE) 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.

In a successful PPE attack, attackers execute malicious unreviewed code in the CI. This provides the attacker with the same abilities and level of access as the build job, including:

Sensitive pipelines triggered by push events to an unprotected branch are dangerous and will be reported by this detector. Unauthorized access to secrets (SCM and API tokens, cloud credentials or database passwords) can lead to unauthorized access, data breaches or supply chain attacks, and lack of control regarding who has access to such secrets.

Ensure branches configured to trigger a pipeline exposed to secrets has a correlating branch protection rule in the SCM.

If the pipeline really needs access to sensitive resources and actions (like accessing secrets or publishing artifacts into registries) it is recommended to protect the triggering branch (think on a release branch), possibly limiting who can push to the branch or enforcing checks like code reviews (e.g. on pull requests from a branch containing the changes that would be reviewed before merge into the base protected branch).

As an alternative, try to split the pipeline into two. The first pipeline, triggered by commits push to the unprotected branch, will launch automated checks that verify the changes, including manual or automatic approvals that launch the second pipeline. Move the sensitive actions to a second pipeline, that depend on the first pipeline having all the checks passed.