Script

The Script page generates a ready-to-deploy installation package for Dev Machine Guard. It walks you through a four-step wizard: pick an operating system, choose a deployment pattern, set your configuration, then review and generate the output.

The page supports macOS, Windows, and Linux. The deployment patterns, scheduler mechanisms, configuration fields, and generated output all adapt to the operating system you select in Step 1.

For the underlying delivery model (loader script versus signed installer) and the binary verification flow, see the Installation overview.

Generating an installation package

The wizard has four steps. Use Continue to advance and Previous to go back. Your selections carry through to the output generated at the end.

Step 1: Operating system

Select the target platform: macOS, Windows, or Linux. Your choice determines the loader type, the available deployment patterns, the scheduler used, the configuration fields shown, and the format of the generated output.

Step 2: Deployment pattern

Choose how you want to run the agent. The available options depend on the operating system selected in Step 1.

On macOS and Windows, patterns are grouped by intent under Get started (try it on a single machine) and Scale deployment via MDM (roll out to many machines). Linux offers its two patterns directly, without the MDM grouping.

macOS

• Get started: One-time execution (recommended) runs the script once for an on-demand scan; Scheduled via launchd installs a LaunchAgent so it runs on a schedule on this machine.
• Scale via MDM: MDM-scheduled (recommended) has your MDM run the script on a recurring schedule; Scheduled via launchd pushes once via MDM and the agent self-schedules via launchd.

Windows

• Get started: One-time execution (recommended) runs the script once for an on-demand scan; Scheduled via Task Scheduler registers a Scheduled Task so it runs on a schedule on this machine.
• Scale via MDM: Win32 app (recommended) produces a .intunewin package for Microsoft Intune; MSI installer provides the signed .msi for SCCM / Configuration Manager.

Linux

• One-time execution runs the script once per invocation.
• Repeated execution registers a systemd user timer to run on a schedule on this machine.

For step-by-step fleet rollout guides, see MDM Deployment.

Step 3: Configuration

The configuration fields depend on the operating system and deployment pattern selected.

Scan frequency (self-scheduling patterns only)

Sets how often the agent scans the device after install, in hours (default 4). It appears whenever the agent runs on its own recurring schedule: Windows Task Scheduler, the Linux systemd user timer (Repeated execution), and the macOS scheduled and MDM-scheduled patterns. On Windows MSI deployments it maps to the SCANFREQUENCY property. It does not appear for one-time execution, where there is no recurring schedule.

Agent version

• Latest (loader-based and Win32-app patterns): the agent resolves the newest release on each run. The page shows the current latest version (for example, 1.12.0). This enables automatic updates. See Auto-updating.
• Pin specific version: lock the install to a known release.
• MSI version (Windows MSI installer pattern): the MSI is pinned at install time. Push a newer MSI to upgrade. Select the version from the dropdown. Unlike the loader-based patterns, MSI installs do not auto-update the binary in place; you upgrade by deploying a newer MSI through your MDM.

Inactive threshold

Sets the number of days after which a device with no telemetry is marked inactive in the device list. This applies to all devices and is saved to your organization settings when you generate. The same setting can be managed later on the Settings page.

Advanced configuration

Expand this section to control install location, scan scope, and package scanners. On Windows MSI deployments these values are delivered via the MSI bootstrap file.

• Install directory: where the agent binary and logs live. Leave blank for the default: ~/.stepsecurity on macOS and Linux, %ProgramData%\StepSecurity on Windows.
• Scan directories: one absolute path per line. Leave blank to scan the user's home directory.
• Include TCC-protected directories (macOS): scan Documents, Downloads, and similar locations. Requires Full Disk Access.
• Package scanners: choose which package ecosystems to scan (npm, Homebrew, Python).
• Scan timeout: maximum run time, in hours.
• Stale-process age: kill hung runs after this many hours.

Step 4: Review and generate

Review a summary of every selection. Hover a field to jump back and edit it, then select Generate script (or Regenerate script after a change).

The generated output depends on the deployment pattern:

• Script patterns (one-time execution, scheduled, repeated, MDM-scheduled) produce a loader script you copy or download, plus deployment instructions. The script is named for the platform and tenant, for example stepsecurity-loader-linux-<customer>.sh.

• Win32 app (Windows) produces the Install and Uninstall command lines to use when adding the .intunewin package as a Win32 app in Intune, along with a link to the Intune guide. Download the .intunewin from the GitHub release.

• MSI installer (Windows) produces the architecture-specific MSI download URLs (x64 and ARM64), a bootstrap.json to pre-stage tenant credentials and advanced scan configuration, and a link to the SCCM guide.

For the exact upload and configuration steps in each MDM tool, follow the linked guide rather than the summary values alone.

Deploying the output

For script patterns, copy the script from the page or use Download, then deploy it through your MDM or EDR tooling. Because the loader handles binary download, version checking, and execution, no further configuration is required on the device. For a quick proof of concept, run the script on your own machine to see results right away.

For Windows Win32-app and MSI patterns, follow the Windows MDM Deployment guides, which cover credential passing (inline MSI properties versus a pre-staged bootstrap file), architecture selection, upgrades, and uninstall.

Fleet deployment via MDM

For step-by-step guides on deploying at scale, see MDM Deployment:

• Windows — Microsoft Configuration Manager (SCCM/MEMCM), Microsoft Intune
• macOS — Iru

Auto-updating

Loader-based deployments support automatic updates. When you set Agent version to Latest in Step 3, devices 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 Script page.
2. In Step 3: Configuration, set Agent version to Latest.
3. Complete the wizard and generate.

Devices that already have the loader deployed pick up the change on their next scheduled run, and every subsequent release is delivered the same way. You do not need to redeploy the loader through MDM.

How often updates arrive. Devices check for a new release once per scheduled run. On self-scheduling patterns, the cadence is set by Scan frequency.

Windows MSI is different. The MSI installer pattern pins the binary at install time and does not auto-update in place. To upgrade an MSI fleet, deploy a newer MSI version through your MDM. See Windows MDM Deployment.

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 the Installation overview for the full verification flow.

Rolling back. On loader-based patterns you can leave Latest at any time: set Agent version to a known-good pinned version and devices roll back on their next scheduled run. On MSI, roll back by deploying the previous MSI version.

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, pin devices to a specific version instead of using Latest.

To pin a version:

1. Open the Script page.
2. In Step 3: Configuration, select Pin specific version (or, for Windows MSI, choose the desired MSI version) and pick the release (for example, 1.11.0).
3. Complete the wizard and generate.

Loader-based devices move to the selected version on their next scheduled run. For MSI, the selected version is the one packaged for deployment. To roll out a later release, repeat with the new version selected.