Teams should treat artifacts as untrusted input and tightly control where they are downloaded, unpacked, and reused. The key safeguards are isolating build and consume steps, setting explicit artifact paths, restricting workflow permissions, and preventing user-controlled files from overwriting repository content. If a later step can execute scripts from overwritten files, artifact poisoning can become full pipeline compromise.
Why artifact poisoning becomes code execution
Artifact poisoning is dangerous because the artifact is not just data, it is something the pipeline may later trust, unpack, or execute. If a poisoned artifact can overwrite repository files, scripts, or build outputs, a later step may run attacker-controlled code with the workflow's privileges. That turns a supply-chain integrity issue into direct pipeline compromise.
The practical failure is usually a trust boundary mistake. A workflow produces an artifact in one step, then a later job downloads it into a path that overlaps source, build, or deployment files. If the pipeline does not separate producer and consumer locations, the artifact can alter what the next step executes rather than remain inert output.
This is why build provenance controls matter. A pipeline that verifies what it produced, where it came from, and whether it was modified before reuse is much harder to subvert than one that treats every downloaded archive as safe workspace content. For artifact integrity controls, SLSA is the clearest external reference for build provenance and tamper resistance.
Where teams need to break the attack path
Teams should design the workflow so the artifact cannot influence code paths unless it has passed an explicit trust gate. That means writing outputs to dedicated directories, extracting them in isolated locations, and never allowing a downloaded archive to land inside the repository root or another executable path. The goal is to make artifact consumption one-way: read, verify, then use.
Permissions should also reflect the same boundary. A workflow that can write artifacts, pull them back, and execute code from the same job has too much opportunity for self-poisoning. Restricting token scope, separating jobs, and limiting filesystem access reduces the chance that a poisoned file can replace a script, config, or binary that the next step expects to run.
In practice, this is a repository hygiene problem as much as a CI problem. Build systems should reject unexpected files in the artifact payload, and the consumer step should know exactly which paths are safe to unpack. OWASP Non-Human Identity Top 10 reinforces the adjacent control lesson that long-lived or overprivileged automation material makes poisoning far more damaging once a workflow is abused.
For teams that want a broader execution-risk lens, OWASP Agentic AI Top 10 highlights a similar pattern: once a system can invoke tools or execute generated content, the boundary between input and code must be explicit and enforced.
What safe workflow design looks like in practice
The most reliable pattern is to treat artifacts as untrusted until the consuming step has verified source, path, and contents. Use immutable artifact names, explicit extraction targets, and separate locations for checked-in code, temporary files, and downloaded outputs. If a step needs to read an artifact, it should not be able to write over files that later become executable.
Teams should also watch for file-type confusion and archive traversal issues. A malicious archive can hide a script, symlink, or path-encoded payload that lands outside the intended directory and changes what the pipeline runs next. Restricting allowed file names, normalising extraction paths, and checking for unexpected executable files are practical guardrails that stop the handoff from becoming code execution.
When a workflow must consume externally influenced artifacts, the safer choice is to verify them before use and keep execution steps separate from unpacking steps. That design is less convenient, but it sharply reduces blast radius when a bad artifact or compromised upstream job appears. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it aligns artifact handling with access control, integrity, and configuration management expectations.
Risk and Threat Considerations
Artifact poisoning is especially risky in CI because the attacker only needs one writable path into the artifact flow, then one later step that trusts the result. If the workflow unpacks into the repository or executes generated files without checking provenance, the attacker can pivot from a poisoned artifact to arbitrary code execution.
Failure mechanism: A poisoned archive or output overwrites a script, build file, or dependency path that a later job executes, so the workflow runs attacker-controlled code under legitimate pipeline permissions.
Impact: The compromise can extend beyond a single job to stolen secrets, tampered build outputs, malicious releases, or broader supply-chain compromise if the pipeline signs, publishes, or deploys from the affected workspace.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Artifact poisoning is a build integrity problem that SLSA directly addresses. |
| Recommendation — Adopt provenance and integrity checks before trusting build artifacts. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | The workflow must preserve integrity before unpacking or executing artifacts. |
| AC-6 — Least Privilege | Restricted workflow permissions limit what poisoned artifacts can affect. | |
| CM-5 — Access Restrictions for Change | Preventing artifacts from overwriting repo content is a configuration-control problem. | |
| Recommendation — Validate artifact integrity before any consumer step executes it. Limit pipeline permissions to the minimum needed for each job. Block writes from downloaded artifacts into source-controlled paths. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | CI artifact handling is part of secure software delivery and pipeline hardening. |
| Recommendation — Harden pipeline steps that unpack, verify, and execute build outputs. | ||
Practitioner Guidance
What to verify: Confirm that artifact download paths are outside the repository root, that extraction cannot traverse directories, and that later steps cannot execute from the same location they unpack. If those three conditions are not true, assume the workflow is one poisoned artifact away from code execution.
Common mistake: Teams often harden the artifact producer but leave the consumer step permissive. The dangerous control point is usually the unpack-and-use phase, because that is where a harmless archive becomes executable input.
What good looks like: Separate produce, verify, unpack, and execute into distinct steps with narrow permissions and fixed paths, then fail closed if the artifact contains unexpected files or executable content.
Practitioner takeaway: Preventing artifact poisoning is less about scanning more and more about making it impossible for downloaded content to overwrite or influence code that will later run.
Related resources from NHI Mgmt Group
- How should security teams prevent insecure deserialization from turning into remote code execution in CI/CD pipelines?
- How should security teams prevent malicious MCP servers from turning authentication flows into code execution risks?
- How should security teams prevent artifact poisoning in CI/CD pipelines when signing releases?
- How should security teams use software attestations to prevent artifact poisoning in CI/CD pipelines?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
