The pipeline can execute attacker-controlled code without the workflow file itself being modified. A malicious config file, local action, or plugin can trigger arbitrary commands, exfiltrate secrets, alter build logic, or fetch hostile dependencies. In practice, the compromise looks like a normal job run until the hidden context file changes the tool’s behaviour.
Why Untrusted Repository Content Changes the Trust Boundary
When a pipeline consumes local actions, custom plugins, or configuration from the repository it is building, the repository is no longer just source code. It becomes an execution input, which means an attacker who can influence that content can affect build-time behaviour even if they never touch the workflow definition itself. That matters because the compromise often blends into ordinary CI activity and can undermine code integrity, secret handling, and release trust.
In practice, teams often discover the issue only after a build has already executed repository-controlled logic that was assumed to be passive content.
How the Compromise Works in a Real Pipeline
The key security mistake is treating repository content as data when the pipeline actually interprets it as instructions. A local action, custom plugin, or build-time config file can change command flow, dependency resolution, environment handling, or artifact generation. If the pipeline grants the job access to secrets, caches, signing material, or privileged network paths, the malicious content can use that access exactly as a trusted build step would.
This is why the threat is not limited to obvious script injection. The more dangerous pattern is delegation: the pipeline loads code or configuration from a place the attacker can influence, then runs it with the pipeline’s authority. That can produce arbitrary command execution, but it can also create quieter outcomes such as altered binaries, poisoned test results, or fetched dependencies that introduce a second stage of compromise.
- Local actions can execute repository-controlled code in the runner context.
- Custom plugins can extend the build system with attacker-chosen behaviour.
- Config files can steer tools toward hostile commands, paths, or dependencies.
- Secret exposure becomes likely when build-time steps inherit broad environment access.
In environments that use reusable build components, the trust problem can extend beyond a single repository because one poisoned input may be consumed across multiple jobs or downstream releases. The NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant here because they emphasise control over software, configuration, and privileged execution paths. Where pipelines automatically accept repository-supplied execution logic, those controls are only as strong as the boundary between reviewed workflow code and unreviewed repository content.
The guidance breaks down when the pipeline cannot reliably distinguish trusted build logic from repository-controlled behaviour, because at that point the repository itself becomes part of the attack surface.
Where the Trust Model Breaks Down
Tighter build automation often increases exposure if it pulls more behaviour from the repository, so teams have to balance convenience against execution trust. The standard model is strongest when workflow code is fixed and reviewed separately from project content; it weakens when the pipeline loads scripts, plugins, or context files that can vary with each commit or pull request.
There are a few common edge cases. Some organisations assume that a file is safe because it is “just configuration,” but many build tools treat configuration as executable control data. Others allow custom plugin ecosystems for developer productivity, then overlook that plugin installation is effectively code execution inside the pipeline. A third variation is partial trust, where only some branches or contributors can change the file, which can still be enough if an attacker reaches the repository or if a dependency chain can be abused.
Guidance is not fully consistent across all CI/CD products on how much repository content should be considered trusted by default. The practical rule is to treat any repository-controlled file that influences execution as part of the privileged attack surface, especially when it can reach signing, publishing, or secret-bearing steps.
The boundary fails most sharply when the pipeline auto-loads repository-supplied logic without a separate trust decision for that content.
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 surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Repo-controlled actions or plugins can invoke shell or script execution during builds. |
| Recommendation — Restrict and monitor script execution paths in pipelines that can be influenced by repository content. | ||
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Untrusted config files and plugins are a secure configuration and software control issue. |
| Recommendation — Harden build and runner configurations so repository-supplied files cannot alter trusted execution paths. | ||
| NIST CSF 2.0 | PR.IP-1 — Baselines are created, maintained, and published | Pipelines need controlled baselines so build logic is separated from mutable repo content. |
| PR.AC-5 — Network integrity is protected | Malicious build inputs may fetch hostile dependencies or exfiltrate data over network paths. | |
| Recommendation — Establish and enforce trusted build baselines that keep execution logic distinct from source content. Limit pipeline network paths so repository-controlled steps cannot freely reach untrusted destinations. | ||
| PCI DSS v4.0 | 6.2.4 — Change control procedures | Repository-driven build changes should be reviewed and controlled before execution reaches production. |
| Recommendation — Require formal review of build-impacting changes that can introduce code execution or dependency drift. | ||
Practitioner Guidance
What to prioritise: Separate reviewed workflow definitions from repository-controlled execution inputs, and treat anything that can invoke code, plugins, or dynamic commands as privileged. If the build system cannot enforce that separation, assume the repository content can steer the job.
What to verify: Check whether local actions, plugin discovery, config parsing, or dependency hooks can execute before a trust decision has been made. Also verify which jobs can reach secrets, signing keys, artifact publication, or outbound network access, because those are the points where benign-looking repository content becomes material risk.
Common mistake: Teams often harden the workflow file while leaving plugin paths, config loaders, and build-time extensions unchecked. That leaves a side channel for attacker-controlled behaviour that bypasses the review process entirely.
Practitioner takeaway: If repository content can alter execution, the real control question is not whether the workflow was reviewed, but whether untrusted inputs were ever allowed to become code in the first place.
Related resources from NHI Mgmt Group
- Why are local .env files and config notes risky in Microsoft 365?
- How should security teams secure local AI runtimes that load untrusted model files or prompts?
- What happens when a privileged helper tool accepts untrusted file paths from a local client request?
- What happens when self-hosted GitHub Actions runners are used for untrusted workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
