TL;DR: Splitting CI and deployment workflows is not enough if the same execution environment, runner, credentials, or artifact path can still bridge test code into production authority, according to Testifysec. The practical lesson is that untrusted jobs need scoped permissions, short-lived credentials, protected promotion decisions, and verified artifacts.
At a glance
What this is: Testifysec shows that CI/CD separation fails when workflow boundaries are only YAML-deep and not enforced across runners, credentials, and artifacts.
Why it matters: Identity and platform teams need to treat CI/CD jobs as trust domains, because untrusted build steps can inherit deployment authority, signing power, or cloud access if controls are shared.
Context
CI/CD pipelines are not isolated just because they use separate files or stages. The real control boundary sits around the code that runs, the credentials it can access, the runner it shares, and the artifacts that move between jobs.
This matters to IAM and NHI governance because build and deployment systems routinely rely on service accounts, tokens, signing keys, and cloud federation. When those non-human identities are not scoped to a job or environment, a low-trust test step can become a deployment path.
The article's starting position is typical: many teams separate workflow definitions before they separate authority, which leaves the operational trust model weaker than the visual one.
Key questions
A: Split the workflow, but more importantly split the trust boundary. Untrusted jobs should not share runners, credentials, signing authority, or artifact paths with deployment steps. If they do, a malicious dependency or workflow change can cross from test execution into release authority even when the YAML files look separate.
Q: Why do short-lived credentials still need tight trust policies in CI/CD?
A: Short-lived credentials reduce persistence, but they do not reduce the blast radius of a bad issuance decision. If the repository, environment, branch, or job conditions are too broad, the token can still be issued to the wrong workflow and misused before expiry. The control is as much about who can receive the credential as how long it lasts.
Q: What breaks when deployment approval sits inside the same code path being released?
A: The approval can no longer be trusted as an independent control. If the evaluated code can also influence the environment policy, artifact path, or policy administration, then approval becomes part of the attack surface. Protected promotion needs authority that the release candidate cannot modify or inherit.
A: Artifact verification proves that the object being promoted is the exact one that passed the gate. Observability only shows what happened during execution and may miss secret access, payload changes, or transient abuse. Useful evidence is not the same as control, so both are needed but they answer different questions.
Technical breakdown
Why separate CI and deployment workflows still share risk
A workflow split only reduces risk if the execution context is also split. If untrusted tests, privileged deployment steps, and signing actions share a runner, artifact store, or credentials cache, the boundary is architectural rather than procedural. A malicious dependency can alter test output, steal a token, or influence the next stage through an artifact that appears legitimate. The security issue is not the YAML file, but the trust inheritance that survives across jobs and environments.
Practical implication: Treat runners, artifacts, and job credentials as separate control points, not as details hidden inside the same pipeline.
Why OIDC federation is safer but not self-securing
OIDC federation replaces stored cloud credentials with short-lived credentials issued under trust policy conditions. That removes one persistence mechanism, but it does not remove the need to define who may receive the token, under which repository or environment claims, and for how long. A token can still be stolen during its validity window, and a weak trust policy can still issue it to the wrong job. Federation changes secret storage, not the need for authorization discipline.
Practical implication: Bind OIDC issuance to narrow claims and minimal permissions so the token is only usable by the intended workflow stage.
How artifact verification and protected promotion close the last gap
Promotion controls matter because the build that is approved is not always the build that is deployed. Artifact verification checks that the promoted object is exactly the one that passed earlier gates, while protected environments keep approval authority outside the evaluated code path. Negative testing is useful here because it proves that missing evidence, altered artifacts, or untrusted producers fail closed instead of falling through to production. Without that check, trust can leak through the release path even when earlier tests looked clean.
Practical implication: Require signed or verified artifacts and keep approval authority separate from the code and pipeline being evaluated.
Threat narrative
Attacker objective: The attacker wants to turn a low-trust test or build step into a path for deployment authority, secret theft, or release manipulation.
- Entry occurs when untrusted code, a malicious dependency, or a workflow change runs inside a CI job that has more authority than the test requires.
- Credential access follows when that job can reach deployment credentials, signing authority, or cloud federation tokens within the shared execution boundary.
- Impact occurs when the stolen or misused authority is used to promote an altered artifact, reach sensitive services, or publish unsafe code into a protected environment.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CI/CD isolation is a trust-boundary problem, not a file-structure problem. Separate YAML files are useful for governance, but they do not stop credential reuse, runner reuse, or artifact reuse. The real control question is whether an untrusted job can influence a later privileged job without crossing an explicit security gate. Practitioners should design CI/CD as an identity- and authority-separation problem, not as a repository hygiene exercise.
Short-lived credentials only work when the trust policy is narrower than the pipeline. OIDC removes stored secrets from the runner, but it also makes claim design the new control surface. If the repository, branch, environment, and job conditions are too broad, the token becomes a movable credential with a short expiry instead of a confined one. The practitioner takeaway is to govern issuance conditions as tightly as the permissions themselves.
Protected promotion is the missing control in many deployment chains. Approval authority, environment policy, and artifact verification need to sit outside the code path that produces the release candidate. This is especially important where service accounts, signing keys, and deployment tokens act as non-human identities with durable authority. Security teams should treat promotion as an identity decision, not just a delivery step.
Artifact integrity now defines whether CI is evidence or an attack surface. Build evidence helps, but observation alone does not prevent exfiltration or malicious state change during execution. That means the decisive governance concept here is artifact trust under constrained execution, not broader observability. Teams that cannot verify origin, immutability, and promotion conditions are still accepting unbounded release risk.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Secrets Management Guide
What this signals
CI/CD trust boundary drift: the common failure mode is assuming that separate workflow files equal separate authority. In practice, the runner, the artifact handoff, and the credential issuance path are where untrusted code can still cross into privileged execution, so governance has to move from pipeline shape to pipeline authority.
Identity and access controls are now release controls. When service accounts, signing keys, and cloud federation are available inside build jobs, IAM scope and promotion policy become part of software delivery assurance. Teams that manage those non-human identities as durable infrastructure risk turning a build pipeline into an indirect privilege-escalation path.
For practitioners
- Scope untrusted jobs to minimal repository permissions Remove deployment and signing authority from test jobs, and keep their access limited to the exact resources needed for validation.
- Separate runners for trusted and untrusted execution Do not reuse a privileged self-hosted runner for untrusted work unless the reset, isolation, and cleanup boundary is demonstrably stronger than the threat.
- Bind OIDC trust to narrow claims Configure cloud trust policies for the intended repository, environment, and other emitted claims, then limit the token's permissions and lifetime.
- Verify the exact artifact before promotion Reject rebuilt substitutes, missing evidence, or changed artifacts, and keep approval and policy administration outside the code path being evaluated.
- Test the negative cases before release Confirm that untrusted producers, failed evidence, and altered artifacts are blocked before the protected action can execute.
Key takeaways
- CI/CD separation only works when the execution environment, credentials, and artifact flow are also separated.
- Untrusted build steps can still reach deployment authority if runners and secrets are shared across jobs.
- Protected promotion, verified artifacts, and narrowly scoped OIDC issuance are the controls that change the risk profile.
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 NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD jobs can expose deployment secrets through shared runners and artifacts. |
| NHI-05 — Overprivileged NHI | The article centres on jobs that carry more authority than their task requires. | |
| NHI-07 — Long-Lived Secrets | OIDC is presented as the alternative to stored credentials in pipelines. | |
| Recommendation — Scan build and deployment paths for secret leakage and remove credentials from untrusted jobs. Reduce NHI permissions so test workflows cannot access deployment or signing authority. Replace long-lived pipeline secrets with short-lived credentials and narrow their issuance conditions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about scoping job permissions and deployment authority. |
| Recommendation — Review CI/CD entitlements so each job has only the permissions needed for its stage. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifetime, issuance and protection are central to the trust model discussed. |
| Recommendation — Manage pipeline authenticators so tokens are short-lived, scoped, and revoked when no longer needed. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat path is secret theft in CI/CD followed by movement into deployment authority. |
| Recommendation — Map CI/CD abuse to credential access and lateral movement to prioritise detection and containment. | ||
Key terms
- Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
- Artifact Verification: Artifact verification is the process of checking a release package against a trusted signature or checksum before use. It gives teams confidence that the software came from the intended publisher and was not modified in transit. Verification is especially important for security controls that influence production access decisions.
- Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security, IAM, and platform teams apply identity controls where automated systems carry real authority.
Published by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org