Secrets Proliferate on Developer Machines, Posing New Supply Chain Risks
A GitGuardian analysis reveals an average of 150 secrets, including private keys and cloud credentials, on developer endpoints, highlighting a significant blind spot in traditional security controls.
A recent analysis by GitGuardian has uncovered a concerning trend: developer endpoints are accumulating an average of 150 secrets, a figure that significantly expands the perceived attack surface for software supply chain security. These secrets, which include private keys (accounting for 38% of unique secrets found) and cloud/identity provider credentials (22%), represent sensitive information that often resides outside the typical security perimeters monitored by organizations.
While these numbers are not presented as a universal benchmark, they serve as a critical indicator of how much credential material can accumulate on developer machines, far from the traditional boundaries of the software supply chain. The findings are particularly striking because numerous secrets were discovered within the history files of coding agents and other modern development tooling. These operational residues, including prompts, tool calls, debug output, and AI assistant contexts, are not typically the first places security teams inspect, yet they are becoming repositories for sensitive information.
The implications of this discovery are profound. It underscores a fundamental shift in how developers work and how attackers can exploit this evolution. The industry has long focused on preventing secrets from entering source code, a crucial but incomplete strategy. Modern development workflows, involving AI-assisted tools, local CLIs, IDE plugins, and various configurations, can inadvertently preserve sensitive context in these less-scrutinized areas.
The recent surge in supply chain attacks, such as those targeting packages, extensions, and CI pipelines, should be viewed through this lens. These incidents, including campaigns like Shai-Hulud, Megalodon, and Miasma, can be interpreted less as isolated failures of package integrity and more as sophisticated credential-harvesting operations. Developer machines have become a high-return target because they offer a more direct path to valuable credentials than production environments.
This pattern is evident in recent compromises affecting Trivy, Checkmarx AST, GitHub, and others. Whether through compromised packages, developer tools, or CI workflows, the common thread is trusted code executing in environments where credentials are accessible. When such an attack succeeds on a developer workstation or CI runner, it inherits the trust of that environment, potentially leading to repository access, package publishing privileges, or broader cloud compromises before any malicious code even reaches production.
The critical blind spot for many Application Security (AppSec) programs lies in their limited visibility into developer laptops compared to repositories and CI systems. While traditional models focused on source, build, artifact, and deployment, modern development blurs these lines. A developer workstation is now a convergence point for source control, package installation, cloud access, AI tooling, and local testing, all while leaving behind operational traces.
These traces are difficult for defenders to detect as they exist outside the standard code review, repository scanning, and CI policy pathways. Ownership becomes ambiguous, with AppSec, endpoint security, identity, and supply chain risk teams all having a stake but rarely a complete picture. This necessitates a reevaluation of the threat model: what can malicious code achieve if it runs where developers work?
Ultimately, while repository scanning, dependency review, and CI hardening remain foundational, AppSec strategies must expand to encompass developer endpoints. These machines are no longer just endpoints but privileged nodes in the software supply chain. As supply chain attackers increasingly target these environments for credential harvesting, AppSec programs must adapt their mental models and security controls to address this evolving and critical attack surface.