> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/dev-machine-guard/overview.md). # Overview Developer machines are an increasingly targeted part of the software supply chain. They store sensitive credentials such as GitHub tokens, package registry publishing credentials, SSH keys, and cloud access keys, and they routinely execute untrusted code through dependencies, IDE extensions, developer tools, and AI coding agents. Recent supply chain attacks have shown how malicious packages, extensions, and tools can execute on developer machines, harvest credentials, and enable attackers to pivot into source repositories, package registries, and release systems, often before any code reaches CI/CD pipelines. ### What is Dev Machine Guard? Dev Machine Guard is not a traditional MDM solution. It is a compiled Go binary based capability designed to integrate with your existing MDM or endpoint management tooling to provide visibility and control into the developer tooling ecosystem, including: * IDE extensions and publishers (VS Code, Cursor, Windsurf, Antigravity, Kiro, Zed, JetBrains IDEs, Android Studio, Eclipse-based IDEs, and Xcode) * Browser extensions in Google Chrome, Microsoft Edge, and Mozilla Firefox * Locally installed open-source dependencies across JavaScript (npm, pnpm, bun, yarn), Python (pip, poetry, pipenv, uv, conda, rye), Go, Rust, PHP, .NET, and Ruby, plus OS-level system packages installed through Homebrew, Linux distribution package managers (rpm, dpkg, pacman, apk, snap, flatpak), and Windows package sources (Programs and Features, Chocolatey, Scoop, winget) * Package-manager configuration across npm, pnpm, bun, yarn, pip, and the Go, Cargo, Composer, NuGet, and RubyGems/Bundler equivalents, showing the effective registry, cooldown policy, and authentication surface across every config scope * Language runtimes (node, python, php, java, go, ruby, deno, bun, and dotnet), including every install found through version managers, package managers, and runtimes bundled inside other apps, not just the one on the PATH * AI coding agents and agent-driven actions, including AI CLI tools (Claude Code, Codex, Gemini CLI, Kiro CLI, GitHub Copilot CLI, Cursor Agent, Aider, OpenCode, and more), AI desktop apps, general-purpose agents, local AI frameworks, and agent plugins, skills, and commands * External tools and MCP server integrations used during development * Credential locations on the machine, analyzed locally and reported without secret values * Suspicious files and indicators of compromise detected by StepSecurity-maintained rules, such as a `binding.gyp` that runs during `npm install`, or editor and AI-tool config files that auto-execute on project open Dev Machine Guard runs on macOS, Windows, and Linux developer endpoints, including scanning of running WSL distributions on Windows. ### Why you need StepSecurity Dev Machine Guard StepSecurity Dev Machine Guard is not a replacement for traditional MDMs like Kandji, Jamf, or Intune. Those tools are built for device posture, compliance, and fleet management, not for detecting or preventing supply chain attacks that originate from developer machines. Dev Machine Guard extends your existing MDM by addressing the developer-specific attack surface. It provides the visibility and controls needed to detect risky tooling, untrusted dependencies, and malicious integrations before they become a supply chain incident. ### Deployment Model Dev Machine Guard is designed to work on top of your existing endpoint infrastructure. Dev Machine Guard is not a traditional, always-on MDM agent like those used by Kandji, Jamf, or Intune. Instead, it is delivered as a lightweight loader script that you deploy using your existing MDM or EDR tooling. On a schedule you control, the loader downloads a small signed binary, verifies it against a StepSecurity signing key, runs it to collect telemetry, and exits. Nothing sits resident on the machine between scheduled runs. (For Windows fleets, Dev Machine Guard also ships as a signed Windows Installer. See the [Installation Script ](/developer-machines/installation.md)documentation for details.) The script runs periodically or on demand and collects the telemetry required to provide visibility into developer machine activity. Collected data is securely sent to the StepSecurity platform for analysis and policy evaluation. This approach allows organizations to extend supply chain visibility to developer machines without introducing a traditional fleet-management agent or replacing existing device management solutions. **You can also follow this interactive demo to see how it works:** {% embed url="" %} ### Security, transparency and privacy Deploying software on developer machines requires trust, and your developers may reasonably ask whether Dev Machine Guard is safe. This section describes how it is built so that your security team can verify each claim independently. **Open source, so you can verify it yourself** * The full source code is public at [github.com/step-security/dev-machine-guard](https://github.com/step-security/dev-machine-guard). * Your team can review exactly what the agent collects, run its own code analysis, and follow every change through public commits and pull requests. **Signed and notarized releases** * The macOS binary is signed with the StepSecurity Apple Developer ID, notarized by Apple, and uses the hardened runtime. Notarization is a release gate, so a release cannot ship without it. * Windows binaries and the Windows Installer (MSI) are code-signed. * Each release publishes a signed checksum. The loader verifies the downloaded binary against the StepSecurity-signed checksum before running it, and downloads a clean copy if validation fails. * The signing private key is held by StepSecurity. On macOS, you can verify the signature on a device yourself: ```bash codesign -dv --verbose=4 ~/.stepsecurity/bin/stepsecurity-dev-machine-guard ``` **Built and released from the public repository** * Binaries are built and released through GitHub Actions workflows in the public repository, and we follow security best practices in these release pipelines. * Because the code, the build workflows, and the release artifacts are all public, you can check that a release corresponds to the published source. **What Dev Machine Guard does and does not collect** * It is read-only. It reports an inventory of developer tooling: installed packages and versions, IDE extensions, AI agents and MCP servers, and package manager configuration. * It reads specific files only, such as package manifests, lockfiles, Python package metadata, and npm, pip, yarn, pnpm, and bun configuration files. It does not upload general file contents. * Credential values are never sent to StepSecurity. Credential analysis happens locally, and credential values found in configuration files are redacted or hashed before they are reported. * It is not a keystroke logger and does not capture screens, personal documents, email, or browsing content. * On non-admin installs it runs as the logged-in user, so it cannot read other users' files or anything owned by root. Nothing stays resident between scheduled runs. * On Mac devices it honors TCC permissions for all of your scans/audits, so you stay in full control on what needs (or doesn't needs) to be scanned. ### Documentation The product documentation covers the Dev Machine Guard workspace pages and the deployment script. * [Devices](/developer-machines/devices.md): inventory of every developer machine reporting telemetry, with per-device asset breakdowns (IDE extensions, npm packages, AI agents, MCP servers, system packages) and scan history. * [IDE Extensions](/developer-machines/ide-and-ai-agents/ide-extensions.md): organization-wide view of every IDE extension and JetBrains plugin in use across your fleet, with per-extension security scores and detection of compromised and typosquatted extensions. * I[DE & AI Agents:](/developer-machines/ide-and-ai-agents.md) centralized view of AI coding tools detected across developer machines, grouped by category (CLI tools, IDE and desktop apps, general-purpose agents, frameworks and runtimes). * [MCP Servers:](/developer-machines/ide-and-ai-agents/mcp-servers.md) inventory of Model Context Protocol servers configured across developer machines, including which AI tools have each server registered. * [Agent Skills:](/developer-machines/ide-and-ai-agents/agent-skills.md) inventory of AI agent skills installed across developer machines, showing which agents can load each skill, where it came from, and whether it ships executable code, hooks, or inline shell commands. * [Suspicious Files:](/developer-machines/suspicious-files.md) files flagged by StepSecurity-maintained malicious-file detection rules across enrolled machines (for example, a `binding.gyp` that runs during `npm install`, or editor and AI-tool config files that auto-execute on project open), with confidence levels and attack-campaign attribution. The rules are authored and updated centrally, so detection works out of the box with nothing to configure. * [OSS Packages:](/developer-machines/packages/oss-packages.md) search the npm and PyPI packages installed on developer machines, with exact on-disk locations to support incident response and remediation. * [System Packages:](/developer-machines/packages/system-packages.md) visibility into OS-level packages installed via Homebrew on macOS and distribution package managers on Linux (apt, dnf, pacman), including filters for unsigned and third-party Linux packages. * [Package Configs:](/developer-machines/packages/package-configs.md) per-device audit of package-manager configuration files (`.npmrc`, `bunfig.toml`, `.yarnrc` / `.yarnrc.yml`, `pip.conf`) across every scope, showing the effective registry each machine resolves from, whether a cooldown policy is in effect, and the authentication surface. * [Device Policy: ](/developer-machines/device-policy.md)define reusable policies for IDE extensions and package-manager configuration, bundle them into profiles, and deliver those profiles through your MDM or through the Dev Machine Guard agent. * [Installation](/developer-machines/installation.md): deployment instructions for the loader script and the signed Windows Installer across macOS, Windows, and Linux, including how the signed-manifest auto-update flow works, plus per-MDM rollout guides. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stepsecurity.io/dev-machine-guard/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.