Should teams manage developer workstation risk separately from CI/CD security?

Why workstation risk and CI/CD security belong in one delivery-chain model

Developer endpoints and pipelines are not separate trust islands. A workstation often becomes the easiest way to reach source control, signing material, cloud consoles, or build tooling, and once an attacker lands there, the blast radius can include the same secrets and release paths that CI/CD security is meant to protect. That is why local device risk and pipeline risk need one ownership model, not two disconnected checklists.

The practical question is not whether the compromise starts on a laptop or in a runner. It is whether an attacker can move from a trusted development environment into release authority, credential material, or production-adjacent systems without a clean control boundary stopping them. Cases like Bybit hack 2025 and CircleCI breach 2023 show that endpoint compromise can become pipeline compromise very quickly.

That also means the control set has to be coherent across the path from code creation to code release. If endpoint hardening, build provenance, secret handling, and identity governance are owned separately, teams tend to leave gaps at the handoff points, especially around token reuse, browser sessions, local caches, and developer-installed tooling. Supply-chain controls such as SLSA help with build integrity, but they work best when the workstation side of the chain is treated as part of the same assurance boundary.

Where the shared risk actually comes from

Developer workstations are high-value because they often hold active sessions, cached credentials, signing keys, package manager tokens, and access to internal and third-party systems. CI/CD systems are high-value because they can mint, transform, or publish artifacts at scale. When those two are connected, an attacker only needs one weak point to bridge into the other, especially through stolen tokens, malicious developer tooling, or poisoned dependencies.

That is why local installation risk matters in supply chain security. A compromised editor extension, package, browser profile, or sync tool can feed directly into source control or pipeline access. The attack path may never touch the central CI system at first; it can start on the endpoint and then abuse the identity and secrets already present there. Resources such as Shai Hulud npm malware campaign and reviewdog Action compromise 2025 illustrate how developer-facing tooling and pipeline trust can be chained together.

Because the same delivery chain is involved, the useful control question is where trust is being assumed rather than verified. Endpoint management, repository protection, short-lived credentials, artifact signing, and pipeline policy need to be consistent enough that compromise of one layer does not silently grant control over the next. If teams cannot explain that boundary clearly, they do not really have separate risks, they have one distributed risk surface.

How teams should govern the combined exposure

The governing model should align endpoint, AppSec, platform, and identity ownership around shared release risk. That means treating developer devices as part of the software supply chain, not as general-purpose IT assets that happen to be used for coding. It also means defining which controls belong on the workstation, which belong in the pipeline, and which must be enforced in both places to prevent trust leakage.

A workable division is to use the workstation to reduce the chance of initial credential theft or malicious local execution, and use CI/CD to reduce the chance that compromised inputs become trusted outputs. But the two must share policy on secrets, code signing, privileged access, and approved tooling. The strongest patterns usually combine endpoint hygiene with pipeline identity controls, because pipeline hardening alone cannot compensate for a compromised developer session that can still authenticate to critical systems.

Practitioners get better results when they govern the chain by release authority, not by tool category. If a control protects a developer browser session, a cloud token, a signing key, or a repository write path, it belongs in the same risk discussion even if it sits on the endpoint side. If it affects provenance or release integrity, it also belongs in the pipeline side of the model.

Risk and Threat Considerations

The main risk is lateral movement from the workstation into build and release authority. An attacker who steals a browser session, API token, SSH key, or local secret can often reach the same systems the CI/CD platform uses, which turns an endpoint compromise into a supply chain event. The more developer tooling is allowed to cache credentials or trust local state, the more attractive the workstation becomes as an entry point.

Failure mechanism: A compromised endpoint, malicious package, or stolen session token is reused against source control, artifact stores, or cloud services, allowing the attacker to alter code, exfiltrate secrets, or sign and publish tainted builds.

Impact: The blast radius can extend beyond one laptop or one pipeline run to released software, third-party consumers, cloud access, and production systems that trust pipeline output.

Practitioner Guidance

What to prioritise: Start with the shared trust objects, not the tooling labels. Inventory the credentials, sessions, signing keys, and privileged repo paths that are reachable from developer endpoints and from CI/CD, then decide which ones need short-lived access, stronger proof of identity, or removal from local storage.

What to verify: Confirm that a developer workstation compromise cannot directly mint durable release authority. If a local machine can still access long-lived tokens, reusable cloud sessions, or signing material, then the workstation and pipeline controls are not actually aligned.

Common mistake: Teams often harden the CI platform while leaving developer endpoints with broad browser sessions, permissive token scopes, or unmanaged installation paths. That creates a false sense of separation because the attack path simply shifts left to the endpoint.

Practitioner takeaway: Treat workstation security and CI/CD security as one control plane for software delivery, because the most serious failures usually happen at the handoff where trusted local access becomes trusted release authority.

Related resources from NHI Mgmt Group

• How should security teams manage third-party software risk in CI/CD pipelines instead of relying only on vendor questionnaires?
• How should security teams govern software supply chain risk when CI/CD identities can publish code?
• How should security teams reduce malicious package risk in CI/CD pipelines?
• How do security teams know whether CI/CD risk gates are actually working?