What breaks when CI/CD pipelines can be modified by untrusted repository input?

When untrusted repository input can change pipeline logic, attackers can turn build automation into code execution. The pipeline may run malicious commands, expose secrets, and let an attacker alter build outputs or release artifacts. In practice, that can expand a single repository compromise into wider environment access, especially when workflows have write permissions or shared credentials.

How pipeline trust breaks when repository input can rewrite execution

The core failure is trust boundary collapse. A CI/CD pipeline should treat repository content as data, not as a source of instructions with the same privilege as the pipeline itself. Once untrusted input can influence workflow logic, checkout behavior, scripts, or action references, the repository becomes an execution substrate rather than a build input.

That matters because pipeline code usually runs with broader authority than the contributor who supplied the change. If the workflow can be edited or indirectly steered by untrusted content, the build system may execute attacker-chosen commands, import hostile dependencies, or pivot into connected services that were never meant to be reachable from repository code.

In practice, this is why “safe by default” pipeline design separates immutable workflow definition from mutable repository payloads. The most robust patterns are pre-approved workflow files, pinned references, restricted runners, and explicit trust decisions for any step that reads from pull request content, generated files, or third-party actions.

What attackers gain once pipeline logic becomes attacker-controlled

The first payoff is command execution in a trusted environment. From there, attackers often look for secrets, publishing credentials, signing material, or cached cloud tokens that the runner can access during the job. If those secrets are available, the compromise can extend beyond the build itself into artifact tampering, package poisoning, or unauthorized access to downstream systems.

This is the same abuse path described in CI/CD pipeline exploitation case study, where pipeline weakness and secret exposure combine into broader environment access. The related CI/CD Pipeline Identity Security Guide is useful because the real problem is not just code execution, it is which identities, tokens, and trust policies the pipeline is allowed to use once execution is gained.

Artifact integrity is another common break point. If the pipeline can be steered, an attacker may be able to change what gets built, signed, or released while leaving the version history looking ordinary. That is why build provenance, tamper-evident signing, and controlled publishing are not optional extras when workflows handle release assets.

Where the blast radius expands from a single repository to the wider environment

Repository-level compromise becomes materially worse when pipelines reuse shared credentials, write back to source control, or run with broad cloud permissions. In those cases, the pipeline is not just building software, it is a bridge into package registries, deployment targets, and internal services. One compromised workflow can therefore alter artifacts, push malicious commits, or expose materials that were assumed to be isolated.

The supply-chain angle is well illustrated by Reviewdog GitHub Action supply chain attack and GitHub Action tj-actions Supply Chain Attack, both of which show how compromised actions can leak CI/CD secrets at scale. SLSA is the relevant external reference when the question is build integrity, because provenance and verified source-to-artifact traceability are what stop a pipeline from silently turning into a release forgery mechanism.

When repository input can modify execution, the practical question becomes whether a workflow is allowed to cross trust zones. If the answer is yes, then the build system needs compensating controls that limit secret exposure, isolate untrusted jobs, and make any privilege escalation visible in logs and reviewable in approvals.

Risk and Threat Considerations

Once untrusted repository content can influence pipeline execution, the main risks are secret theft, unauthorized code execution, artifact tampering, and lateral movement through shared build credentials. The threat is especially severe when workflows run on self-hosted runners or reuse long-lived tokens, because a single malicious change can persist long enough to exfiltrate credentials or modify release outputs.

Failure mechanism: The attacker injects or redirects pipeline logic through a repository-controlled path, then uses the trusted runner context to read secrets, invoke commands, or replace build and release artifacts.

Impact: A compromise that began as a repository change can expand into package compromise, credential exposure, unauthorized deployment, or broader environment access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Pipeline compromise often exposes CI/CD secrets and tokens.
	NHI-05 — Overprivileged NHI	Workflows with broad tokens or runner access widen blast radius.
	NHI-07 — Long-Lived Secrets	Long-lived CI/CD credentials make pipeline compromise persist.
Recommendation — Rotate exposed secrets and remove them from build-time scope. Reduce workflow permissions to the minimum needed for each job. Replace static pipeline secrets with short-lived, scoped credentials.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Attacker-controlled workflow steps can trigger actions beyond intended privilege.
	API8 — Security Misconfiguration	Misconfigured runners, permissions and triggers create exploit paths.
Recommendation — Enforce function-level authorization on workflow-triggered operations. Harden pipeline configuration and remove unnecessary execution privileges.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Pipeline jobs should not inherit broader access than the task requires.
	IA-5 — Authenticator Management	CI/CD tokens, keys and secrets must be protected and rotated.
Recommendation — Assign the minimum permissions needed to each CI/CD job. Manage pipeline credentials with rotation, storage and revocation controls.
SLSA	Supply-chain Levels for Software Artifacts	The question centers on build integrity and trusted artifact production.
Recommendation — Adopt provenance and signing controls to verify build outputs.
MITRE ATT&CK	T1552 — Unsecured Credentials	Attackers exploit pipeline-accessible secrets to expand compromise.
	T1195 — Supply Chain Compromise	Repository-controlled pipeline changes are a supply-chain abuse path.
Recommendation — Hunt for credential exposure in build logs, runners and artifacts. Model repository-to-build trust paths as supply-chain attack surfaces.

Practitioner Guidance

What to verify: Confirm that repository-sourced content cannot alter privileged workflow steps, action versions, or release logic without review. If a pipeline must process untrusted input, separate that job from any step that can read secrets or publish artifacts.

Decision rule: If a workflow can reach signing keys, publishing tokens, or cloud credentials, treat it as a high-value control boundary and require pinned dependencies, least-privilege permissions, and a clear approval path for any change to execution logic.

Common mistake: Teams often harden the repository while leaving the workflow runtime broad and trusted. The better test is whether an attacker who controls pull-request content can influence execution beyond the intended build scope.

Practitioner takeaway: The critical control is not just repository review, it is preventing untrusted input from inheriting the pipeline’s authority. If the workflow can execute on behalf of more privilege than the contributor, assume the repository can become a delivery path for code execution and secret exposure.