# Installation Script

The Installation Script page is where you configure deployment and execution of the Dev Machine Guard data collection script.

<figure><img src="/files/l3pnDxeckK2MymWBOmNX" alt=""><figcaption></figcaption></figure>

The page provides a ready-to-deploy script for **macOS, Windows** and **Linux**. Use the platform tabs at the top of the page to switch between them.

### How Dev Machine Guard is deployed

Dev Machine Guard is delivered using a two-piece architecture:

* **The loader script** is a lightweight shell (macOS) or PowerShell (Windows) script that you deploy through your existing MDM or EDR tooling. It downloads the Dev Machine Guard binary, writes the embedded configuration to disk, and delegates execution to the binary.
* **The Dev Machine Guard binary** (`stepsecurity-dev-machine-guard`) is published on GitHub Releases at [`github.com/step-security/dev-machine-guard`](https://github.com/step-security/dev-machine-guard/releases). On each scheduled run, the loader:

  * Fetches a signed version manifest from the StepSecurity API.
  * Verifies the manifest signature against the StepSecurity releases public key, which is **embedded in the loader at the time it is generated**.
  * Downloads the binary identified by the manifest from GitHub Releases.
  * Verifies the binary's SHA-256 against the value in the signed manifest.
  * Executes the binary only if both verifications pass.

  The signature is an Ed25519 SSH signature, verified using `ssh-keygen -Y verify`. The signing key (`releases@stepsecurity.io`) is held by StepSecurity and is the trust root for every released build.

This separation has two practical benefits:

1. You only need to deploy the loader script once via MDM. Binary updates are delivered automatically the next time the loader runs, without requiring an MDM redeploy.
2. Every binary the loader runs is cryptographically tied back to a single trust root: the StepSecurity releases signing key. Because that key is embedded in the loader rather than a per-build checksum, devices stay safe across version changes without re-deploying the loader. Substituting a malicious binary would require compromising both the StepSecurity API and the offline signing key, not just one or the other.

#### **Signed installer (Windows)**

For Windows fleets, Dev Machine Guard also ships as a **signed Windows Installer (`.msi`)**, published on [GitHub Releases](https://github.com/step-security/dev-machine-guard/releases) for both x64 and ARM64 architectures. The MSI integrates natively with Windows application-management tooling (SCCM, Intune Win32 apps, GPO software installation), exposes a standard `ProductCode` for detection and supersedence, and never spawns PowerShell during install, upgrade, or uninstall.

The MSI is the recommended path for production Windows fleets, especially in environments where EDR blocks PowerShell from making outbound network calls. See MDM Deployment → Windows for details.

### Deploying the script

You can copy the script directly from the page or use the **Download** button in the top right.

Deploy the script to your developer machines using your existing MDM or EDR tooling. Because the loader handles binary download, version checking, and execution, no further configuration is required on the device.

### Fleet deployment via MDM

For step-by-step guides on deploying Dev Machine Guard at scale through your endpoint management platform, see **MDM Deployment**. The section covers:

* **Windows** — [Microsoft Configuration Manager (SCCM/MEMCM)](/developer-machines/installation-script/mdm-deployment/windows/microsoft-configuration-manager-sccm.md), [Microsoft Intune](/developer-machines/installation-script/mdm-deployment/windows/microsoft-intune.md)
* **macOS** — [Iru](/developer-machines/installation-script/mdm-deployment/macos/iru-formerly-kandji.md)

### Auto-updating

<figure><img src="/files/AcRVmJshukxPWyfJQ345" alt=""><figcaption></figcaption></figure>

**Dev Machine Guard supports automatic updates.** When you set the **Version** dropdown to **Latest**, devices will pick up the most recent published release on their next scheduled run, with no further action required from you.

**To enable auto-update:**

1. Open the **Installation Script** page.
2. Set the **Version** dropdown to **Latest**.
3. Confirm the change.

That is all. Devices that already have the loader deployed will pick up the change on their next scheduled run, and every subsequent release will be delivered the same way. You do not need to redeploy the loader through MDM and you do not need to take any action when a new version ships.

**How often updates arrive.** Devices check for new releases once per scheduled run. The cadence is controlled by the **Scan Frequency** setting on the same page.

**Is auto-update safe?** Yes. Every binary the loader downloads is cryptographically verified before it runs. The loader carries an embedded StepSecurity releases public key, and a release is only executed if its signed manifest verifies against that key and its SHA-256 matches. See How Dev Machine Guard is deployed for the full verification flow.

{% hint style="info" %}
**Rolling back.** You can leave **Latest** at any time. If a release causes an issue, switch the **Version** dropdown to a known-good pinned version and devices will roll back on their next scheduled run.
{% endhint %}

### Pinning a specific version

If your environment requires change-controlled rollouts, or you want to validate a release in a staging fleet before promoting it, you can pin devices to a specific version instead of using **Latest**.

**To pin a version:**

1. Open the **Installation Script** page.
2. Select the desired version (for example, `v1.11.0`) from the **Version** dropdown.
3. Confirm the change.

Devices that already have the loader deployed will move to the selected version on their next scheduled run. To roll out a later release, repeat the same steps with the new version selected. As with auto-update, you do not need to redeploy the loader through MDM.

### What the script does not collect

The Dev Machine Guard binary is designed to collect only the metadata required for supply chain visibility. It does not collect:

* Source code
* Secrets or credentials
* Personal data outside the developer's installed tooling inventory

For details on what data Dev Machine Guard does collect, see the Devices page.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stepsecurity.io/developer-machines/installation-script.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
