What is the difference between direct poisoned pipeline execution and indirect poisoned pipeline execution?

Direct poisoned pipeline execution happens when an attacker changes the pipeline configuration itself, so malicious commands are executed because the workflow definition was altered. Indirect poisoned pipeline execution happens when the pipeline remains intact, but it calls scripts or files that the attacker has modified. Both can lead to unsafe execution, but the second is harder to spot because the compromise sits in referenced code, not the pipeline file.

How the two poisoned pipeline execution paths differ

direct poisoned pipeline execution targets the pipeline definition itself, so the attacker is changing what the pipeline will do when it runs. Indirect poisoned pipeline execution leaves the pipeline intact but corrupts something it depends on, such as a script, build file, or referenced asset. The practical difference is where the malicious logic lives and how far it must travel through the delivery chain to execute.

That distinction matters because the direct path is usually easier to prove from the pipeline config alone, while the indirect path requires checking the full set of referenced inputs and generated artifacts. In both cases, the problem is unsafe execution inside trusted automation, but the compromise surface is different: pipeline control versus pipeline dependency.

Direct poisoning is a workflow-definition problem, often visible in YAML, job steps, or build orchestration logic.
Indirect poisoning is a dependency-integrity problem, where the pipeline faithfully runs tampered content it was told to trust.
Direct attacks usually change intent up front; indirect attacks preserve the pipeline’s apparent intent while altering the executed payload.

For practitioners, that means the review scope is different. A code review of the pipeline file may catch direct poisoning, but it will not catch a malicious helper script pulled from a branch, package, or repository path that the workflow invokes later. The second case is often harder to spot because the dangerous change is separated from the orchestration layer that appears clean.

Why indirect poisoning is often harder to detect

Indirect poisoning blends into ordinary delivery mechanics, which makes it easier to miss during routine inspection. The pipeline may still pass structural validation, still use the expected workflow file, and still appear to be executing normal build steps. The malicious behavior emerges only when a referenced file, script, or dependency is resolved at runtime.

That creates a common blind spot: teams often protect the pipeline configuration more carefully than the code or artifacts the pipeline consumes. If referenced files can be edited without the same controls, an attacker can preserve the workflow’s outward structure while still steering execution. This is why provenance, repository integrity, and change control over build inputs matter as much as the pipeline definition itself.

One useful way to think about the difference is this: direct poisoning compromises the instruction set, while indirect poisoning compromises the inputs to that instruction set. A secure pipeline needs both to be trustworthy, because a clean workflow file does not guarantee clean execution.

Direct poisoning is easier to pinpoint in audits because the malicious change is in the pipeline logic.
Indirect poisoning is often stealthier because the workflow file can remain unchanged while a called component is altered.
Both forms can produce the same end result, unsafe commands running in a trusted automation context.

Risk and Threat Considerations

Both attack paths create integrity risk, but indirect poisoning often broadens the attack surface because it can hide in scripts, templates, and dependencies that are reused across jobs. A compromised pipeline path can lead to secret exposure, malicious builds, or downstream code execution in environments that trust the automation output.

Failure mechanism: direct poisoning changes the workflow definition, while indirect poisoning leaves the workflow intact and corrupts a referenced script, file, or artifact that the pipeline later executes.

Impact: attackers can trigger malicious commands inside trusted delivery systems, which can expose secrets, tamper with builds, and propagate unsafe artifacts downstream.

Standards & Framework Alignment

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

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
MITRE ATT&CK	T1195 — Supply Chain Compromise	Poisoned pipeline execution is a supply-chain compromise of trusted build automation.
Recommendation — Map pipeline trust boundaries and detect tampered build inputs under T1195.
CIS Controls v8	8 — Audit Log Management	Pipeline poisoning demands traceability for workflow and script changes during execution.
	16 — Application Software Security	Securing pipeline code and referenced build assets is part of software delivery hardening.
Recommendation — Log and review pipeline, script, and artifact changes to spot unsafe execution paths. Secure build inputs and delivery automation to prevent malicious code execution.
NIST CSF 2.0	PR.DS — Data Security	Protecting pipeline inputs, scripts, and artifacts preserves integrity across delivery stages.
	PR.IP — Information Protection Processes and Procedures	Workflow review and change control are central to preventing poisoned pipeline paths.
Recommendation — Protect pipeline data and build inputs from tampering across the delivery chain. Enforce change control for workflows, scripts, and referenced build assets.

Practitioner Guidance

What to verify: Treat the pipeline file, the scripts it calls, and the artifacts it consumes as one trust boundary. If a workflow is permitted to run repository content, verify whether branch protections, review rules, and commit provenance apply equally to those referenced paths, not just to the YAML definition.

Common mistake: Teams often harden the visible pipeline while leaving shared scripts, build helpers, or generated files weakly controlled. That creates a false sense of safety, because a clean workflow can still faithfully execute a poisoned dependency.

Practitioner takeaway: The real control objective is end-to-end execution integrity, not just configuration integrity. If the pipeline can be trusted but its inputs cannot, the environment is still vulnerable to poisoned execution.