You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SOC-2 compliance solution for the discerningly paranoid security engineer.
3
+
A security-first MDM that proves compliance without compromising your infrastructure.
4
4
5
5
![logo](./media/logo_small.png"gitMDM logo")
6
6
7
-
## What Happens When a Security Engineer Builds an MDM
7
+
## A Different Approach to Device Management
8
8
9
-
gitMDM is what you get when you ask a security engineer to make an MDM tool. Traditional MDMs operate on the assumption that the central server is trustworthy and should have root access to execute arbitrary code on all endpoints. We think that's insane.
9
+
Traditional MDMs were designed for corporate IT control. They require root access, execute remote commands, and create a massive attack surface. One compromised MDM server can mean game over for your entire fleet.
10
10
11
-
**Core Security Principle**: A compromise of the MDM server should NOT result in a compromise of all agents reporting to it.
12
-
13
-
This is why gitMDM:
14
-
-**Cannot execute remote commands** - The server literally lacks the code to push commands to agents
15
-
-**Uses cryptographic signatures** - All agent configurations are signed with Sigstore, preventing a compromised server from injecting malicious checks
16
-
-**Runs without privileges** - Agents run as regular users, not root/SYSTEM
17
-
-**Reports only** - Information flows one way: from agents to server, never the reverse
18
-
19
-
## Your Problem
20
-
21
-
Your startup just hit the enterprise sales milestone where someone asks "are you SOC 2 compliant?" Meanwhile, your engineering team runs OpenBSD on ThinkPads, Arch on Frameworks, and that one person still dailying Plan 9.
22
-
23
-
Traditional MDMs run as root, execute arbitrary code from cloud servers, and auto-install binaries downloaded from the internet. Your security engineer just had an aneurysm.
24
-
25
-
## Our Solution
26
-
27
-
gitMDM proves compliance without the backdoor:
28
-
29
-
```
30
-
Traditional MDM: "Install our root agent that downloads and executes code from our servers!"
31
-
Your Team: "How about no."
32
-
33
-
gitMDM: "Run a read-only agent as a regular user that only reports"
34
-
Your Team: "...continue"
35
-
```
36
-
37
-
### Why Your Security Team Will Actually Approve This
38
-
39
-
-**Zero Remote Execution**: Can't push commands or install software. The server only receives data.
40
-
-**Cryptographically Signed Configs**: All agent configurations require Sigstore signatures. A compromised server can't inject malicious checks.
41
-
-**No Auto-Updates**: No downloading binaries from the internet. Updates require YOU to rebuild and redeploy.
42
-
-**Runs as User**: No root, no SYSTEM. Can't execute arbitrary code or modify your system.
43
-
-**You Own Everything**: Your server, your git repo, your data. No third-party cloud with root access to your fleet.
44
-
-**Audit Everything**: Every change is a git commit. `git blame` for compliance.
11
+
gitMDM takes a security-first approach. Built on the principle that even your MDM server shouldn't be trusted with root access to your machines.
45
12
46
13
## Demo
47
14
48
-
Visit our demo instance at https://gitmdm.codegroove.dev/ - OK, so it's actually our prod instance.
49
-
50
-
## Quick Start
51
-
52
-
Build static binaries:
53
-
54
-
```bash
55
-
make all
56
-
```
57
-
58
-
Run a server:
59
-
60
-
```bash
61
-
gitmdm-server -git /var/git
62
-
```
15
+
https://gitmdm.codegroove.dev/ - a real life instance of gitMDM.
63
16
64
-
If you are a fan of Google Cloud Run, check out `./hacks/deploy.sh` for a deployment script.
17
+
### Core Security Principles
65
18
66
-
On a client, the --install flag establishes persistence:
19
+
**Zero Trust Architecture**: The server cannot execute commands on agents - we didn't just disable it, we never built it. A compromised server gets you compliance reports, not a botnet.
**Defense in Depth**: Agents run as unprivileged users (not root). Checks are compiled into the binary. With Sigstore, configurations are cryptographically signed. Even without signatures, a compromised server can't inject malicious code.
71
22
72
-
## What compliance items does gitMDM check for?
23
+
**Minimal Attack Surface**: No listening ports on agents. No remote execution capability. No auto-updates. The agent can only send data, never receive commands. This isn't configurable - it's architectural.
73
24
74
-
Only the things that come up in a SOC-2 or ISO 27001 report:
25
+
**Transparency Through Simplicity**: Every check we run is visible in `checks.yaml`. The entire codebase is open source. Compliance data is stored in git with immutable history. Security through obscurity is not security.
75
26
76
-
* Antivirus
77
-
* Firewall
78
-
* Full Disk Encryption
79
-
* OS updates
80
-
* Password complexity (respecting NIST 800-36B)
81
-
* Screen locks
27
+
## What Makes This Secure
82
28
83
-
## What kind of bizarre platforms do you support?
84
-
85
-
```yaml
86
-
# Your snowflake setups, our problem:
87
-
- MATE on OpenBSD (we see you)
88
-
- Sway on Alpine (of course)
89
-
- i3 on Debian (classic)
90
-
- Whatever that custom Wayland compositor you wrote is
91
-
- macOS (10.15+)
92
-
- Windows 11/10 (though we've never tried it)
93
-
```
94
-
95
-
## Installation That Respects Your OS
96
-
97
-
- **Linux**: systemd user service (falls back to cron)
98
-
- **(Dragonfly|Net|Free|Open)BSD**: cron
99
-
- **macOS**: launchd
100
-
- **Windows**: Task Scheduler
101
-
102
-
We detect 11+ desktop environments because your team refuses to standardize.
103
-
104
-
## Security Architecture
29
+
Instead of giving servers control over devices, we use a one-way reporting model:
105
30
106
31
```
107
32
[Agent] [Server] [Git]
@@ -113,57 +38,61 @@ We detect 11+ desktop environments because your team refuses to standardize.
113
38
(execute)
114
39
```
115
40
116
-
The server literally cannot execute commands. We removed the code. It's not there.
41
+
Even if an attacker completely owns your server, they cannot:
42
+
- Execute commands on agents
43
+
- Install malware
44
+
- Modify agent behavior
45
+
- Access sensitive local files
46
+
- Pivot to other machines
117
47
118
-
### Configuration Integrity via Sigstore
48
+
##Default Compliance Checks
119
49
120
-
Every agent configuration is cryptographically signed using Sigstore's keyless signing:
50
+
We verify only what's required for SOC 2 and ISO 27001:
51
+
- Disk encryption status
52
+
- Screen lock configuration
53
+
- OS security updates
54
+
- Firewall status
55
+
- Antivirus presence
56
+
- Password policy (NIST 800-63B compliant)
121
57
122
-
```bash
123
-
# Sign configuration with your GitHub identity
124
-
gitmdm-sign --config cmd/agent/checks.yaml
58
+
Want different checks? Edit `cmd/agent/checks.yaml` and rebuild. The checks are part of the binary, not runtime configuration.
> "What happens if someone compromises the server?"
81
+
We love Google Cloud Run for our deployment story - check out `./hacks/deploy.sh` to see how our own production infrastructure works.
153
82
154
-
They get read-only access to compliance reports. They cannot:
155
-
- Push commands to agents (no code for it)
156
-
- Modify agent behavior (signatures prevent it)
157
-
- Install malware (agents don't accept commands)
158
-
Perhaps they can clean up the old stale check-in data while they are there.
83
+
## Security FAQ
159
84
160
-
> "What if someone tampers with the agent?"
85
+
**What's the worst case scenario if my server is compromised?**
86
+
Attackers can read compliance reports and delete them. That's it. They cannot push commands, install software, or access agent machines.
161
87
162
-
They can. It's their machine. They can also lie on spreadsheets. At least this has timestamps.
88
+
**Why not just use osquery?**
89
+
osquery is powerful but requires careful configuration to avoid information leakage. gitMDM is purpose-built for compliance with security as the primary design constraint.
163
90
164
-
> "Is this enterprise-ready?"
91
+
**How do you prevent supply chain attacks?**
92
+
Agents are built from source, checks are compiled in, and with Sigstore integration, all configurations are cryptographically signed with identity verification. Minimal dependencies.
165
93
166
-
No. But neither was Stripe when you started using it.
94
+
**What about insider threats?**
95
+
Even malicious insiders with server access can only view compliance data. To modify agent behavior requires rebuilding and redistributing the binary - leaving an audit trail.
0 commit comments