Living Off The Pipeline describes abuse of build-time tools, scripts, or automation components that were never meant to process attacker-controlled input. The attacker uses legitimate pipeline behavior as the execution path, often gaining command execution, secret access, or control over generated artifacts without modifying the main source branch.
Expanded Definition
Living Off The Pipeline is a supply-chain abuse pattern in which an attacker turns trusted build or delivery automation into the execution environment. The pipeline itself is not the target in the abstract; its scripts, runners, plugins, and helper steps become the path through which untrusted input is processed and trusted actions are performed.
This is different from source-code tampering alone. The attacker may never need to change the main branch if they can influence a build trigger, an environment variable, a script argument, a template, or a dependency fetched during the workflow. The result is usually command execution, secret exposure, or artifact manipulation inside a system that is assumed to be routine and safe.
The common boundary mistake is to treat CI/CD as a purely internal build concern. In practice, pipeline logic often spans identity, secrets, artifact signing, deployment privileges, and third-party integrations, so misuse can cross multiple trust boundaries at once.
Examples and Use Cases
Living Off The Pipeline usually appears where automation is highly trusted but only lightly isolated. It is most visible in systems that mix code execution with credentials, deployment rights, or reusable build logic.
- A pull request triggers a job that runs a script with attacker-influenced parameters, and the script interprets them as shell input.
- A build step reads environment data or repository metadata and passes it to helper tooling that was never designed for hostile content.
- A shared runner executes a pipeline component that can reach signing keys, package registries, or deployment APIs.
- A reusable workflow or template is invoked across projects, so a single weak assumption about input handling affects many pipelines.
- A compromised dependency or build plugin is used to steer output artifacts without visibly altering the main application code.
One tradeoff is that the same flexibility that makes pipelines fast and reusable also expands the number of places where trust can be misapplied. Security teams often need to distinguish between legitimate automation complexity and unsafe implicit trust.
Security Implications
The security problem is not only that a pipeline can be abused, but that it is often over-privileged by design. Build systems frequently hold source access, secret material, artifact publishing rights, and sometimes downstream deployment authority, which makes a single weak step disproportionately valuable.
When Living Off The Pipeline is misunderstood, teams may focus only on repository protection while ignoring the execution layer. That leaves a gap where attacker-controlled input can be converted into command execution, secret theft, unsigned artifact creation, or stealthy workflow modification. Because the activity occurs inside expected automation, it may blend into normal build noise rather than look like a distinct intrusion.
A practical symptom is that the compromise does not begin with a visible code change. Instead, the pipeline behaves as if it is doing ordinary work while quietly processing data in a way that breaks the trust boundary.
Domain and Governance Relevance
For software supply chain governance, this term sits at the boundary between build integrity, secrets handling, and privilege control. The core governance question is whether pipeline components are trusted only for their intended function, or whether they are being used as a broad execution surface with hidden authority.
In NHI terms, the issue often overlaps with non-human identities because pipelines commonly authenticate as service accounts, signing principals, package publishers, or deployment actors. That means machine credentials and their privilege scope become part of the attack path, not just a supporting detail.
The governance challenge is to assign clear ownership for pipeline identities, secret exposure, and reuse patterns. Where those controls are vague, abuse can persist across many runs, many repositories, and many environments even if the source branch itself remains clean.
Risk and Threat Considerations
Living Off The Pipeline creates concentrated exposure because trusted automation can become both the execution path and the credential path. The material risk is privilege abuse inside build and delivery systems that were assumed to be non-interactive and therefore safe from hostile input.
Failure mechanism: attackers exploit unsafe input handling, overbroad runner permissions, inherited environment variables, or reusable workflow trust to run commands, read secrets, or alter artifacts from within the pipeline.
Impact: compromised builds, secret disclosure, poisoned packages, unsigned or manipulated releases, and downstream deployment of untrusted code can follow without a visible source-branch change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 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 | T1059 — Command and Scripting Interpreter | Pipeline abuse often turns scripts and build steps into command execution paths. |
| T1552 — Unsecured Credentials | Abused pipelines often expose secrets through environment, runner, or build context. | |
| Recommendation — Map risky pipeline script execution to T1059 and restrict attacker-influenced input to interpreter contexts. Hunt for secret exposure under T1552 and reduce credential visibility inside build jobs. | ||
| CIS Controls v8 | 6 — Access Control Management | Pipeline abuse is amplified when build and deployment identities have excess access. |
| 16 — Application Software Security | Build and release automation is part of the application security surface for this term. | |
| Recommendation — Apply CIS Control 6 to tighten pipeline account access and remove unnecessary publishing or deployment rights. Use CIS Control 16 to secure build logic, scripts, and release workflows against unsafe execution paths. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations are Managed | Pipeline runners and service identities need least-privilege authorization to limit abuse. |
| PR.DS-5 — Integrity Checking Mechanisms are Implemented | Artifact tampering and poisoned outputs are core integrity concerns in pipeline abuse. | |
| Recommendation — Enforce PR.AC-4 to scope pipeline permissions to the minimum needed for each job. Apply PR.DS-5 to verify build output integrity before publishing or deployment. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Pipeline abuse often targets machine credentials, tokens, and signing material. |
| Recommendation — Use NHI-01 to inventory, protect, and rotate pipeline secrets and machine credentials. | ||
Practitioner Guidance
Why practitioners should care: pipeline abuse is often a privilege problem disguised as an automation problem. If a build step can access secrets or publish artifacts, it needs the same ownership discipline and trust review as any other execution boundary.
Common misunderstanding: teams sometimes assume that a clean repository means a clean release path. In reality, the abuse may occur in scripts, templates, or inherited runner context that never appear in the primary code review conversation.
Practitioner takeaway: Treat pipeline identity, input handling, and secret reachability as first-class security objects, not incidental implementation details.
Related resources from NHI Mgmt Group
- How can organisations detect living-off-the-land attacks against AI identities?
- How should security teams detect living-off-the-land attacks in hybrid environments?
- Why do living-off-the-land attacks bypass so many traditional controls?
- How can organisations reduce the impact of living-off-the-land activity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
