Why I Built Kensa: Open-Source STIG Compliance Automation

I've spent 12 years inside the environments this tool is built for.

Army IT infrastructure. FBI networks. DHS systems. DoD contractor environments. Hundreds of Red Hat servers under DISA STIG requirements, assessed quarterly, remediated manually, documented in spreadsheets that were outdated before the assessor opened them.

I've been the person who SSHs into a server at 11 PM to verify controls configuration because the assessment window opens Monday. I've been the person who runs a remediation script on a Friday afternoon and watches it lock out SSH access on 12 hosts because the script didn't account for sshd drop-in directories. I've been the person who rebuilds the evidence binder for the third time because the format changed or a control mapping was wrong or someone wanted it done any way.

That experience — repeating across every team, every contract, every assessment cycle — is why Kensa exists.

The Pattern

Here's what I watched happen, repeatedly, across every federal environment I worked in:

The assessment passes. The team puts in weeks of effort. Evidence is compiled. Findings are remediated. The assessor signs off. Everyone exhales.

The posture immediately begins to decay. A kernel update changes a sysctl value. An admin modifies an sshd setting. A PAM configuration silently degrades after a package update. Nobody notices because there's no continuous monitoring — the scanning tool was a point-in-time exercise.

The next assessment starts from scratch. The same servers. The same checks. The same manual SSH sessions, the same stdout copied into spreadsheets, the same framework cross-referencing. Nothing from the last cycle carries forward. The evidence is reassembled, not referenced.

The cost never decreases. The fifth assessment costs the same as the first. The team gets faster at the manual process — but the process itself doesn't improve. It can't. It's structurally manual.

Remediation is the most dangerous part. The Bash script that hardens 50 servers works on 47 of them. On 3, the sshd configuration uses drop-in directories, or authselect manages PAM, or FIPS mode changes which crypto policies apply. The script doesn't know. It applies the change. The service breaks. The rollback is manual, host by host, if someone captured the pre-state. Usually they didn't.

This pattern isn't a failure of people. The teams I've worked with are skilled, dedicated, and doing their best inside a process that wastes their time. The failure is structural. The tooling forces manual work at every step, and manual work doesn't compound.

What I Wanted to Exist

Before I built Kensa, I looked for a tool that did what I needed. Here's what I found — and what was missing:

OpenSCAP is a solid assessment tool. It has NIST certification. It's mandated in some federal environments. It does what it's designed to do: validate a system against a SCAP benchmark and produce a structured assessment result. But OpenSCAP is built around benchmark documents — one SCAP datastream per OS version, organized by the structure of the benchmark, not the structure of the problem. The XCCDF/OVAL content is XML that's difficult for engineers to read, customize, or version-control. And its remediation model — embedded Bash scripts — doesn't capture pre-state and doesn't roll back on failure. OpenSCAP answers "does this system pass this benchmark?"

What I needed was a tool that answers "how do I ensure this security control is enforced safely, prove it, and undo it if something goes wrong?"

Ansible Lockdown gets closer to remediation, but with Ansible tasks that also don't capture pre-state, don't roll back on failure, and require maintaining separate repositories per framework per OS version. RHEL8-CIS, RHEL9-CIS, RHEL8-STIG, RHEL9-STIG — four repos that share 70-80% of their logic but are maintained as independent codebases. When a bug is fixed in one, it has to be manually ported to the others. In practice, it isn't. The codebases drift.

Nessus is powerful but cost $50,000+ per year — impossible for most small business and small teams. And they're assessment tools, not remediation engines.

The gap wasn't in scanning. The gap was in everything that comes after: safe remediation with rollback, one rule that works across frameworks and OS versions without duplication, and evidence that's structured enough for an assessor to independently verify.

What I wanted was:

• Rules separated from their implementations — the rule is the stable core, the mechanism is the variable shell
• Capabilities detected at runtime (does this host support sshd drop-in directories?) instead of version-string conditionals (is this RHEL 9?)
• Frameworks treated as metadata labels, not reasons to duplicate the entire rule set
• Typed remediation mechanisms that capture pre-state and roll back automatically on failure
• Evidence that's structured, machine-verifiable, and exportable
• SSH — no agents, no daemons, no packages installed on targets

That tool didn't exist. So I built it.

What Kensa Actually Does

Kensa connects to your RHEL servers over SSH, evaluates 508 compliance rules, and generates structured evidence for every check — the exact command, the raw output, the expected value, the actual value, and a UTC timestamp.

Each rule maps to CIS, STIG, NIST 800-53, PCI-DSS, FedRAMP, ISO 27001, and SRG simultaneously. Run one scan, satisfy every assessor.

When a check fails, Kensa can remediate it — not with a Bash script, but with one of 23 typed, declarative mechanisms. config_set. service_disabled. sysctl_set. pam_module_config. Each mechanism captures pre-state before touching the system. If any step fails, all completed steps are automatically reversed. Your system is never left half-remediated.

22 runtime probes detect what each host actually supports — sshd drop-in directories, authselect, crypto policies, FIPS mode, SELinux, firewalld backend. The correct implementation variant is selected automatically. One rule works across RHEL 8, 9, and 10 without version-specific content.

The rules are YAML. Human-readable. Git-friendly. Reviewable in a pull request. Modifiable with a text editor. No XML parser required.

Why It Matters for Small Contractors

If you're a 50-person defense contractor with a 3-person security team and CMMC on the horizon, you have two choices:

Option A: Hire a Big 4 consulting firm for $100,000-$200,000 to assess your environment, produce a report, and hand you a remediation list you'll execute manually.

Option B: Run Kensa against your Linux fleet in an afternoon, see your actual posture across every framework, remediate the failures with automatic rollback, and hand your assessor structured evidence they can independently verify. Cost: zero for the community edition.

The assessment is the starting line, not the finish. What matters is what happens between assessments — whether the posture holds, whether drift is detected, whether the cost of maintaining compliance decreases over time.

That's what Kensa is built for. And that's why I built OpenWatch on top of it — a compliance operating system with a dashboard, adaptive scheduling, drift detection, temporal queries, and governance workflows. Together, they're the compliance control plane for teams that don't have the budget for enterprise tooling or the headcount for manual processes.

Both are open source. Both are free to evaluate. Both are built specifically for the federal compliance problem because that's the problem I've spent my career inside of.

Start Here

Kensa: — Install, scan a host, see your posture in 5 minutes.

OpenWatch: — Deploy with Docker, scan your fleet, see everything continuously.

If you want help — a free assessment of your environment, a walkthrough of the results, or a conversation about what CMMC readiness actually looks like for your team — reach out. That's what we're here for.