Why do workflow_run pipelines create supply chain risk when they process pull request results?

workflow_run creates risk because the follow-on job runs with access to secrets and write tokens even when the earlier workflow was unprivileged. If the privileged job trusts code, artifacts, or outputs from the triggering workflow, an attacker can inject commands, modify artifacts, or reach repository secrets. That combination can escalate a single pull request into broader supply chain compromise.

Why Workflow-Run Pipelines Become a Supply Chain Boundary

workflow_run is risky because it intentionally crosses a trust boundary: one workflow is allowed to produce artefacts or results, and a later workflow consumes them with higher privileges. That handoff is attractive to attackers because pull requests are often the least trusted input path in a repository, while the follow-on job may be the first step that can reach protected secrets, publish artefacts, or mutate repository state.

The core issue is not simply that the trigger exists, but that the privileged stage may assume the earlier stage was benign. Once a pull request can influence code, generated files, metadata, or build outputs, the workflow boundary becomes a supply chain boundary. In practice, teams usually discover this only after they have already wired the privileged job to trust the untrusted output.

How the Compromise Happens in Practice

The dangerous pattern is a two-stage pipeline where the initial pull request workflow runs with limited permissions, but the workflow_run listener runs with broader permissions. If the second stage checks out attacker-controlled content, parses untrusted artefacts, or reuses generated files without strong validation, the attacker can turn the handoff into code execution or data exposure.

Common failure modes include:

Executing scripts or actions referenced by untrusted build output.
Downloading and unpacking artefacts without verifying origin or integrity.
Using pull request data in shell commands, template files, or release steps.
Allowing the privileged workflow to access repository secrets before trust is established.

The security impact is usually broader than a single workflow run. A successful attacker can steal tokens, exfiltrate secrets, tamper with release artefacts, poison build provenance, or persist through altered automation. The practical lesson is that the second workflow must treat everything from the first workflow as hostile unless it has been independently authenticated and integrity-checked.

NIST SSDF (SP 800-218) and SLSA both reinforce the same principle: build and release stages should preserve provenance and separate untrusted input from privileged execution. For a concrete exploitation pattern, see Reviewdog GitHub Action supply chain attack.

These controls break down when the privileged workflow re-checks out attacker-influenced content or trusts artefacts as if they were signed release inputs.

Common Variations and Edge Cases

Tighter pipeline isolation often increases friction, so teams have to balance speed against trust separation. The safest design for one repository is not always the most convenient design for a multi-stage release process.

Some workflows are relatively safe when they only pass metadata such as run IDs or status flags, but the risk rises quickly when the second job uses any content that originated from the pull request itself. A “results-only” handoff is much less dangerous than a handoff that carries generated code, archives, manifests, or environment variables derived from untrusted input.

The edge case that causes the most trouble is the false assumption that a completed first workflow makes the result trustworthy. Completion only means the job finished, not that the artefact is safe for privileged reuse. Teams should treat artefacts, logs, and outputs from pull request paths as untrusted until verified, especially when the next stage can write tags, publish packages, or access deployment secrets. Best practice is evolving, but there is no universal shortcut that makes untrusted PR output safe to consume automatically.

Risk and Threat Considerations

The material risk is privilege escalation across a CI/CD trust boundary. A pull request can remain unprivileged in its own workflow while still influencing a later privileged job that has secrets, write access, or release authority. That makes workflow_run a high-value target for supply chain compromise.

Failure mechanism: An attacker shapes code, artefacts, or metadata in the initial workflow so the follow-on job executes attacker-controlled logic, consumes poisoned outputs, or leaks credentials during privileged steps.

Impact: Repository secrets, signing material, release artefacts, and downstream package or deployment integrity can all be exposed or corrupted, allowing compromise to spread beyond the original pull request.

Standards & Framework Alignment

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

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations	Workflow_run privilege hinges on access boundaries and authorizations.
	PR.DS-6 — Data is Protected	Artefacts and outputs crossing the workflow boundary need integrity protection.
	GV.SC-3 — Cyber Supply Chain Risk Management	This is a software supply chain trust problem across pipeline stages.
Recommendation — Restrict downstream workflow permissions to the minimum needed for release tasks. Protect workflow outputs with integrity checks before downstream reuse. Map workflow_run handoffs into supply chain risk reviews and release gating.
CIS Controls v8	6 — Access Control Management	The issue is excessive access in the privileged pipeline stage.
	16 — Application Software Security	The attack abuses pipeline logic and trusted build inputs.
Recommendation — Separate untrusted PR workflows from privileged release credentials and write access. Validate artefacts and inputs before a privileged workflow consumes them.

Practitioner Guidance

What to prioritise: Treat the workflow boundary as a trust boundary, not a convenience boundary. The first question is whether the privileged job truly needs any artefact, file, or command path that the pull request can influence.

What to verify: Confirm that the follow-on workflow never executes unreviewed content, never inherits secrets before validation, and never assumes build success equals content trustworthiness. If the privileged stage must use outputs, verify integrity and origin explicitly before use.

Decision rule: If the downstream job can publish, deploy, sign, or write back to the repository, require stronger controls than ordinary PR review, because the blast radius is no longer limited to the pull request itself.

Practitioner takeaway: The control objective is not to make workflow_run harmless, it is to ensure that untrusted pull request results cannot cross into a privileged stage without a deliberate trust decision.