OpenWatch: The Open-Source Compliance Operating System for Federal Infrastructure

Kensa solves the scanning problem. It evaluates compliance rules, remediates failures with rollback, and generates structured evidence — all over SSH, all in minutes.

But scanning is not the whole problem.

The whole problem is what happens after the scan. And before the next one. And across 200 hosts instead of one. And when an assessor asks a question about last month instead of today. And when your team needs to track exceptions, manage drift, and prove to an auditor that compliance isn't a point-in-time snapshot, it's a continuous operational state.

That's the problem OpenWatch exists to solve.

The Gap Between a Scan and a Program

A compliance engine gives you results. A compliance program requires something more:

Visibility across the fleet. Not one host at a time in a terminal. All of them. At once. With the ability to see which hosts are healthy, which are degrading, and which need immediate attention.

History. Not just "what's passing now" but "what was passing on January 15th." Not just the current posture but the trajectory — is it improving, holding, or decaying? An assessor's first question is almost never about today. It's about the assessment window. If you can't answer questions about the past, you don't have a compliance program. You have a scanner.

Governance. Some controls have approved exceptions. A legacy application requires a weaker cipher suite. An operational system can't enforce a lockout policy without disrupting mission. These exceptions are real, they're approved, and they need to be tracked — not in a spreadsheet that someone updates when they remember, but in a system with request, approval, time limits, revocation, and an audit trail.

Drift detection. A rule that was passing last week is failing today. A sysctl value changed after a kernel update. An sshd setting was overridden by a new drop-in file. A PAM configuration silently degraded after a package update. If nobody is watching continuously, nobody knows until the next assessment. By then, the assessor finds it before you do. That's backwards.

Team coordination. Compliance is not a one-person activity. The ISSO needs to see posture. The engineer needs to see findings. The compliance officer needs to manage exceptions. The auditor needs to export evidence. Each role needs a different view of the same data, governed by permissions that match the organizational structure.

Kensa doesn't solve any of these problems. It was never meant to. Kensa is an engine, it's fast, precise, single-purpose. OpenWatch is the operating system that turns that engine into an operational compliance program.

What OpenWatch Actually Does

Continuous Compliance Posture

OpenWatch scans your fleet on a schedule — but not a static one. The schedule adapts to what the environment is actually doing.

Healthy hosts scan every 15 minutes. Hosts where a finding has appeared scan every 5. Hosts with critical failures scan every 2. The frequency tracks the risk. The dashboard updates in real time.

This isn't monitoring in the sense of "we check periodically." It's monitoring in the sense of "we know the state of every host, at all times, and the system adjusts its attention based on what it finds."

For FedRAMP shops, this is what continuous monitoring is supposed to look like. Not a monthly report assembled from memory. A live posture backed by scan data with timestamps.

Temporal Compliance Queries

This is the capability that changes the conversation with assessors.

An auditor asks: "Were these 200 servers compliant with STIG during the assessment window in January?"

With manual processes, that question takes a week to answer — if it can be answered at all. You'd have to hope someone ran a scan during that window and saved the results. If they didn't, the question is unanswerable. You can scan today, but today's results say nothing about January.

With point-in-time scanning tools, the answer is the same: we can only tell you about now. The past is gone.

With OpenWatch, it's a query. Select the date. Select the framework. Select the hosts. The posture on that date is returned — backed by the scan data that was captured at the time, not reconstructed after the fact.

OpenWatch captures daily posture snapshots automatically. Every scan result is stored with its timestamp. The compliance history isn't assembled for the auditor. It exists because the system generates it continuously.

This is the difference between a scanning tool and a compliance operating system. The scanner tells you what's true now. The operating system tells you what was true at any point you need to prove.

Compliance Drift Detection

A rule that was passing starts failing. Maybe a package update reset a sysctl value. Maybe a configuration management run overwrote a hardened setting. Maybe someone made a manual change on a host and didn't realize it was controlled.

In a manual compliance program, nobody notices until the next scan — which might be weeks or months away. In practice, drift accumulates silently between assessments, and the assessor is the one who discovers it.

OpenWatch detects drift when it happens. When a finding's status changes from passing to failing, an alert is raised. The drift event is tracked through acknowledgment to resolution. Your team knows the moment posture degrades — not weeks later when someone else finds it.

This closes the gap that every periodic compliance program has: the space between assessments where nobody is watching.

Exception Management

Not every finding can be remediated. Some can't be remediated safely. Some are operationally incompatible with the system's mission. Some require compensating controls that don't map neatly to the framework.

In most compliance programs, these exceptions live in spreadsheets. The approval chain is an email thread. The expiration date is tracked by a human who may or may not remember. When the assessor asks for the exception log, someone spends a day reconstructing it from scattered records.

