What are the signs that a CI workflow is misusing untrusted artifacts?

Warning signs include artifacts downloaded from prior workflows without a clear trust boundary, files unpacked into the repository root, later steps that run package installs or scripts, and workflows triggered from pull requests or forked branches. If the pipeline trusts artifact contents as though they were generated only by maintainers, the workflow is vulnerable to overwrite and code execution.

How to recognise untrusted-artifact misuse in CI workflows

The clearest sign is a trust boundary mismatch: a workflow consumes an artifact as if it were produced by the current trusted build, when it actually came from a prior run, a different branch, or an outside contributor. That matters because artifacts are not just files, they can be an attack payload if downstream steps unpack, interpret, or execute them without verification.

Look for pipelines that treat artifact contents as authoritative input. A healthy workflow keeps generated output, build inputs, and untrusted contribution paths separate; a risky one blurs those lines and lets later steps act on files that may have been influenced by a pull request, fork, or earlier compromised job.

Several patterns usually appear together: artifacts are downloaded and extracted into the repository root, later steps run package installs or build scripts from that extracted content, and the job has write access to the workspace or shared paths. When those pieces line up, the artifact is no longer passive data, it becomes a mechanism for overwrite or code execution.

Where the trust boundary breaks

The practical question is not whether a workflow uses artifacts, but whether it can prove the artifact is safe for the next step. Untrusted-artifact misuse often starts when a build or test job accepts an artifact from a run it did not fully control, then reuses that content in a privileged context. For supply-chain provenance and integrity expectations around build outputs, SLSA is the clearest external reference point.

Misuse also shows up when the workflow assumes that a file named like a package, archive, or report is harmless because it came from CI. The danger is contextual: a benign artifact can be made dangerous if a later step expands it, sources it, or passes it into a shell command without sanitisation or path controls.

Another warning sign is artifact reuse across branches or workflow phases without a documented trust model. If a pull-request job can influence the artifact that a later main-branch or release job consumes, the pipeline has effectively created a path from low-trust input to high-trust execution.

Why the compromise becomes execution

Once the workflow unpacks untrusted content into a writable directory, the next step may overwrite files, change scripts, or place executables where the job will later find them. That is especially dangerous when the workflow runs installs, test hooks, or helper scripts after extraction, because those steps often execute code implicitly rather than visibly.

Files extracted into the repository root are a classic red flag because they can shadow expected paths, alter configuration, or replace build helpers. In the same way, a workflow that reads artifact contents into environment variables, shell commands, or package managers is converting data into instructions.

If the pipeline is triggered by forks or pull requests, the risk is sharper because the attacker controls the initial input channel. The artifact may pass through one job, then be trusted in another job that has broader permissions, secrets, or deployment reach.

Risk and Threat Considerations

Untrusted-artifact misuse creates a direct route from untrusted input to code execution, overwrite, or supply-chain compromise. The most dangerous cases are not the obvious malware drops, but workflows that quietly treat generated files as trusted build material and then execute them in a more privileged stage.

Failure mechanism: A low-trust job produces or influences an artifact, then a later job downloads, unpacks, or executes that artifact inside a workspace or context that assumes only trusted maintainer output is present.

Impact: Attackers can overwrite build inputs, inject commands, exfiltrate secrets, tamper with release artifacts, or pivot from a forked or review-stage workflow into broader CI/CD compromise.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	Artifact trust and provenance are central to the misuse pattern described.
Recommendation — Adopt SLSA-aligned provenance checks before consuming build artifacts in later workflow stages.
CIS Controls v8	CIS-16 — Application Software Security	CI workflow artifact handling is a software integrity and release-path control problem.
Recommendation — Harden CI pipeline steps so untrusted artifacts cannot execute or alter build logic.
NIST CSF 2.0	PR.DS-08 — Integrity of data is protected through data life cycle	The issue is trust in artifact integrity across the CI data lifecycle.
Recommendation — Protect artifact integrity across creation, storage, transfer, and consumption stages.
MITRE ATT&CK	T1608 — Stage Capabilities	The workflow can stage malicious content through artifacts before later execution.
Recommendation — Detect staged content that later becomes executable in privileged CI steps.

Practitioner Guidance

What to verify: Confirm the artifact’s producer, trust boundary, and intended consumer before allowing it into any step that can execute code or modify the workspace. If the workflow cannot prove that the artifact came from the same trusted control plane and branch state, treat it as untrusted input, not build truth.

Common mistake: Teams often assume that “artifact” means “safe output.” In CI, the safer rule is the opposite, artifact contents are only trusted when the workflow explicitly constrains who can create them, where they can be consumed, and what paths they can affect.

Practitioner takeaway: The decisive control is not artifact storage, it is preventing untrusted content from crossing into a step that can execute, overwrite, or inherit privileged context.