Security teams should treat CI/CD as an execution environment with privileged pathways, not just build automation. Test for workflow injection, excessive token scope, unsafe pull request handling, and secrets that can be read from runner memory or logs. Then validate whether a low-friction path exists from a workflow trigger to repository access, cloud credentials, or production systems.
Testing the workflow as an attack path, not just a build step
CI/CD exposure becomes dangerous when a workflow can be influenced by untrusted input and then rewarded with repository, cloud, or deployment privilege. The test is therefore not whether the pipeline “runs,” but whether an attacker can steer what runs, where it runs, and what secrets or permissions are available at each stage. That means looking for injection points, privilege inheritance, and unsafe assumptions around pull requests, forks, reusable workflows, and self-hosted runners. For background on how adversary tradecraft maps to access, staging, and execution chains, the MITRE ATT&CK Enterprise Matrix is a useful reference point.
Security teams often miss that pipeline weakness is usually a trust-boundary problem, not a single misconfiguration. A job that looks harmless in isolation may become a cloud access path once it can read a token, call an API, or write an artifact that another system trusts. In practice, many teams discover CI/CD exposure only after a workflow shortcut has already enabled repository or cloud access through an assumed-safe automation path.
How to probe token scope, runner trust, and workflow inputs
A useful test plan starts with the trigger surface. Review whether pull requests from forks, manual dispatches, scheduled jobs, and reusable workflows behave differently, then check whether those paths inherit the same permissions as trusted branches. The key question is whether untrusted content can reach a privileged job context without a clear approval or isolation step. That includes workflow files that can be edited by contributors, scripts that consume pull request metadata, and conditions that decide whether secrets are exposed.
Next, test credential reachability. Validate what each job can see by default, including short-lived cloud credentials, repository tokens, deployment keys, and any secret mounted into the runner environment. Security teams should also inspect runner memory, logs, cached artifacts, and step outputs because secrets can leak through places that are not meant to be persistent storage. If the pipeline depends on artifact handoff or environment promotion, check whether a lower-trust stage can influence an output that a higher-trust stage later consumes.
- Confirm whether job permissions are reduced to the minimum needed for each workflow path.
- Check whether a forked pull request can trigger code paths that read secrets or publish artifacts.
- Test whether a reusable workflow can be invoked with attacker-controlled inputs that alter execution.
- Verify whether runner logs, caches, or artifacts expose tokens, paths, or generated credentials.
- Map the shortest path from workflow trigger to cloud API use, repository write, or deployment action.
Teams that already use identity-bound automation should treat each token and service account as an access boundary with its own lifecycle, not as a generic pipeline helper. For a control-oriented view of that boundary management, the OWASP Non-Human Identity Top 10 is directly relevant because it focuses on machine credentials, scope, and governance. This guidance breaks down when pipeline ownership is fragmented across development, platform, and cloud teams and nobody can show the full path from trigger to privilege.
Where CI/CD exposure becomes more dangerous than a normal misconfiguration
Tighter pipeline control often increases build friction, requiring organisations to balance developer convenience against the chance of turning automation into an access bridge. The most important edge case is when a workflow flaw is not enough by itself to cause compromise, but becomes serious because the pipeline can reach a trusted environment or mint a trusted identity. That is why the same weakness may be low impact in a sandbox and high impact in a release workflow.
There is also a difference between direct secret exposure and indirect trust abuse. A workflow may never print a secret, yet still let an attacker influence an artifact, package, or configuration file that a later job consumes as if it were trusted. That pattern matters in systems where promotion is automatic and there is little human review between stages. Guidance is still evolving on how much isolation is enough for reusable workflows and self-hosted runners, so organisations should be explicit about where they are following established practice and where they are making a local governance choice.
Cloud-connected pipelines also create a broader blast radius. A single workflow flaw can affect source control, deployment automation, infrastructure provisioning, and production access in one chain. The practical limit of any test is whether it models that full chain rather than checking only one permission at a time.
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 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Pipeline tokens, service accounts, and runner credentials are non-human identities in scope. |
| NHI-02 — Secrets and Credential Management | The question centres on secret exposure through runners, logs, and workflow execution. | |
| NHI-04 — Privilege and Authorization | Testing must confirm whether workflow triggers can inherit excessive permissions. | |
| Recommendation — Inventory every pipeline identity and assign clear ownership before testing access paths. Restrict secret reachability and validate where credentials can be read or exfiltrated. Reduce token scope and verify that each workflow path has only the permissions it needs. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | CI/CD weaknesses can be turned into trusted build and deployment abuse. |
| T1098 — Account Manipulation | Excessive automation permissions can let an attacker alter or extend trusted access. | |
| Recommendation — Map pipeline trust boundaries to T1195 and test how compromised automation could affect release stages. Hunt for workflow paths that can modify accounts, tokens, or deployment-linked permissions. | ||
| CIS Controls v8 | 6 — Access Control Management | The question is about reducing and testing the permissions available to pipeline identities. |
| 3 — Data Protection | Secrets in logs, artifacts, and runner memory are a direct data exposure concern. | |
| Recommendation — Audit pipeline access paths and remove unnecessary permissions from automation accounts. Classify and protect pipeline data so logs and artifacts cannot expose sensitive credentials. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization | Testing should confirm least-privilege behaviour across workflow triggers and jobs. |
| PR.DS-1 — Data-at-Rest Protection | Secrets and generated credentials may persist in artifacts, caches, or stored logs. | |
| Recommendation — Enforce least privilege for pipeline identities and verify permission boundaries on every trigger. Protect stored pipeline data so credentials are not recoverable from artifacts or logs. | ||
Practitioner Guidance
What to prioritise: Start with the workflow paths that can touch production, cloud credentials, or repository write access. Those are the places where a small input-handling flaw becomes an access problem rather than a simple build failure.
What to verify: Prove, for each trigger type, whether untrusted content can reach a privileged job and whether the job can see secrets, mint tokens, or invoke deployment APIs. If you cannot demonstrate that separation clearly, treat the pipeline as exposed.
Common mistake: Teams often test only for secret leakage and miss the larger issue of trust inheritance. A pipeline can be compromised through control flow, artifact trust, or credential scope even when no secret is printed in plain text.
What good looks like: The test results should show a narrow and explainable path from trigger to privilege, with clear isolation between untrusted and trusted execution. If the path is ambiguous, the design is still too permissive.
Practitioner takeaway: CI/CD exposure becomes actionable when the pipeline can convert untrusted influence into trusted execution, so the decisive question is not “can it run?” but “what can it reach if it is steered?”
Related resources from NHI Mgmt Group
- How should security teams implement access control lists in CI/CD pipelines to avoid privilege creep and pipeline tampering?
- How should security teams validate their exposure to a Linux kernel privilege escalation flaw before attackers use it in production?
- How should security teams use runtime detections to reduce cloud breach impact before attackers escalate access?
- How should security teams prepare for credential exposure in developer, cloud, and AI workflows before attackers exploit it?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