OpenWatch provides structured exception workflows. Request an exception. Route it for approval. Attach a justification. Set a time limit. When the exception expires, the system surfaces it for review. If it's revoked, the finding re-enters the active queue. Every action in the workflow is logged with a timestamp, a user, and a reason.

The exception log is not assembled for the assessor. It generates itself, with an audit trail the assessor can follow from request to approval to expiration.

Multi-Framework Posture

A single Kensa scan maps findings to CIS, STIG, NIST 800-53, PCI-DSS, FedRAMP, ISO 27001, and SRG simultaneously. OpenWatch takes that mapping and turns it into framework-specific posture views.

Your CIS compliance is 94%. Your STIG compliance is 87%. Your NIST 800-53 coverage is 91%. Same hosts. Same evidence. Different lens. One scan produced all of it.

For organizations that face multiple framework obligations — and most federal contractors do — this eliminates the duplicate work that traditionally multiplies with each additional framework. The same evidence satisfies multiple assessors. The same remediation improves posture across every standard.

Audit-Ready Evidence and Exports

Every finding in OpenWatch carries the full evidence chain: host, rule, command executed, raw output, expected value, actual value, timestamp, framework mapping. This evidence is structured, queryable, and exportable.

Build saved queries for recurring audit requests. "Show me all STIG CAT I failures across the production fleet for the last 90 days." Save it. Run it before every assessment. Export as CSV for the spreadsheet analysts, JSON for the automation pipelines, PDF for the binder.

The evidence is generated by the scan. The report is generated by the query. The binder assembles itself.

Who OpenWatch Is For

If you're an ISSO managing 50-300 systems across multiple authorization boundaries, OpenWatch gives you the posture visibility and governance infrastructure that replaces your spreadsheets, your manual scan coordination, and your evidence assembly process.

If you're a CISO or security leader accountable for compliance posture across the organization, OpenWatch gives you a live dashboard backed by real data — not a quarterly report based on a scan that happened three months ago. When the board asks "are we compliant," your answer has a timestamp.

If you're a program manager responsible for CMMC, FedRAMP, or FISMA authorization, OpenWatch gives you the temporal posture data that assessors are starting to expect. Not "we believe we were compliant." Instead: "here is our posture on every date in the assessment window, with evidence."

If you're an IT manager trying to protect your team's capacity, OpenWatch means your engineers stop spending weeks on evidence assembly and start reviewing automated results. The compliance program runs in the background. Your team runs the mission.

Architecture

OpenWatch is a full-stack platform, not a wrapper around a CLI:

• Backend: FastAPI with 80+ REST API endpoints. Everything you see in the dashboard, you can automate.
• Frontend: React with Material-UI. Responsive. Clean. Designed for the people who actually use it, not for screenshots in a sales deck.
• Engine: Kensa. 508 rules and growing, 23 remediation mechanisms, 22 capability probes. The same engine you can use standalone from the command line.
• Database: PostgreSQL. All persistent data — scan results, posture history, exceptions, audit logs.
• Task queue: Redis + Celery. Asynchronous scanning across 100+ hosts in parallel.
• Administration: owadm — a Go CLI for deployment operations. Start, stop, status, logs, migrations, health checks.

OpenWatch can be deployed natively on RPM-based and DEB-based server with full support for air-gapped environment. Complete support is avaiable for Docker and Podman deployment.

Security

OpenWatch is built for environments where security is the requirement, not the afterthought.

AES-256-GCM encryption for stored credentials. RS256 JWT authentication with Argon2id password hashing. TOTP multi-factor authentication. FIPS 140-2 Level 1 compliant cryptography. Six-role RBAC — from super admin to guest — with granular permissions. Rate limiting. TLS 1.2+ with FIPS cipher suites in production. Full audit logging for every authentication, authorization, and compliance event.

A compliance tool that isn't itself compliant has no credibility. OpenWatch is designed to be deployable in the same environments it monitors.

Kensa and OpenWatch Together

Kensa is the engine. OpenWatch is the platform. Neither alone is a compliance program.

Kensa without OpenWatch is a powerful CLI — fast, precise, excellent for single-host scans, scripts, and pipelines. It's where individual engineers start.

OpenWatch without Kensa has no scanning capability. The platform needs the engine.

Together, they form the compliance control plane:

• Kensa scans, remediates, and generates evidence at the host level
• OpenWatch orchestrates scans across the fleet, stores the history, detects drift, manages governance, and presents the posture to every role in the organization

If you need a CLI tool to scan and remediate with peace of mind, Kensa is your tool. If you need a platform for your team — a dashboard, scheduling, governance, and audit workflows, start with OpenWatch.

If you want help deploying OpenWatch on your infrastructure, configuring it for your frameworks, or training your team to operate it — that's what we do. You can find the Kensa and OpenWatch documentation or Reach out for demo.