Untrusted code execution happens when a pipeline runs code or build logic that an attacker can influence. In practice, this usually means contributor input, modified workflow files, or imported steps that are not sufficiently constrained. It is a common path to secret exposure, artifact tampering, and broader supply chain compromise.
Expanded Definition
Untrusted code execution refers to any situation where a build, test, deployment, or automation pipeline runs logic that the organisation does not fully control. The important boundary is not simply whether the code is “external” or “open source”, but whether the runtime has been allowed to interpret it with privileges, network reach, or secret access that exceed its trust level.
This term is often used in software supply chain and CI/CD discussions to describe a control failure rather than a language feature. A workflow file, plugin, script, dependency hook, or build step can all become an execution path if the pipeline treats attacker-influenced content as executable. That is why the practical question is not “is the code malicious by default?” but “what can the pipeline be induced to run, and with what authority?”
A common misunderstanding is to treat review of source repositories as sufficient protection. In reality, trust decisions often live outside the application code itself, in automation definitions, runner permissions, and step injection points. Guidance vs consensus: there is broad agreement that untrusted execution is dangerous, but teams differ on how much sandboxing is enough for shared runners and contributor workflows.
Examples and Use Cases
Untrusted code execution appears in several routine engineering patterns:
- A pull request modifies a CI workflow so that a job executes attacker-controlled commands during validation.
- A build system runs post-install scripts from a dependency without constraining what those scripts can read or transmit.
- A reusable automation step is imported from another repository and executed with broader permissions than the original repository owner intended.
- A test harness processes repository content as code, turning input that should have been data into executable logic.
- A deployment pipeline allows contributor-controlled branches to trigger privileged jobs on shared infrastructure.
The operational tradeoff is that modern delivery pipelines rely on code execution for speed and flexibility, but every new execution point expands the trust boundary. Security teams therefore need to distinguish between code that is intentionally executed under controlled conditions and code that becomes executable because the pipeline accepts it too broadly.
For readers mapping this to supply chain governance, the key issue is not just source provenance but execution context. The same artifact can be harmless in one stage and highly sensitive in another if it inherits credentials, signing rights, or release authority later in the pipeline.
Security Implications
When untrusted code execution is permitted, the most immediate consequence is loss of control over what the automation environment can reveal or modify. A malicious or compromised step can read environment variables, exfiltrate tokens, tamper with build outputs, alter release metadata, or implant backdoors in artifacts that downstream systems trust.
The failure mechanism is usually straightforward: a pipeline grants execution before it has established isolation, provenance, or least privilege. Once attacker-influenced logic runs, the environment itself becomes part of the attack surface. This is especially damaging in CI/CD because build systems are often connected to source control, package registries, signing services, and deployment targets at the same time.
Practitioners should watch for symptoms such as unexpected network access from build jobs, workflow changes that increase privilege, or jobs that behave differently for external contributions than for trusted branches. The blast radius grows quickly when the same runner handles both untrusted inputs and sensitive release operations.
Domain and Governance Relevance
In software supply chain security, untrusted code execution matters because it turns a delivery pipeline into an enforcement point for trust. The concept is not limited to application compromise; it also affects artifact integrity, release assurance, and whether downstream consumers can rely on the resulting package or image.
Where non-human identities are involved, the governance question becomes sharper. A pipeline or automation agent that can execute untrusted logic often also carries machine credentials, signing privileges, or deployment authority, so the execution path and the identity context must be governed together. That does not make every pipeline an NHI problem, but it does mean that machine permissions become part of the risk boundary when code execution and release authority converge.
For an organisation, the practical implication is clear: execution trust, identity trust, and artifact trust cannot be managed as separate concerns when the same automation path can write code, sign code, and publish code.
Risk and Threat Considerations
Untrusted code execution creates a direct supply chain exposure because attacker-influenced logic can run inside a trusted automation boundary. The risk is not limited to malware in source code; it includes workflow injection, dependency script abuse, and build-time command execution that inherits sensitive context.
Failure mechanism: the attacker relies on the pipeline to execute content before the system has constrained permissions, isolated secrets, or verified provenance. Once that happens, the untrusted step can steal tokens, alter build outputs, or pivot into signing and deployment systems.
Impact: secret exposure, tampered artifacts, compromised releases, and loss of trust in the delivery chain. In a worst case, downstream consumers receive a package or image that appears legitimate but was produced under attacker control.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Untrusted execution often abuses excessive pipeline privileges. |
| 16 — Application Software Security | Build and workflow logic must be validated before execution. | |
| 3 — Data Protection | Build jobs can expose secrets and sensitive variables during execution. | |
| Recommendation — Restrict pipeline permissions to the minimum needed for each job. Harden build and workflow logic against injection and unauthorized changes. Protect secrets from exposure in untrusted execution contexts. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Pipeline jobs should not inherit broad authority by default. |
| PR.DS-1 — Data-at-Rest Security | Sensitive build data and credentials must not be readable by untrusted steps. | |
| PR.IP-1 — Baseline Configuration Management | Workflow definitions are part of the trusted build baseline. | |
| Recommendation — Enforce least-privilege authorization for automation and build jobs. Limit secret exposure to trusted stages and protected environments. Control and review workflow changes before they can execute in production paths. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | The core abuse is attacker-influenced code being interpreted by automation. |
| T1195 — Supply Chain Compromise | This term is a common supply-chain compromise mechanism in pipelines. | |
| Recommendation — Detect scripted execution paths that can be influenced by untrusted inputs. Hunt for build and release paths that can be subverted by upstream changes. | ||
Practitioner Guidance
Why practitioners should care: treat every place where automation interprets contributor-influenced logic as a control decision, not a convenience feature. The critical judgment is whether that execution point can reach secrets, signing material, or publish paths without a stronger trust boundary.
Common misunderstanding: teams often assume repository review or branch protection is enough, but the dangerous part is frequently the runtime context, not the code review process. If a job can execute untrusted input with broad environment access, the approval workflow does not remove the exposure.
Related resources from NHI Mgmt Group
- Who is accountable when a model loader turns untrusted input into code execution?
- Who is accountable when untrusted code execution depends on both interpreter controls and host isolation?
- Who is accountable when a parser lets untrusted input reach a command line and enables remote code execution?
- Why does untrusted input driving reflection create such a high risk of remote code execution?
