As we noted in our earlier analysis, attackers already know secrets are on your developers’ machines, the only question is whether security teams do. The supply chain attack calendar of 2026 has been relentless. Megalodon backdoored 5,500 GitHub repositories in six hours. TrapDoor spread across npm, PyPI, and Crates.io simultaneously, planting persistence inside AI coding assistant config files. Miasma compromised 32 official Red Hat packages by abusing GitHub’s trusted publishing.
Each campaign shared the same objective: reach developer machines and harvest the credentials sitting on them. Developer workstations have become a high-value target precisely because they concentrate credentials that no perimeter control covers, shell histories, `.env` files, local caches, cloud CLI configs, and now AI agent directories.
Today, GitGuardian is addressing that gap directly with Developer Endpoint Protection: the ability to find every credential on every developer machine, built into ggshield, the CLI already deployed across the GitGuardian customer base.
Scans the full endpoint, including AI tooling. The scanning engine processes 500,000 files in under three minutes and completes subsequent scans in seconds using intelligent caching. All scanning is local. Credentials never leave the machine in clear text. Beyond traditional file paths, it covers the locations AI coding agents now write to: prompt histories, tool output logs, agent config files, and inventories of which AI tools and MCP servers are running on each machine, surfacing unauthorized or potentially malicious MCPs before they can exfiltrate data.
Detects live attacks with honeytokens. Honeytokens placed on developer machines fire the moment an infostealer validates one of those credentials. Instead of discovering a breach weeks later in a log review, security teams get attribution-rich alerts in real time, before the credential is used.
Feeds into the broader platform. Endpoint findings surface directly in the GitGuardian dashboard alongside vault, repository, and cloud data, connecting endpoint exposure to the NHI governance and secrets security workflows teams already use. When an incident lands, teams can answer immediately: what was on this machine, what services does it reach, and what needs to be revoked first.
Developer Endpoint Protection is built for organizations that need more than a proof of concept. It supports MDM-based rollout via Intune and Jamf, structured output forwarding to SIEM, API-based data retrieval, configurable exclusions with CPU and memory limiting, and cross-platform coverage across Windows, Linux, and macOS. Because it extends ggshield rather than introducing a new tool, teams already using GitGuardian for pre-commit hooks and CI/CD scanning can deploy without adding another agent or workflow.
Supply chain attackers have already updated their model. Machine identities and developer machine credentials are a primary objective, not an afterthought. Megalodon, TrapDoor, Miasma, and the campaigns that preceded them, including Shai-Hulud and NX, all demonstrate the same calculus: compromising one developer machine or CI workflow is often enough to reach production credentials, repository access, and cloud environments in a single step.
AppSec programs that stop their visibility at repositories and CI pipelines are working with an incomplete map of where credentials actually live. Developer Endpoint Protection is how GitGuardian extends that map to the machines themselves.
Developer endpoints are the most under-monitored surface in secrets security. The organizations that know what credentials are on their fleet recover faster when the next campaign lands. The ones that don’t find out during the breach.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。