How should security teams harden CI/CD build pipelines against untrusted pull requests and workflow abuse?

Security teams should treat build pipelines as privileged infrastructure, not just automation. Start by restricting workflow permissions to the minimum required, preferring read-only defaults, avoiding risky triggers where possible, and requiring approval for forks and outside contributors. Separate sensitive secrets, use ephemeral credentials with OIDC, and scan workflow files for injection points and vulnerable actions before attackers can exploit them.

Why CI/CD pipelines become high-value targets when pull requests are untrusted

Untrusted pull requests are dangerous because the pipeline often runs with more privilege than the contributor who submitted the change. That creates a trust mismatch: code from an external source can influence build steps, environment variables, tokens, artifact outputs, and even deployment paths if the workflow is not tightly constrained. The core problem is not just malicious code in the repository, but abuse of the automation layer itself.

For security teams, the practical concern is that CI/CD systems frequently combine source code, secrets, signing material, package publishing rights, and cloud access in one execution path. A weak workflow permission model can let a low-trust contribution reach high-trust infrastructure. The OWASP Non-Human Identity Top 10 is useful here because build runners, service accounts, tokens, and ephemeral identities all need explicit governance rather than inherited trust. In practice, many teams discover pipeline abuse only after a workflow has already exposed a secret, altered an artifact, or executed an unexpected command path.

How to harden workflow execution without breaking contributor velocity

Hardening starts with separating what an untrusted pull request may influence from what it may directly control. A secure pipeline should make the default path low-privilege, then selectively reintroduce trust only where the review process and the source of the code justify it. That usually means read-only permissions by default, limited job scopes, and a strong distinction between build validation and release operations.

One reliable pattern is to prevent forked or outside-contributor code from reaching privileged jobs until it has passed a controlled review step. For example, a pipeline can run initial checks in a sandboxed context, then require human approval before any step that can access signing keys, deployment credentials, package publishing tokens, or protected environments. If the workflow needs cloud access, short-lived identity should be preferred over long-lived secrets because it reduces the blast radius of leakage and makes credential reuse harder.

Constrain workflow permissions at the repository and job level, not just at the platform default.
Keep secrets out of untrusted execution paths unless the job genuinely requires them and the trust boundary is explicit.
Review third-party actions and pinned dependencies as supply-chain inputs, not as harmless convenience tooling.
Log workflow changes, approval events, and token issuance so abuse can be reconstructed after the fact.

Where teams get into trouble is assuming that “build only” means “safe.” Build jobs often have enough reach to mutate release outputs, poison caches, or trigger downstream automation, so the controls must be designed around privilege, not just code provenance. This guidance breaks down when a pipeline must support fully automated release from external contributions without any human gate, because then the organisation is accepting a materially higher trust burden.

Where pipeline abuse tends to hide, and which edge cases change the control design

Tighter workflow controls often increase friction for maintainers and contributors, so organisations need to balance trust reduction against developer throughput and operational simplicity. The tradeoff is most visible in projects that rely on forks, reusable workflows, or shared runners, because each of those patterns widens the boundary where untrusted input can affect privileged execution.

There is no single consensus pattern for every repository. Some teams can safely require manual approval before privileged jobs, while others need a more segmented model because open-source contribution volume or release cadence makes that approach too slow. The important distinction is whether the workflow can be separated into a low-trust validation stage and a high-trust promotion stage. If it cannot, the pipeline should be treated as a release system with explicit trust gates rather than as generic automation.

Edge cases also matter. Reusable workflows can import risk from another repository, cached build artifacts can carry unintended state across jobs, and condition-based execution can be abused when the trigger logic assumes trusted branch context. In short, the strongest control is not “more workflow logic,” but a clearer trust boundary around what may run, what may read secrets, and what may influence downstream deployment. Teams that ignore those edges usually end up discovering the abuse path through an incident rather than through design review.

Risk and Threat Considerations

CI/CD abuse creates a material exposure because untrusted code can be executed inside a privileged automation context. The main risk classes are secret disclosure, unauthorized artifact manipulation, poisoned release outputs, and compromise of downstream systems that trust the pipeline.

Failure mechanism: An attacker or malicious contributor exploits workflow triggers, inherited permissions, unsafe action usage, or secret exposure in pull-request execution to gain access that the repository author did not intend to grant. Once that trust boundary is crossed, the pipeline can be used to read credentials, modify outputs, or pivot into deployment and cloud environments.

Impact: The result can be compromised software releases, leaked credentials, tampered packages, fraudulent automation activity, or broader environment exposure through the identities and tokens the pipeline is allowed to use.

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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	CI/CD pipelines rely on machine credentials and ephemeral tokens.
	NHI-03 — Privilege and Access Scope	Workflow abuse often succeeds through overbroad runner and token permissions.
	NHI-05 — Lifecycle and Ownership	Pipeline identities and workflow assets need clear control and review.
Recommendation — Replace long-lived pipeline secrets with short-lived, scoped credentials. Restrict workflow and runner privileges to the minimum required. Assign ownership and periodic review to every privileged pipeline identity.
CIS Controls v8	6 — Access Control Management	Pipeline hardening depends on limiting access paths and approval scope.
	8 — Audit Log Management	Workflow abuse requires logs for approvals, token use, and job changes.
Recommendation — Enforce least privilege and remove unnecessary access paths from CI/CD jobs. Record workflow approvals, permission changes, and credential issuance for review.
MITRE ATT&CK	T1195 — Supply Chain Compromise	Untrusted PRs and workflow abuse target the software delivery chain.
Recommendation — Hunt for workflow tampering and malicious changes in the delivery pipeline.
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations	CI/CD pipelines need constrained permissions for untrusted contributors.
	DE.CM-8 — Vulnerability Scans on Software and Systems	Workflow files and actions should be scanned for abuse-prone changes.
	RS.MI-1 — Mitigation of Incidents	Pipeline abuse needs containment once malicious workflow activity is detected.
Recommendation — Apply least-privilege permissions to repository, runner, and deployment access. Scan workflow definitions and actions for injection points before release. Contain suspicious workflow activity quickly and revoke exposed credentials.

Practitioner Guidance

What to prioritise: Treat the highest-risk jobs as the ones that can reach secrets, signing, publishing, or deployment. Those steps deserve the strictest approval path and the narrowest identity scope, even if the rest of the pipeline stays fully automated.

What to verify: Confirm that untrusted pull requests cannot inherit privileged runtime context through reusable workflows, cached state, or hidden environment variables. The most common failure is not obvious code injection, but an approval or trigger path that quietly grants more access than the author intended.

Decision rule: If a job can change what leaves the build system, or can authenticate to another system, treat it as privileged and separate it from ordinary test execution. If it cannot be separated, accept that the repository is operating with a higher trust profile and review whether that is still justified.

Practitioner takeaway: Pipeline hardening succeeds when teams design for trust boundaries first and automation convenience second; once an untrusted contribution can influence a privileged job, the control problem has already shifted from code review to identity and execution governance.