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
chore(deps): bump Kensa to v0.6.0 (atomicity engine; 538 rules) (#670)
* chore(deps): bump Kensa to v0.6.0 (atomicity engine; 538 rules)
Updates the bundled Kensa scan engine + rule corpus from v0.5.2 to v0.6.0,
keeping the three version pins in sync (go.mod, internal/kensa.KensaModuleVersion,
specs/system/kensa-executor.spec.yaml — TestKensaModuleVersion/TestSpec_VersionPin
enforce agreement).
What's in v0.6.0:
- The remediation "atomicity engine": crash-recovery intent journal + `kensa
recover`, mandatory post-apply VALIDATE re-check, post-state recapture into
the signed evidence envelope, a footprint pre-commit gate, and agent-mode
kernel-IO handlers. Kensa's CHANGELOG marks the consumed `api/` surface as
additive (crash-recovery types) with no breaking change; the OpenWatch build
and scan-path tests confirm it.
- Rule corpus: 539 -> 538. One STIG rule was removed
(system/pkg-gdm-absent.yml). No rules added.
- Pulls 3 new indirect deps (elastic/go-libaudit, elastic/go-licenser,
kballard/go-shellquote) from the agent-mode kernel-IO features.
Verified: go build ./... clean, go vet clean, internal/kensa + the server
scan-config/variable-catalog/lens tests pass, specter check 113/113 at 100%
coverage.
Note: docs/README/guides reference "539" rules; those need a 539->538 follow-up
(left out here to avoid colliding with the pending README PR #669).
* docs(kensa): update rule count 539 -> 538 for v0.6.0
Kensa v0.6.0 removed one rule, so the bundled corpus is now 538 (verified
by a live end-to-end scan against a RHEL host: status=completed,
total_rules=538, 0 errors). Update the factual rule-count claims in the
README and the scanning/controls guides to match.
Version-pinned historical statements are intentionally left unchanged
(LINUX_DISTRIBUTION_SUPPORT verified against v0.4.3=539; engineering
plan past measurements), as are the explicitly-approximate "~539"
architectural bounds in the lens handler/openapi (the tilde already
disclaims precision and the bounded-no-pagination claim is unaffected).
Copy file name to clipboardExpand all lines: README.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ An auditor asks: *"Were these 200 servers compliant with STIG on January 15th?"*
13
13
14
14
With manual processes, that question takes a week to answer. With point-in-time scanning tools, you can only answer if you happened to scan that day. With OpenWatch, it is a query — executed in seconds, backed by machine-verifiable evidence, exportable as CSV, JSON, or PDF.
15
15
16
-
OpenWatch is the compliance operating system for teams managing Linux infrastructure under STIG, CIS, NIST 800-53, PCI-DSS, and FedRAMP. It connects to your servers over SSH, runs 539 compliance checks via the [Kensa](https://github.com/Hanalyx/kensa) engine, and provides continuous visibility into compliance posture — not just what's passing now, but what was passing last Tuesday, what drifted since your last assessment, and what needs attention before your next one.
16
+
OpenWatch is the compliance operating system for teams managing Linux infrastructure under STIG, CIS, NIST 800-53, PCI-DSS, and FedRAMP. It connects to your servers over SSH, runs 538 compliance checks via the [Kensa](https://github.com/Hanalyx/kensa) engine, and provides continuous visibility into compliance posture — not just what's passing now, but what was passing last Tuesday, what drifted since your last assessment, and what needs attention before your next one.
17
17
18
18
> **Project status — Go rebuild, pre-release.** OpenWatch is a single Go binary
19
19
> that serves both the REST API and the embedded React UI (the original
@@ -104,7 +104,7 @@ Open **https://localhost:8443** and sign in with the admin user you created.
104
104
2.**Add a host** — Hosts > Add Host > enter IP, select credentials
105
105
3.**Scan** — Click the play button on the host card
106
106
107
-
Results appear in under a minute. OpenWatch ships with 539 built-in [Kensa](https://github.com/Hanalyx/kensa) rules — human-readable YAML, not XML — ready to go.
107
+
Results appear in under a minute. OpenWatch ships with 538 built-in [Kensa](https://github.com/Hanalyx/kensa) rules — human-readable YAML, not XML — ready to go.
108
108
109
109
## Architecture
110
110
@@ -121,7 +121,7 @@ Results appear in under a minute. OpenWatch ships with 539 built-in [Kensa](http
OpenWatch is the compliance operating system — the dashboard, the scheduler, the governance layer. **[Kensa](https://github.com/Hanalyx/kensa)** is the compliance engine underneath — 539 rules, 23 remediation mechanisms, automatic rollback, all over SSH.
249
+
OpenWatch is the compliance operating system — the dashboard, the scheduler, the governance layer. **[Kensa](https://github.com/Hanalyx/kensa)** is the compliance engine underneath — 538 rules, 23 remediation mechanisms, automatic rollback, all over SSH.
250
250
251
251
If you want a CLI that integrates into scripts and pipelines, start with Kensa. If you want a platform for your team with a dashboard, scheduling, and audit workflows, start here.
Copy file name to clipboardExpand all lines: specs/system/kensa-executor.spec.yaml
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ spec:
10
10
feature: Kensa scan execution bridge
11
11
description: >
12
12
The executor invokes Kensa (Go module github.com/Hanalyx/kensa
13
-
pinned to v0.5.2) to run a scan against a single host using the
13
+
pinned to v0.6.0) to run a scan against a single host using the
14
14
FULL rule corpus applicable to the host's detected OS
15
15
capabilities. The Kensa API (`Kensa.Scan(ctx, host, rules,
16
16
opts...)` per kensa-go/api/kensa.go:228) takes a `[]*api.Rule`
@@ -131,7 +131,7 @@ spec:
131
131
type: technical
132
132
enforcement: error
133
133
- id: C-13
134
-
description: The production scanFunc MUST compose the scan-only Kensa via api.New with pkg/kensa.NewScanner (kensa v0.5.2 — stateless, concurrency-safe shared) and this package's TransportFactory; no engine, store, or signer is constructed for the scan path. The worker subcommand binds it via WithScanFunc(NewProductionScanFunc(...)). unwiredScanFunc may remain ONLY as the test fallback NewExecutor defaults to before binding, annotated as such
134
+
description: The production scanFunc MUST compose the scan-only Kensa via api.New with pkg/kensa.NewScanner (kensa v0.6.0 — stateless, concurrency-safe shared) and this package's TransportFactory; no engine, store, or signer is constructed for the scan path. The worker subcommand binds it via WithScanFunc(NewProductionScanFunc(...)). unwiredScanFunc may remain ONLY as the test fallback NewExecutor defaults to before binding, annotated as such
0 commit comments