Skip to main content

​
How remediation works

Remediation is a three-phase process for each failing rule:
  1. Pre-state capture. Kensa records the current value of every setting it will change.
  2. Apply fix. The remediation mechanism writes the corrected configuration.
  3. Post-check. Kensa re-runs the compliance check to verify the fix took effect.
If step 3 fails and --rollback-on-failure is active, Kensa reverses all changes for that rule using the captured pre-state data.

​
Remediation mechanisms

All remediations use typed, declarative mechanisms — not arbitrary shell scripts. Each mechanism is idempotent (running it twice produces the same result as running it once). Kensa selects the most durable option available: drop-in files in .d/ directories survive package updates, while direct config edits may be overwritten.

​
Risk classification

Every remediation step is assigned a risk level based on its mechanism type and target path:
RiskScope
HighMechanisms affecting boot, authentication, or mount behavior: GRUB parameters, kernel module disabling, PAM configuration, mount options. Also triggered by high-risk paths: /etc/pam.d/, /etc/fstab, /etc/default/grub, /etc/selinux/config.
MediumMechanisms that change service or kernel behavior: config file edits, sysctl values, service masking, audit rules, SELinux booleans.
LowNarrow-scope changes: file permissions, package install/remove, cron jobs.

​
Snapshot configuration

The rollback section of config/defaults.yml controls pre-state capture: 
rollback:
  snapshot: all             # all | risk_based | none
  risk_threshold: medium    # Minimum risk level when snapshot=risk_based
  high_risk_paths: []       # Additional paths that elevate risk to high
  snapshot_active_days: 7   # Full rollback available within this window
  snapshot_archive_days: 90 # Metadata retained, pre-state data pruned
  • all (default): Capture pre-state for every remediation step.
  • risk_based: Capture only for steps at or above the risk threshold.
  • none: No snapshots. Faster, but rollback is unavailable.

​
Rollback workflow

1

Remediate with safety net

kensa remediate -h 192.168.1.10 -u admin --sudo --rollback-on-failure
2

List sessions if you need to reverse later

kensa rollback --list
3

Inspect what was changed

kensa rollback --info 3 --detail
4

Preview and execute rollback

# Preview
kensa rollback --start 3 -h 192.168.1.10 -u admin --sudo --dry-run

# Execute
kensa rollback --start 3 -h 192.168.1.10 -u admin --sudo

​
Non-capturable mechanisms

Three mechanism types cannot capture pre-state:
  • command_exec — arbitrary commands
  • manual — human-performed steps
  • grub_parameter_set/remove — requires regenerating boot config
Kensa surfaces these explicitly so operators know which steps lack rollback coverage.

​
History and drift detection

​
Storing results

Add --store to any check command to persist results in the local SQLite database (.kensa/results.db): 
kensa check -h 192.168.1.10 -u admin --sudo --store

​
Tracking drift

Compare two scan sessions to find regressions and improvements: 
# Run a baseline scan
kensa check -h 192.168.1.10 -u admin --sudo --store

# ... time passes, changes are made ...

# Run a follow-up scan
kensa check -h 192.168.1.10 -u admin --sudo --store

# Compare
kensa history                               # Find session IDs
kensa diff 1 2                              # See what changed
diff reports four categories: regressions (previously passing rules that now fail), resolved (previously failing rules that now pass), new failures, and new passes.

​
Database maintenance

# See database size and record counts
kensa history --stats

# Remove results older than 90 days
kensa history --prune 90
Remediation snapshots follow their own retention policy (configurable in defaults.yml): full rollback data is available for 7 days (active window), metadata is retained for 90 days (archive window), then records are pruned.