What are the signs that a CI/CD pipeline is being abused through living-off-the-pipeline techniques?

Warning signs include unexpected plugin execution, tools reading configuration from the wrong location, unexplained dependency changes, unusual shell behaviour from environment variables, and secrets appearing in logs or standard output. Teams should also watch for builds that succeed while silently performing extra actions, because LOTP abuse often hides inside normal pipeline activity rather than crashing jobs outright.

Pipeline abuse signals that matter to defenders

Living-off-the-pipeline techniques matter because they turn trusted build automation into an execution path that looks normal until something downstream breaks. The abuse is not primarily about a failed build, but about an attacker or insider using the pipeline’s own trust, variables, runners, and plugins to run extra actions, stage payloads, or expose secrets without creating an obvious error. For defenders, the question is whether the pipeline is doing only what it was intended to do, and whether its outputs match the expected change set and control flow. For background on how post-compromise activity is organised by adversary behavior, the MITRE ATT&CK Enterprise Matrix is the most relevant external reference. In practice, many security teams discover LOTP abuse only after a routine build has already been used to execute side actions or leak material that the job never needed in the first place.

How living-off-the-pipeline abuse shows up in real builds

LOTP abuse usually blends into ordinary CI/CD activity, so the most useful signs are mismatches between what the pipeline should do and what it actually touched. Unexpected plugin or step execution is one common indicator, especially when the change request did not introduce a new build dependency or job stage. Another is path confusion, where tools resolve configuration, templates, or scripts from an unexpected location because environment variables or working directories were manipulated.

Dependency drift is another practical clue. A build that suddenly pulls different packages, updates lockfiles without a clear reason, or fetches artifacts from unfamiliar locations may be following attacker influence rather than developer intent. Secret exposure is also a strong warning sign, but the key is context: credentials appearing in logs, console output, or artifact contents often indicate the pipeline was coaxed into handling data it should never have surfaced.

Watch for job steps that run outside the documented sequence or invoke tools not used by that repository.
Check for shell or interpreter behaviour that changes when environment variables, wrappers, or injected arguments are present.
Compare the build output with the approved change set, especially when a job succeeds but produces unexpected network, file, or dependency activity.
Review whether the pipeline is reading from the intended config source, not a parent directory, temp path, or attacker-controlled workspace location.

The most important control failure is trust without verification: pipeline automation is often granted broad execution rights even when its inputs are only weakly constrained, which makes abuse easier to hide inside routine success. That guidance breaks down when logging, artifact retention, or runner isolation is too limited to show what the job actually executed.

When a “normal” pipeline is really an unsafe one

Tighter pipeline monitoring often increases noise and operational overhead, so teams have to balance visibility against the risk of drowning in false positives. One genuine edge case is legitimate build tooling that behaves dynamically, such as plugin ecosystems, generated code, or environment-sensitive tests, where unusual actions are not automatically malicious.

Guidance is not fully settled on where to draw the line between acceptable automation flexibility and suspicious runtime mutation, so the practical test is whether the behaviour is both expected and recorded. If the pipeline can modify its own inputs, fetch new execution components, or emit secrets without a change ticket or a reviewed exception, that is an abuse condition even if the final job still passes.

Another common edge case is shared runners and cached workspaces. These environments can make benign behaviour look abnormal, but they also create a larger blast radius if trust boundaries are weak. Teams should treat unexplained success with extra caution when the pipeline has enough privilege to reach source control, package registries, or secret stores.

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 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	LOTP abuse often uses pipeline shells and interpreters to execute hidden actions.
	T1105 — Ingress Tool Transfer	Abused pipelines often fetch extra tools or payloads during a build run.
	T1552 — Unsecured Credentials	Secrets exposed in logs or output are a common consequence of pipeline abuse.
Recommendation — Hunt for unexpected interpreter use and block unapproved script execution in CI/CD jobs. Alert on unexpected tool retrieval and restrict pipeline egress to approved sources. Detect credential exposure in job output and prevent secrets from reaching logs or artifacts.
CIS Controls v8	6 — Access Control Management	CI/CD abuse depends on excessive pipeline and runner permissions.
	8 — Audit Log Management	Detection depends on logs that show unusual execution paths and data access.
Recommendation — Apply least privilege to pipeline identities, runners, and deployment tokens. Centralise build and runner logs so anomalous steps, outputs, and file reads are reviewable.

Practitioner Guidance

What to verify: Confirm that each job is using approved inputs, approved execution paths, and approved secrets exposure rules. The most useful check is not whether the job completed, but whether every unexpected file read, dependency fetch, or shell action can be explained by the committed change and pipeline design.

What to prioritise: Focus first on places where the pipeline can rewrite its own behaviour, especially environment variables, dynamically loaded plugins, shared caches, and runner-local configuration. Those are the points where LOTP abuse most often turns routine automation into covert execution.

Common mistake: Treating successful builds as evidence of safety. An attacker does not need a failed pipeline when the objective is to execute quietly, stage access, or leak data through a trusted job.

Practitioner takeaway: The strongest signal is not a broken pipeline, but a pipeline that still appears healthy while doing work the change request never justified.