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
A security-first MDM that proves compliance without compromising your infrastructure.
9
+
A security-first MDM that manages compliance without compromising your infrastructure.
10
10
11
11
![logo](./media/logo_small.png"gitMDM logo")
12
12
13
13
## A Different Approach to Device Management
14
14
15
15
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.
16
16
17
-
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.
17
+
gitMDM takes a security-first approach. Built on the principle that a compromise of your MDM server shouldn't result in an instant root-level compromise of its clients.
18
18
19
-
## Demo
19
+
## Features
20
20
21
-
https://gitmdm.codegroove.dev/ - a real life instance of gitMDM.
* YAML configuration - cryptographically signed using [sigstore](https://sigstore.org/)
23
+
* Designed to run as a non-root user
24
+
* Uses [git](https://git.org/) as a datastore for a persistent trail of events
25
+
* Secure-by-design with a minimal attack surface
26
+
* Low maintenance, low dependencies
27
+
* Self-hostable on anything from [Google Cloud Run](https://cloud.google.com/run) to a [Raspberry Pi running Plan 9](https://luksamuk.codes/posts/plan9-setup-rpi.html)
22
28
23
-
### Core Security Principles
29
+
##Demo
24
30
25
-
**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.
31
+
📺 https://gitmdm.codegroove.dev/ - a real-life unrestricted instance of gitMDM.
26
32
27
-
**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.
33
+
## Default Compliance Checks
28
34
29
-
**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.
35
+
By default, we verify only what we interpret as required for SOC 2 and ISO 27001 compliance:
36
+
37
+
- Disk encryption status
38
+
- Screen lock configuration
39
+
- OS security updates
40
+
- Firewall status
41
+
- Antivirus presence
42
+
- Password policy (NIST 800-63B compliant)
30
43
31
-
**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.
44
+
Want different checks? Edit `cmd/agent/checks.yaml`, sign the configuration, and run "make build". The checks are part of the binary, not runtime configuration.
32
45
33
46
## What Makes This Secure
34
47
@@ -44,61 +57,77 @@ Instead of giving servers control over devices, we use a one-way reporting model
44
57
(execute)
45
58
```
46
59
47
-
Even if an attacker completely owns your server, they cannot:
48
-
- Execute commands on agents
49
-
- Install malware
50
-
- Modify agent behavior
51
-
- Access sensitive local files
52
-
- Pivot to other machines
60
+
Even if an attacker completely owns your server, they cannot modify agent behavior.
53
61
54
-
## Default Compliance Checks
62
+
NOTE: We plan on making this approach more flexible in the future, but we will always choose secure-by-default.
55
63
56
-
We verify only what's required for SOC 2 and ISO 27001:
57
-
- Disk encryption status
58
-
- Screen lock configuration
59
-
- OS security updates
60
-
- Firewall status
61
-
- Antivirus presence
62
-
- Password policy (NIST 800-63B compliant)
64
+
## Quick Start
63
65
64
-
Want different checks? Edit `cmd/agent/checks.yaml` and rebuild. The checks are part of the binary, not runtime configuration.
66
+
### Server-less test of the agent
65
67
66
-
## Platform Support
68
+
Want to see what the agent checks for without connecting it to a server? We've got you covered:
67
69
68
-
Secure on every platform:
69
-
- Linux (all distros, all desktop environments)
70
-
- macOS (10.15+)
71
-
- BSD variants (Free/Open/Net/Dragonfly)
72
-
- Windows 10/11
73
-
- Solaris/Illumos
70
+
```
71
+
go run ./cmd/agent/ --run all --verbose
72
+
🔍 Running compliance checks...
74
73
75
-
## Quick Start
74
+
✅ AVAILABLE UPDATES [PASS]
75
+
Command: softwareupdate -l
76
+
Output:
77
+
Software Update Tool
78
+
79
+
Finding available software
80
+
Stderr: No new software available.
81
+
82
+
Status: OK
83
+
...
84
+
85
+
```
86
+
87
+
### Client/Server configuration
88
+
89
+
Build the command-line utilities:
76
90
77
91
```bash
78
92
make all
93
+
```
94
+
95
+
To run the MDM server, there are two options for storage:
79
96
80
-
# Server (git-backed for auditability)
97
+
*`-git`: the location of a git repo to clone and push to; if it's a local directory, we'll even `git init` the directory for you
98
+
*`-clone`: the path to a locally checked out clone of a remote git repo.
99
+
100
+
```
81
101
gitmdm-server -git /var/git
102
+
```
103
+
104
+
By default, the server will generate a join key that clients need to confirm they are talking to the correct server. You can pass in a custom string using `--join scoobysnacks`. If the join key leaks, the worst someone can do is upload garbage compliance data for their machine.
105
+
106
+
We love Google Cloud Run for our deployment story - check out `./hacks/deploy.sh` to see how our own production infrastructure works.
We love Google Cloud Run for our deployment story - check out `./hacks/deploy.sh` to see how our own production infrastructure works.
117
+
To persistently install the agent, add `--install`, which will populate launchd (macOS), task scheduler (Windows), user-systemd (Linux), or cron (elsewhere).
88
118
89
119
## Security FAQ
90
120
91
-
**What's the worst case scenario if my server is compromised?**
92
-
Attackers can read compliance reports and delete them. That's it. They cannot push commands, install software, or access agent machines.
121
+
**What's the worst-case scenario if my server is compromised?**
93
122
94
-
**Why not just use osquery?**
95
-
We ❤️ osquery – enough that we previously created [osquery-defense-kit](https://github.com/chainguard-dev/osquery-defense-kit) - but it's only part of an MDM solution, and didn't meet our goals when it came to platform support & operating with low privilege.
123
+
Attackers can read compliance reports and trash them. They cannot push commands, install software, or access agent machines.
96
124
97
125
**How do you prevent supply chain attacks?**
98
126
Agents are built from source, checks are compiled in, and with Sigstore integration, all configurations are cryptographically signed with identity verification. Minimal dependencies.
99
127
100
-
**What about insider threats?**
101
-
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.
128
+
## Contributions
129
+
130
+
... are very much appreciated. We actually want this to be useful.
0 commit comments