Do not pass long-lived secrets to jobs that run untrusted pull request code. Use least-privilege tokens, separate trusted and untrusted workflows, and keep secrets unavailable until the job has passed any code review or approval gate. Limit repository and environment permissions, and watch for unexpected secret access, exfiltration attempts, or workflow steps that read environment variables or files.
Why untrusted CI code becomes dangerous as soon as secrets are available
The core issue is not just code execution, it is secret exposure under a trust boundary you do not fully control. If untrusted pull request code can read environment variables, mounted files, tokens, or inherited process context, it can copy credentials out before any human notices. That is why CI design has to separate “can run code” from “can see secrets.”
Untrusted workflows should be treated as adversarial until they pass the repository’s approval path. In practice, that means secret-bearing jobs must be isolated from jobs that compile, test, or lint code from outside contributors. The same principle applies to logs, caches, artifacts, and helper actions, because each of those paths can become a covert exfiltration channel.
For implementation guidance on the broader CI/CD identity and secret boundary, CI/CD Pipeline Identity Security Guide is the best starting point. For the secret-handling side of the problem, Secrets Management Guide explains why secretless or short-lived credential patterns reduce blast radius when pipeline code cannot be fully trusted.
What to change in the workflow design
The safest pattern is to make the untrusted part of the pipeline incapable of reaching production secrets at all. Use separate workflows or jobs for untrusted contributions, keep protected secrets behind approval gates, and only inject credentials after the job context is verified. When a workflow only needs read-only access or metadata access, give it that and nothing more.
Least-privilege tokens matter here because CI often over-issues access by default. Repository-scoped or environment-scoped permissions should be narrowed to the smallest action set, and the default token should be reduced wherever the platform allows it. If the job only needs to comment, fetch artifacts, or publish status, it should not also be able to read deployment secrets or write repository contents.
For the credential model itself, dynamic or short-lived secrets are materially safer than long-lived static values, especially when jobs are run on branch or pull-request code. NHIMG’s Ultimate Guide to NHIs, Static vs Dynamic Secrets covers the lifecycle trade-off, and the OWASP Non-Human Identity Top 10 reinforces why overprivileged, long-lived, or reused secrets are especially risky in automated environments.
Where possible, prefer federated or keyless patterns over embedded credentials. That shrinks the window in which a compromised workflow can reuse a secret and makes revocation easier when the pipeline is suspected of misuse.
How to detect leakage attempts and respond fast
Protection is incomplete unless you also assume some workflows will try to read more than they should. Watch for steps that print environment values, enumerate filesystem paths, access credential stores, or attempt outbound network calls immediately after secret material becomes available. Those are often the earliest signs that a job is probing for what it can steal.
If you see suspicious access, treat the workflow run as potentially compromised even if the build eventually fails. The right response is to stop the run, revoke any credentials that were exposed, invalidate active sessions where applicable, and review whether artifacts, logs, or caches contain copied secret material. If the secret could authenticate outside the pipeline, assume it may need rotation.
The practical lesson is that CI secret safety is about blast-radius control, not just hiding values. Guide to the Secret Sprawl Challenge is useful when you need to track down where credentials accumulate, while tj-actions/changed-files compromise 2025 shows how poisoned workflow components can expose secrets even when the repository owner thinks the code path is routine.
Risk and Threat Considerations
Once untrusted code can execute in a privileged workflow, the main threat is secret theft followed by downstream abuse. The attacker does not need to “break” the CI system if the pipeline hands over credentials, because a single readable token can be enough to move from pull request execution to repository access, package publishing, cloud control, or deployment abuse.
Failure mechanism: Untrusted workflow steps inherit secrets, read them from memory or files, and exfiltrate them through logs, artifacts, outbound requests, or poisoned helper actions before the job is reviewed or terminated.
Impact: A leaked CI secret can become immediate repository compromise, supply-chain abuse, unauthorized deployment, or broader environment access until the credential is revoked and any dependent trust paths are reset.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI workflows can leak credentials to untrusted code through logs, files, or env vars. |
| NHI-05 — Overprivileged NHI | CI tokens and service credentials are non-human access material that should be least privilege. | |
| NHI-07 — Long-Lived Secrets | Long-lived CI credentials increase blast radius when untrusted code can execute in the pipeline. | |
| Recommendation — Prevent secret leakage by withholding secrets from untrusted jobs and tightening runtime exposure. Scope CI credentials to the minimum permissions needed for each workflow step. Replace static CI secrets with short-lived or federated credentials where possible. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | CI tokens and federated credentials are authentication material that must not be exposed to untrusted jobs. |
| Recommendation — Harden token issuance and prevent untrusted workflow code from accessing authentication material. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | CI workflows need least-privilege access and controlled permission boundaries for secrets. |
| Recommendation — Restrict workflow permissions so untrusted jobs cannot reach sensitive resources. | ||
Practitioner Guidance
What to verify: Confirm that pull-request jobs cannot access deployment secrets, signing keys, production cloud tokens, or reusable environment variables. Also verify that approval gates are enforced before secret injection, not after the job has already started with elevated context.
Common mistake: Teams often protect the secret value but forget the surrounding channels, especially logs, artifacts, caches, and third-party actions. If any of those can carry copied credential material out of the run, the workflow is still unsafe.
What good looks like: Untrusted code can run tests and checks, but it cannot reach long-lived secrets, cannot write to sensitive targets, and cannot silently expand its permissions during execution. The trust boundary is visible in the workflow design, not just in policy text.
Practitioner takeaway: Treat CI secrets as injectable authority, not as harmless configuration, and only release that authority after the code path has crossed the same trust gate you would require for production access.
Related resources from NHI Mgmt Group
- What breaks when CI/CD workflows can run untrusted code with privileged tokens?
- Why do CI/CD secrets become so dangerous when a workflow runs untrusted code with elevated permissions?
- How should organisations respond when NHI secrets are exposed in code or CI pipelines?
- What breaks when secrets are stored in code and CI/CD tools?