Why do CI/CD secrets become so dangerous when a workflow runs untrusted code with elevated permissions?

Why This Matters for Security Teams

CI/CD pipelines are attractive targets because they often hold the same trust as production automation while also handling secrets, build credentials, deployment tokens, and repository write access. When untrusted code runs in that same context, the attack surface shifts from source code review to execution-time compromise. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that access, privilege, and information flow controls must match the trust level of the component processing the data, not just the identity of the pipeline owner.

The practical issue is that secrets are not dangerous merely because they exist. They become dangerous when a job can read them, print them, reuse them, or exchange them for further access before the workflow completes. In a modern pipeline, a token may be sufficient to alter code, trigger releases, tamper with artifacts, or pivot into cloud infrastructure if it is scoped too broadly. The same problem appears when elevated permissions are granted for convenience and not reduced for untrusted paths.

In practice, many security teams encounter this only after a malicious pull request, compromised dependency, or poisoned build step has already turned a trusted automation lane into a secret-exfiltration path.

How It Works in Practice

The risk emerges from a combination of three conditions: untrusted input, privileged execution, and available secrets. If a workflow executes code from a pull request, dependency update, or generated artifact, that code may inherit the runner’s environment, filesystem, network access, and any injected credentials. Once the attacker can run commands, they can inspect environment variables, read temporary files, intercept process output, or use legitimate tools to call internal services.

Effective control design starts by separating what the workflow needs to build from what it needs to release. For example, a test job rarely needs write access to the repository or deployment systems. A build job may need an ephemeral token to fetch packages, but not a long-lived secret with broad cloud permissions. A deployment job may need privileged access, but that job should not process untrusted code at all. This is the core boundary that many teams blur.

• Minimise secret exposure by using short-lived credentials and workload identity where possible.
• Split workflows so untrusted jobs run without write permissions or secret injection.
• Use approval gates for release steps that require elevated access.
• Restrict what the runner can reach, including cloud metadata endpoints and internal admin APIs.
• Validate artifacts and dependencies before any privileged stage consumes them.

From an identity perspective, CI/CD secrets behave like non-human identities: they authenticate automation, not people, and they need lifecycle management, scope control, and rotation discipline. That is why the OWASP Non-Human Identity Top 10 is relevant here, especially where tokens are embedded into pipelines and reused across jobs. These controls tend to break down when a single workflow both tests untrusted code and performs privileged release actions because the same runner becomes both the attack surface and the trust anchor.

Common Variations and Edge Cases

Tighter secret controls often increase pipeline friction, requiring organisations to balance developer velocity against blast-radius reduction. That tradeoff is real, especially where release engineering depends on legacy jobs, third-party actions, or shared self-hosted runners.

Best practice is evolving for several edge cases. Some teams try to “mask” secrets in logs, but masking does not stop runtime exfiltration. Others rely on branch protections alone, but protections do not help if a privileged workflow is triggered by a manipulated event or a compromised maintainer account. In self-hosted runners, the problem is usually worse because the runner may persist after a job, retain cached credentials, or share a network segment with sensitive internal systems.

There is also no universal standard for every GitHub, GitLab, or managed CI implementation, so control design should be based on the workflow’s trust boundary rather than the platform’s default behaviour. Where a pipeline uses OIDC federation, the security posture is often better because ephemeral credentials reduce reuse risk, but that pattern still needs audience restriction, token lifetime limits, and clear separation between build and deploy contexts. The strongest approach is to treat untrusted execution as a low-trust zone and reserve secrets for isolated, narrowly scoped steps only.

For organisations mapping this to broader governance, the right question is not whether secrets are present, but whether any untrusted code path can reach them before the workflow’s privileged intent is proven.

Related resources from NHI Mgmt Group

• What breaks when a CI/CD workflow can access secrets from untrusted pull requests?
• What breaks when secrets are stored in code and CI/CD tools?
• What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?
• Who is accountable when an AI agent in CI/CD exposes secrets or pushes unauthorized code?