System Packages

The System Packages page provides visibility into all OS-level packages installed on developer machines across your organization.

This view consolidates packages detected by the Dev Machine Guard agent on macOS and Linux devices, giving security teams a unified inventory of OS-level developer tooling. This is the category of software that often sits outside traditional MDM inventories and SCA tools, and that has been the target of recent supply-chain incidents.

Supported package managers

System Packages currently covers:

• macOS: Homebrew (formulae)

• Linux: Distribution package managers (for example, dnf, apt, pacman)

• Windows: Coming soon

The page is organized into per-platform tabs. Each tab header shows the total number of unique packages detected on that platform across your fleet (for example, macOS 235, Linux 1,472).

The main System Packages list shows every unique package detected on the selected platform:

• Package: the package or formula name (for example, openssl@3, sqlite, terraform). Click the name to open the package detail view.

• Type: the package type. On macOS this is typically formula for standard Homebrew packages. On Linux this reflects the package manager (for example, rpm, deb).

• Devices: the number of devices where the package is present. Click the count to see the list of devices.

• Versions: the number of distinct versions of the package installed across your fleet. A high version count often indicates version drift worth investigating.

A summary at the top shows the total number of unique packages detected on the selected platform across all active devices.

You can:

• Switch between macOS, Linux, and Windows tabs

• Search the list by package name

• Filter by device using the All devices dropdown

• Filter by package type using the All types dropdown

• Sort by Devices or Versions to surface the most widely deployed or most fragmented packages

Linux-only filters

When the Linux tab is selected, three additional filters appear:

• All vendors: filter packages by vendor (for example, Cursor, Microsoft Corporation)

• Unsigned: show only packages that have no cryptographic signature. Unsigned packages cannot be verified against a publisher and are worth reviewing during incident response.

• Third-party: show only packages that are not distributed officially by the device's Linux distribution. Third-party packages typically come from vendor-provided repositories or sideloaded installers and represent a higher-risk surface than packages that ship with the distribution.

These filters can be combined with the search box and the All types filter to quickly narrow the list to, for example, all unsigned third-party rpm packages from a specific vendor.

Package details

Clicking a package name opens a side panel with detailed information about that package.

The panel is organized into the following sections.

Summary cards

• Devices: the total number of devices in your fleet where the package is installed

• Versions: the number of distinct versions detected across those devices

Package Information

• Name: the package or formula name

• Type: the package manager origin (for example, brew)

• Last Updated: the most recent date upstream package metadata was refreshed for this package

• Versions: the number of distinct versions detected

Package Metadata

• Description: the upstream package description

• Tap (Homebrew only): the originating Homebrew tap (for example, homebrew/core)

• License: the package license (for example, blessing, MIT, Apache-2.0)

• Homepage: a link to the upstream project homepage

• Install Reason: how the package came to be installed on the device. Common values include dependency (installed automatically to satisfy another package's requirements) and direct/manual installs.

For Linux packages, this block also surfaces signature status. If the package has no cryptographic signature, an Unsigned Package warning is shown:

Unsigned Package This package has no cryptographic signature.

Unsigned packages cannot be verified against a publisher's signing key. Combined with the Third-party indicator, this is a strong signal that the package warrants closer review.

Version distribution

A row of version chips below Package Metadata shows each distinct version detected in your fleet and the number of devices running it (for example, 3.50.4 1 device, 3.51.1 1 device, 3.53.0 1 device).

This makes version drift immediately visible. A widely-installed package such as openssl@3 may span four or more distinct versions across a fleet of a dozen devices, showing you at a glance where updates have lagged.

Devices

A list of all devices where the package is installed. Each entry shows:

• Device hostname

• Device ID

This helps you understand the spread of a specific package across your organization and identify where remediation may be required during an active supply-chain incident.

Why it matters

Package managers such as Homebrew (macOS) and dnf/apt (Linux) are the de facto distribution channels for developer tooling on engineer workstations and build hosts. A typical developer machine has hundreds of system-installed utilities, compilers, databases, and network tools, many installed automatically as dependencies of higher-level packages. This software routinely runs with developer-level access to source code, credentials, and CI/CD tokens.

Visibility into what your developers have installed, and at what versions, is the foundation for responding quickly when a supply-chain incident is disclosed.

Use this page to:

• Respond to incidents: when a compromised system package is disclosed, search for it here to identify affected devices and users in seconds

• Audit developer tooling: surface unexpected or policy-violating software across the fleet

• Assess version drift: packages with high version counts across your fleet may indicate forgotten auto-installed dependencies or inconsistent update practices

• Track footprint: understand the total OS-level package surface area across your developer population

Remediation

Using the device and version information from the System Packages detail view, you can create an MDM script to remove affected packages from developer machines during an incident. After the package is removed, rescan the device and verify the package is no longer present in Dev Machine Guard.