Open source macOS CLI tools like fort are letting individual developers and small teams generate compliance evidence on their own laptops, rather than standing up Jamf or Kandji first.
A SOC 2 audit is supposed to start with a stack: Jamf, Kandji, or some other mobile device management platform that pushes settings to every Mac, logs the results, and shows auditors a continuous record. For a solo founder or a four-person consultancy, that stack is often more work than the audit itself.
A growing cohort of individual developers and small teams is opting out of that path. Instead of deploying MDM, they are running open-source CLI tools directly on the laptops they want audited, generating point-in-time evidence for SOC 2 and ISO 27001 endpoint controls, and handing the output to their auditors as a snapshot. The category is small but structurally telling: compliance overhead is pushing the bottom of the market out of MDM and into self-service tooling.
fort, a new open-source Mac security CLI from developer djadmin, is a clean example of the approach. The tool, which launched on Product Hunt this week, runs more than 15 macOS security checks, groups them into five buckets (core security, system hardening, access controls, exposure reduction, and patching), and produces a posture score at the end. A --fix flag can remediate problems with the user's approval, and a --report flag writes a self-contained HTML file with the machine ID, OS version, timestamp, and per-check evidence suitable for an auditor's records.
What makes the design choice matter is what it omits. The tool is a single Go binary, distributed via [Homebrew, direct download, or go install](https://github.com/djadmin/fort). There is no agent to install, no account to create, no background process, no telemetry, and no network call home. For developers who have already declined to put MDM on their personal machines, that posture is the feature, not a limitation.
Each check in fort is mapped by the project to one or more controls in SOC 2, ISO 27001, NIST CSF, and CIS v8. FileVault, for example, is mapped in the project's README to SOC 2 CC6.1 and CC6.7 and to ISO 27001 A.8.3. The framing throughout is preparation and evidence collection, not a substitute for the audit itself. Exit codes (0 for pass, 1 for fail, 2 for warn) make the tool scriptable, and a --json flag lets teams pipe results into their own compliance dashboards.
That design has obvious appeal for a specific audience. A contractor billing $200 an hour does not want to spend a week evaluating MDM vendors, paying per-seat fees, and explaining to a client why their laptop is being remotely managed. A pre-revenue startup running lean on its first SOC 2 Type 1 may not have anyone to operate a management console at all. For these teams, a CLI that runs in 30 seconds, prints what it found, and produces an HTML file an auditor can read is a reasonable answer to a real pain point.
It is also an honest, limited answer. A CLI snapshot captures configuration at a moment in time. It does not enforce policy, drift-detect, or alert when something changes tomorrow. It does not replace EDR, identity controls, or organizational policy. And the framework mappings in fort's README are the project's own work; auditors will still need to assess whether the controls in the tool actually satisfy the controls in the standard for a given environment. As of v0.3.0, the project documents more than 15 checks, and that count reflects the maintainer's own accounting rather than an external benchmark.
The structural question is whether this bottom-up category keeps growing. The MDM market is not going away, and enterprises with hundreds of Macs still need centralized management. But the long tail of solo developers, contractors, and small agencies is large enough that compliance tooling is visibly bifurcating into an enterprise track and an indie track. Tools like fort, and the maintainers willing to publish their check logic in the open, are part of why an individual developer can credibly face an auditor without first buying into a platform.
What to watch next: whether independent auditors will accept point-in-time CLI output as evidence, and whether the open-source category attracts enough maintainers that the "one binary, one person" risk gets distributed across a real community.