Attackers already know the secrets are on your developers’ machines. Do you?
In a recent GitGuardian analysis, an average of 150 secrets were found on a sample of developer endpoints. Private keys accounted for 38% of unique secrets, while cloud, identity provider, and secret management credentials (AWS IAM, Hashicorp vault) added another 22%.
Those figures should not be treated as a universal prevalence estimate for every developer machine, but they are directionally significant. They show how much credential material can accumulate outside the places security teams usually define as the software supply chain.
The more surprising finding is where some of those secrets appeared: numerous secrets were found in coding agent history files. These are not the classic places security teams think to inspect first. They are the operational residue of modern development work: prompts, tool calls, debug output, generated snippets, assistant context, and other traces left behind by local tooling.
Everybody knows secrets exist on developer machines. But the scope of the problem is probably underestimated, given AppSec can hardly see the places where modern developer tools now leave them behind.
The problem starts before code reaches production
Software supply chain security is often framed as a question of what enters the codebase: which packages are being pulled into the build, which dependencies are vulnerable, and which workflows can touch production credentials.
Those questions matter, but they can obscure a simpler fact: attackers do not need malicious code to reach production to win. A single compromised developer workstation can expose enough local access to seed the next compromise.
The industry has spent years teaching teams not to put secrets in source code. That lesson still matters, but it does not cover the way developers now work with coding agents, local CLIs, IDE plugins, MCP configurations, and AI-assisted tooling that can quietly preserve sensitive context.
The recent wave of supply chain attacks targeting packages, extensions, and CI pipelines, such as Shai-Hulud, Megalodon and Miasma, should be read less as isolated package integrity failures and more as credential-harvesting campaigns. The malicious component is often the delivery mechanism. Developer machines have become a high-ROI target because they sit closer to credentials than production does.
The recent wave has a common pattern
Very recently, Trivy, Checkmarx AST, GitHub, LiteLLM, Telnyx, RedHat and Axios were all compromised or pulled into cascading supply chain incidents.
Some attacks came through packages, others through developer tools or CI workflows, but their common trait was trusted code executing in places where credentials were reachable. Once there, an attack can succeed before a single vulnerable line of code is committed, reviewed, or deployed. If it runs on a developer workstation or CI runner, it inherits the trust of that environment.
Nx Console was a poster child. A malicious version of the popular VS Code extension attempted to collect local developer secrets across SSH keys, .env files, cloud credentials, package tokens, Vault tokens, and active 1Password CLI session material. Even a security mature company like GitHub fell.
Because they collapse the distance between initial execution and meaningful access, developer credentials have become a natural objective for supply chain attackers. One compromised workflow can become repository access, package publishing access, cloud access, or another round of downstream compromise.
The blind spot is where developers actually work
Most AppSec programs have a clearer view of repositories and CI than they do of developer laptops. That made sense when the software supply chain was modeled as source, build, artifact, and deployment, but modern development has blurred those boundaries.
A developer workstation is not just an endpoint. It is where source control, package installation, cloud access, AI tooling, and local testing converge. It also stores the local traces those tools leave behind.
For defenders, these files are hard to see because they live outside the normal code review, repository scanning, and CI policy path, at an intersection where ownership gets blurry. AppSec, endpoint security, identity, and supply chain risk all touch the developer machine, but no team always has the full picture of what developers install, what tools execute locally, and what secrets those tools can reach.
So for AppSec teams, one question can no longer sit outside the threat model: what could malicious code reach if it runs where our developers work?
Developer endpoints are part of secrets security
None of this makes repository scanning, dependency review, CI hardening, or push protection less important. Those controls are still part of the foundation.
If attackers use trusted developer tooling as a path to credential harvesting, AppSec cannot stop its mental model at repositories and CI. Developer endpoints are part of secrets security because they are where software work and credential exposure now meet.
A developer laptop is not another endpoint managed by IT, but a privileged software supply chain node. When secrets collect there, they become part of the attack surface AppSec is responsible for reducing.
Supply chain attackers have already made that adjustment. AppSec programs need to make it too.