Supply chain attackers are not only trying to slip malicious code into trusted software. They are trying to steal the access that makes trusted software possible. Recently, three separate campaigns hit npm, PyPI, and Docker Hub in a 48-hour window, and all three targeted secrets from developer environments and CI/CD pipelines, including API keys, cloud credentials, SSH keys, and tokens. This is an ongoing concern and is self-propagating, as seen in attacks like the “mini Shai Hulud” campaigns.
That pattern should change how security teams think about the software supply chain.
Traditionally, security focused on shared systems like source code repositories, CI/CD platforms, artifact registries, package managers, and cloud environments. The goal was to protect production workloads and data. We absolutely still need to focus on these areas, but it is an incomplete picture.
Modern software delivery begins before code reaches Git. It begins on the developer workstation, where code is written, dependencies are installed, credentials are tested, AI assistants are prompted, containers are built, and trusted actions begin.
Developer workstations are a real part of the software supply chain. Treating them as ‘just’ ordinary endpoints leaves gaps among endpoint security, identity security, application security, and supply chain governance.
Supply Chain Attacks Have Become Credential-Harvesting Operations
Recent incidents keep pointing to the same operational truth. Attackers may use poisoned packages, compromised images, dependency bots, malicious workflows, or vulnerable developer tools, but the recurring objective is access.
Events like the TeamPCP and Shai-Hulud campaigns show how supply chain attacks increasingly converge around credential theft. In the TeamPCP campaign, attackers used compromised packages and developer tooling to harvest tokens, cloud credentials, SSH keys, npm configuration files, and environment variables.
Shai-Hulud pushed the same pattern even further, turning infected developer environments into credential collection points that exposed thousands of secrets across GitHub, cloud services, package registries, and internal systems.
That is not just software tampering. It is credential collection at the points where developers and automation already hold trust.
The supply chain is exposed when attackers gain access to credentials and context that allow them to alter, publish, build, deploy, or impersonate trusted software systems. Packages altered and published in a modern supply chain attack remain live for hours, while automation tools merge malicious updates in minutes.
The common thread across many of the recent attacks has been secrets, either as an initial access vector or as the target of collection.
The Attacker Path Now Runs Through Developer-Side Context
The developer workstation is valuable because it concentrates context. It often contains local repositories, .env files, shell history, SSH keys, package manager credentials and configs, build scripts, debugging logs, and browser sessions. Those pieces become far more dangerous when viewed together.
A single access token may look limited in isolation. A token found next to a Git remote, deployment script, README, cloud profile, and CI configuration tells an attacker where the token fits and what it might unlock. In the Shai-Hulud 2.0 campaign, for example, GitHub credentials dominated the exposed and exfiltrated credentials, each with potential admin access to repositories and CI workflows.
Local compromise is not only a device problem. It can serve as a map for source control, cloud accounts, package publishing workflows, CI/CD systems, internal APIs, and production-adjacent infrastructure.
Developer Machines Concentrate Software Delivery Authority
A standard employee laptop may expose corporate data. A developer workstation may expose the ability to change software. That distinction is critical when considering endpoint security.
Developers often need broad access to do their jobs. They clone private repositories, authenticate to cloud services, publish packages, access staging environments, and interact with multiple internal tools. Their machines become a working intersection of source code, credentials, automation, and delivery authority.
While not every developer has production access, many do have enough access to influence the systems that eventually produce production outcomes. A registry token can affect packages. A GitHub token can affect repositories or workflows. A cloud profile can expose infrastructure. A CI/CD credential can affect build behavior.
The board and auditors do not care if a developer stored a secret locally. The business risk is really that a local exposure gives attackers a path into systems that build, modify, release, or operate software.
That shift changes the questions security teams should ask:
- Can you identify which credentials are usable from developer workstations?
- Can you limit the value and lifetime of those credentials?
- Can you detect sensitive material before it enters Git history, CI logs, tickets, artifacts, or chat?
- Can you revoke and rotate access quickly when you suspect workstation compromise?
- Can you tell the difference between low-impact local exposure and credentials with admin-like privilege?
Those questions sit between AppSec, endpoint, identity, platform, and cloud security. However your organization chooses to coordinate, you must understand how developer behavior connects to delivery systems.
Automation And AI Make The Exposure Surface Thinner And Faster
Automation has compressed the time between compromise and impact. Dependency update bots can open and merge changes quickly. CI/CD systems can execute trusted workflows automatically. Package managers can run installation scripts. AI agents and coding assistants can read files, call tools, generate commands, inspect output, and move context across systems.
Automation is not inherently unsafe, but typically, any automation inherits trust, especially if it comes in an agentic form. If a malicious dependency update appears routine, an automated workflow may move it forward faster than a human reviewer can understand what happened.
AI In The Loop
AI-assisted development adds another set of handoff points. Sensitive data can appear in prompts, terminal output, tool calls, generated code, agent memory, logs, and local configuration copied into a debugging session. The issue is broader than whether a model provider stores prompts. The larger issue is that local development context now flows through more semi-automated systems.
Security teams should evaluate AI coding risk through the same lens they use for supply chain risk. Teams need to answer: what sources and data can the tool read? What can it execute? Where does output go? What credentials are nearby? And, maybe most importantly, what trust does the workflow inherit?
Downstream Controls Still Matter, But They Are Too Late By Themselves
Repository scanning, branch protection, CI/CD policy, artifact signing, dependency analysis, and runtime controls remain essential. They create shared enforcement points and help teams govern software at scale.
The problem is now timing, thanks to the speed of modern attacks. Attackers now leverage AI-powered tools to exploit any and all secrets within seconds of discovery.
Guardrails reduce potential exposure and the blast radius. Catching sensitive material while a developer is editing a file, preparing a commit, running a local command, installing a dependency, or interacting with an AI assistant keeps the impact to a minimum.
Mature programs distinguish between actions that should be blocked, actions that should give warnings, and actions that should merely generate telemetry for deeper investigation. The goal is not to bury developers in friction.
Treat The Workstation As A Local Supply Chain Boundary
The modern software supply chain does not start when code is pushed. It starts where code, credentials, automation, and trust first come together.
It is time to treat the developer workstation as a local supply chain boundary. That boundary includes the IDE, terminal, Git client, package manager, container tooling, cloud CLI, local build system, secrets handling practices, AI assistants, and automation agents. It is the place where individual developer action becomes organizational software delivery risk.
