Look for unexpected workflow changes, unfamiliar package sources, sudden token revocations, unusual publishing activity, and secrets appearing where they should never be visible. A pipeline that regularly executes third-party code with broad access, or that cannot explain who can reach signing and deployment credentials, is already outside a safe trust boundary.
How CI/CD trust gets misused
CI/CD trust becomes dangerous when a pipeline is treated as implicitly trusted after a token, workflow, maintainer account, signing key, or build secret is exposed. At that point, the pipeline can be used to publish altered artifacts, reach protected deployment paths, or exfiltrate secrets that should never be visible to ordinary build steps.
The misuse usually starts with a trust shortcut: broad permissions, unpinned third-party actions, long-lived credentials, or a pipeline that can reach production without strong separation between build, test, signing, and release. Once an attacker reaches that trust boundary, the pipeline itself becomes the delivery mechanism.
One useful way to understand the problem is through proven supply-chain abuse patterns such as compromised build actions and malicious packages, where code that looks like routine automation is actually used to harvest credentials or alter release outputs. In practice, the question is not only whether the build ran, but whether the build should have been allowed to act with that much authority in the first place. Shai Hulud npm malware campaign shows how package trust can become a CI/CD secret exposure path, while reviewdog Action compromise 2025 shows how a poisoned action can turn trusted automation into a secret-stealing step.
What signs point to pipeline misuse, not just routine instability?
Look for evidence that the pipeline is acting outside its expected role. Unfamiliar package sources, unexpected workflow edits, sudden token revocations, unusual publishing activity, and secrets appearing in logs or artifacts all suggest that the trust boundary has already been crossed.
Also watch for behavior changes that are easy to dismiss as noise but are actually control failures: a workflow that begins running extra third-party code, a release job that now reaches signing or deployment credentials it never needed before, or repeated credential access from jobs that should be read-only. Those are not normal build variations, they are signs that authority is too broad or has been taken over.
CI/CD misuse often leaves a secondary trail in the release process. A clean commit history with a suspicious artifact, a legitimate build with unexpected outbound access, or a publishing event that cannot be tied back to an approved change path should all be treated as trust anomalies. ArtiPACKED 2024 is a good example of why artifacts and runtime tokens deserve the same scrutiny as source changes, and GhostAction campaign 2025 shows how a fake workflow can be used to blend into normal automation while exfiltrating secrets.
What to verify before you trust the next build
The key question is whether the pipeline can still prove who can reach the sensitive parts of the release path. If signing credentials, deployment tokens, or privileged runners are reachable without clear ownership and tight scoping, the pipeline should be treated as compromised or at least overtrusted until proven otherwise.
Verify the integrity of the workflow definition, the provenance of any third-party code it runs, and the permissions of the token used at each stage. You also need to verify whether secrets are ephemeral, whether they are exposed only to the smallest necessary job, and whether a build can fail closed when it encounters an unexpected dependency or publishing target.
That same verification mindset applies to the release channel. If artifact signing, trusted publishing, or provenance assertions cannot be tied to a known source and a restricted execution context, then the pipeline is still granting trust by habit rather than by design. CI/CD Pipeline Identity Security Guide is useful here because it focuses on OIDC federation, pinned actions, and publishing controls, while SLSA provides the broader build provenance model that helps prove whether an artifact really came from the expected pipeline.
Risk and Threat Considerations
Misused CI/CD trust is high impact because the pipeline sits close to the build, release, and signing path. When attackers reach that path, they can steal secrets, modify artifacts, publish malicious updates, or use the automation itself to reach systems that would otherwise resist direct access.
Failure mechanism: Excessive permissions, exposed tokens, untrusted third-party steps, or weak separation between build and release let an attacker convert routine automation into an execution channel for secret theft or artifact tampering.
Impact: The result can be credential compromise, poisoned releases, wider supply-chain exposure, and loss of confidence in the integrity of deployed software.
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 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD trust misuse often reveals secrets in logs, artifacts, or workflow output. |
| NHI-05 — Overprivileged NHI | Pipeline tokens and runners become risky when they can publish, sign, or deploy too broadly. | |
| NHI-07 — Long-Lived Secrets | Long-lived CI/CD credentials are a common misuse signal when trust is abused over time. | |
| Recommendation — Scan pipeline jobs for exposed secrets and revoke any credential that can be read by untrusted steps. Reduce pipeline permissions to the minimum needed for each job and separate build from release access. Replace durable pipeline secrets with short-lived credentials and rotate any exposed token immediately. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | CI/CD trust abuse often starts with stolen or weakly protected tokens used to impersonate automation. |
| API5 — Broken Function Level Authorization | The core issue is often whether a pipeline can perform publish or deploy actions it should not be allowed to do. | |
| Recommendation — Harden pipeline authentication and revoke any token that can authenticate outside its intended job. Enforce function-level authorization so build jobs cannot perform release actions by default. | ||
Practitioner Guidance
What to prioritise: Start with the jobs that can publish, sign, or deploy, because those are the places where trust abuse becomes externally visible fastest. Then review any workflow that imports third-party code, uses broad tokens, or can read secrets that are not required for its stated purpose.
What to verify: Confirm that each release step has a clear owner, a minimal permission set, and a narrow set of allowed inputs. If a step cannot explain why it needs signing keys, publishing tokens, or cross-environment access, treat that as an exception to be removed, not a convenience to preserve.
Practitioner takeaway: The safest CI/CD system is not the one that trusts the most code, it is the one that can prove exactly which build step was allowed to do what, with which credential, and under which boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org