What are the signs that a CI/CD pipeline is vulnerable to artifact poisoning or command injection?

Where Artifact Poisoning Begins in CI/CD

Artifact poisoning usually starts when the pipeline treats build outputs as if they were already trustworthy. That trust can be broken when a job writes to a shared workspace, consumes artifacts from an earlier stage without verifying origin, or allows archive contents to influence later execution paths. Once a build artifact can shape what gets executed, the pipeline has lost a key boundary.

The most visible warning sign is path ambiguity. If a pipeline extracts archives into locations that later steps also read from, a malicious file can shadow a legitimate one or alter what a script loads. The risk is higher when build outputs and source checkout share directories, when cleanup is inconsistent, or when the pipeline accepts artifacts without provenance checks such as SLSA style integrity controls.

Shared trust also shows up in the way teams handle secrets and tokens. If later stages can read the same files, environment variables, or cached credentials used by earlier stages, a poisoned artifact can become a pathway to broader compromise rather than a single bad build. NHIMG’s Ultimate Guide to Non-Human Identities is a useful reference for the broader risk of overprivileged machine credentials in delivery systems, and the same pattern applies when CI/CD jobs are allowed to reuse authority without tight scoping.

Command Injection Warning Signs in Pipeline Jobs

command injection becomes plausible when pipeline steps interpolate untrusted data into shell commands, template strings, or interpreted scripts without strict validation. Common red flags include branch names, commit messages, file names, issue fields, or build parameters being inserted directly into a shell, especially when the command is executed with elevated privileges or reused across multiple stages.

Another strong signal is “convenience scripting” that assumes inputs are already safe. A job that builds command lines through string concatenation, expands wildcards, or shells out to helper scripts without quoting and argument separation can turn ordinary metadata into executable control. The same concern applies when build systems accept values from pull requests, external webhook payloads, or third-party automation and then pass them on unchanged.

When command injection is present, the failure is often not a single unsafe line but a pattern of weak assumptions: no input normalisation, no allowlist for expected values, and no clear boundary between data and instructions. In mature pipelines, execution steps are intentionally boring, because anything that can alter the command interpreter should be treated as hostile until proven otherwise.

Risk and Threat Considerations

Artifact poisoning and command injection matter because they turn the pipeline itself into an execution surface. Once an attacker can influence a build artifact or a shell command, they may be able to change the build output, steal credentials, tamper with release assets, or pivot into downstream environments that trust the pipeline.

Failure mechanism: The pipeline consumes untrusted inputs as if they were trusted code, file content, or command arguments, then executes them in a stage that has access to build secrets, deployment tokens, or signing material.

Impact: The result can include source tampering, malicious release artifacts, credential exposure, unauthorized deployment, or persistence inside the delivery chain. References such as the Reviewdog GitHub Action supply chain attack and the CI/CD pipeline exploitation case study show how quickly weak trust boundaries can convert into material compromise.

Practitioner Guidance

What to verify: Check whether each stage has a single, explicit trust boundary. If a job both handles untrusted input and can reach signing keys, deployment credentials, or production registries, treat that as a design flaw rather than an implementation detail.

What to prioritise: Separate data handling from execution. Use distinct workspaces, strict artifact provenance checks, and argument-safe invocation patterns before you spend time hardening secondary controls. The goal is to make it difficult for an attacker to influence what runs, not merely to detect it after the fact.

Common mistake: Teams often secure the repository and forget the pipeline. That leaves build metadata, archives, helper scripts, and automation tokens as the easier route into the delivery chain.

Practitioner takeaway: If an untrusted input can change what the pipeline executes, or if a later stage inherits more privilege than it needs, the pipeline should be treated as vulnerable until those paths are explicitly broken.

Related resources from NHI Mgmt Group

• What are the signs that a CI/CD pipeline may be vulnerable to logging command abuse?
• What are the signs that artifact protection is failing in a CI/CD pipeline?
• How should security teams prevent command injection in CI/CD pipelines that execute debugging commands with untrusted input?
• How do security teams know whether CI/CD guardrails are actually preventing command injection?