We're Automating CMMC Compliance.
And We Won't Sell It Until It Survives Our Own Servers.

The problem with most compliance tooling

Ask most CMMC "compliance platforms" what they actually enforce on a box, and the honest answer is usually: not much. A checklist gets filled out, a PDF gets generated, and the actual operating system underneath — the thing an assessor's scanner touches — never changes. That gap is where audits fail and, worse, where real incidents happen.

We wanted something different: a Salt formula that maps every applicable requirement in NIST SP 800-171 to an actual, testable state on the host — access control, audit logging, session limits, boundary protection, the whole technical surface of CMMC Level 2 — and tells you the truth about which requirements code can satisfy and which ones are genuinely a policy document's job, not a script's.

Where it actually stands

Of the 110 requirements in NIST SP 800-171 Revision 2, roughly half are organizational by nature — personnel screening, physical security, written policy — and no amount of Salt code will ever touch them. That's not a gap in the tooling; that's just what those requirements are. Of the remainder — the part an operating system can actually be held accountable for — we're automating about 95% of it today, with a real, working Salt state behind each one.

The last few percent aren't unfinished by accident. They're either things we've deliberately decided not to automate blind (more on that below), or one control we confirmed, by checking rather than assuming, simply doesn't fit a continuously-converged infrastructure model at all — it's about how a temporary password gets issued to a brand-new employee, not something that exists in a system's steady state.

Debian and Ubuntu came first, because that's what our own production infrastructure runs. Red Hat family — Rocky and Alma — came next, and it taught us something worth repeating in public: for a long stretch, those states rendered correctly without ever having been applied to a real Red Hat host. The first time we actually ran them against one, eight distinct defects fell out in a single pass. All eight are fixed. None of them would have been caught by reading the code, and none of them were visible from a clean render. Rendering is not running, and we'd rather say that out loud than let anyone assume we'd tested something we hadn't.

There is now a complete Windows tree as well — Level 1, and Level 2 Revision 2 across all eight technical families, with the report module classifying controls on Windows the same way it does on Linux. Two honest limits on that: it has only ever run against standalone servers, so the paths that apply when Group Policy owns a setting on a domain-joined machine have not executed even once, and the workstation profile has never touched a real Windows client. Both need a lab we haven't stood up yet. We're calling that unproven rather than supported, and Revision 3 on Windows we've refused outright rather than guess at it.

We test on ourselves first

This formula runs, right now, against two of our own live production systems — this site's own hosting, and a separate production SaaS platform we operate. Not a lab environment. Not a disposable VM spun up for a demo. The actual boxes that actual traffic hits.

That's caught real bugs before they became someone else's incident: a wrong package name for a hardening tool on Debian, a stale firewall rule that would have quietly left SSH exposed after a "fix," a false positive against a cloud provider's own managed sudo configuration, a resource-sizing mistake that briefly made a small server unresponsive under its own hardening job. Every one of those was found and fixed against real infrastructure, not caught later by a client — or an assessor.

We also draw a hard line on what we'll enable without direct verification. The single highest-risk change in this entire formula — the control that limits failed login attempts — has a well-known failure mode on one operating system family: get the implementation wrong, and it doesn't just stop attackers, it locks out every legitimate login, including the administrator's, all at once. We wouldn't ship that on a guess. So we didn't — we built an isolated test harness, ran the actual system tool against scratch copies of the configuration (never a live system) until we could prove, not assume, that a correct password gets through and an incorrect one gets denied, with a clean rollback path either way. Multi-factor authentication for privileged access is staged the same way: fully built, deliberately switched off until every account has enrolled and a non-SSH recovery path is confirmed open.

Where the results go next

A hardening run tells you where a host stood at one moment. That's useful once and much less useful the second time you're asked. So the formula can now hand its per-control verdicts to a compliance workspace, where a host's posture stops being a report you generate and becomes evidence attached to a system — tracked over time, rolled into scores, and mapped across frameworks rather than re-derived by hand for each one. That workspace is ScopeHunter, which we build and run ourselves, and it's the same story as the formula: in active development, in production on our own infrastructure, and not being described here as finished.

The important part is what it does not do. Reporting is off unless you turn it on. It requires an endpoint, a system identifier, and a token to be configured deliberately; absent any one of them it refuses to run rather than falling back to a default. Nothing is transmitted off a host that hasn't been explicitly pointed somewhere, and the formula carries no third-party HTTP dependency to do it.

We'd rather flag the trade-off than bury it: the evidence a check produces is free text — process names, ports, file paths, account names. That's exactly what makes it useful to an assessor, and exactly why sending it anywhere is a data-handling decision, not a toggle. If your hosts sit inside a CUI enclave, that decision is yours to make deliberately, which is the whole reason we built it to stay quiet by default. The boundary rule this rests on — and exactly what the platform will and won't hold — is written out in full on ScopeHunter's own scope statement, and its build log, including the part where we say plainly that it is not an authorized system for storing CUI.