How should teams handle a CI/CD pipeline when untrusted test jobs share the same environment as deployment steps?

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.

The core issue is not just environment separation, it is authority separation. Test code can be hostile by design, so any shared runner, shared workspace, shared cache, or shared signing path gives that code a route into release capability. Once a job can write where deploy steps read, it can alter artifacts, credentials, provenance, or metadata without changing the visible pipeline structure.

In practice, the dangerous overlap is usually less obvious than a single shared server. Reused containers, mounted volumes, shared artifact stores, and long-lived runner tokens can all let a test job influence the deployment step even if the jobs appear to be different stages. That is why pipelines need a boundary that survives malicious dependencies, forked pull requests, and compromised build steps, not just a tidy YAML layout. See SLSA for a provenance-centered view of build integrity, and CI/CD Pipeline Identity Security Guide for how runner trust, token scope, and publishing authority should be separated.

Untrusted jobs should be treated as code execution with adversarial intent. If they can observe or modify the same filesystem, secret store, image cache, or artifact registry used by deployment, then the release step is no longer isolated from the test step. The workflow may still “work,” but the trust boundary has already collapsed.

Where shared runners and shared artifacts create the real failure mode

The most common failure is artifact confusion: a test job produces something that the deployment step later treats as trusted output. That can be a binary, package, checksum, manifest, release note, or container image tag. If the same path, cache, or registry namespace is reused, a malicious or compromised test job can swap in a payload that deploys with release authority.

Another common failure is credential spillover. Deployment tokens, signing keys, and cloud publish credentials should never be reachable from jobs that execute untrusted code. Once those values are present in the same execution context, a test dependency or malicious script can exfiltrate them, then use them later to publish altered artifacts, sign poisoned releases, or push tampered workflows. NHIMG’s ArtiPACKED 2024 shows how artifact handling alone can expose live tokens, while reviewdog Action compromise 2025 illustrates how one compromised CI component can cascade into broader secret exposure.

Shared infrastructure also weakens detection. If test and deploy jobs reuse the same identity, logs, or workspace, it becomes much harder to tell whether a release artifact came from a controlled build or from an injected step. The practical question is not whether the jobs are logically separated in the pipeline, but whether the deployment step can prove the thing it consumes was created in a context the test job could not influence.

What a safe split looks like in practice

A sound design gives untrusted jobs and deployment steps different runners, different credentials, different artifact paths, and different retention rules. In mature setups, test jobs run on ephemeral infrastructure with no publishing authority, while deployment jobs run in a narrow, approved path that only consumes verified outputs. That split should extend to caches, registries, and signing services, not just the visible job graph.

Where teams use a shared platform, the safer pattern is to make the handoff one-way and attestable. The test phase should produce an artifact that the deploy phase can verify by digest, signature, or provenance, rather than by trusting the workspace where it happened to appear. This is where RFC 7523 is useful for replacing shared secrets with signed client assertions, and where NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame the separation of access, authentication, and configuration control.

The best indicator that the split is real is simple: an untrusted job should be able to fail, be replaced, or be malicious without increasing the release authority available to any other job. If a test job can still touch the same signing key, publish token, or artifact namespace that deployment uses, the pipeline is still coupled.

Risk and Threat Considerations

When test and deployment environments share trust, the main risk is poisoned release authority. A malicious dependency, compromised action, or workflow change can move laterally from test execution into signing, publishing, or artifact selection, even if the YAML looks segmented.

Failure mechanism: The untrusted job gains write access, credential access, or path control over a resource that the deployment step trusts, then alters what the release step consumes or signs.

Impact: Attackers can ship tampered builds, steal publish credentials, leak secrets, or create a persistent supply-chain foothold that survives normal code review.

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 addresses the attack and risk surface, while SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	Build provenance and artifact integrity are central when test jobs must not influence deployment outputs.
Recommendation — Adopt provenance checks so deployment only trusts artifacts from verified build steps.
NIST SP 800-53 Rev 5	IA-9 — Service Identification and Authentication	Shared CI/CD components and release services need distinct, controlled authentication paths.
	AC-6 — Least Privilege	The question is about preventing untrusted jobs from inheriting release authority.
	IA-5 — Authenticator Management	Pipeline secrets and signing credentials must be managed so test jobs cannot expose or reuse them.
Recommendation — Separate service authentication so untrusted jobs cannot reuse deployment identity. Restrict job permissions so test runners cannot reach deployment actions or secrets. Rotate and protect CI/CD credentials so untrusted jobs never obtain release auth material.
CIS Controls v8	CIS-5 — Account Management	CI/CD trust boundaries depend on tightly scoped and separated accounts for build versus release.
Recommendation — Use separate accounts for test and deploy steps to prevent privilege crossover.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	CI/CD runners and publishing identities can become overprivileged when test and deploy share trust.
Recommendation — Reduce pipeline identity privileges so untrusted jobs cannot perform release actions.

Practitioner Guidance

What to verify: Confirm that untrusted jobs cannot reach deployment secrets, signing material, or release artifact locations, even through caches, volumes, or container reuse. Also verify that the deploy step only accepts artifacts with a verifiable provenance or digest from a context the test job could not modify.

Decision rule: If a job can execute third-party or fork-originated code, treat it as hostile and keep it off the runner, identity, and artifact path used for release. If the same infrastructure must be reused, then the environment is not sufficiently separated for deployment authority.

Practitioner takeaway: A CI/CD pipeline is only as safe as its weakest trust boundary, so separate execution from release authority, not just test from deploy.