When configuring a new device, achieving an acceptable Lynis hardening score is a challenge most practitioners are familiar with.
Navigating its recommendations often requires significant background knowledge, leaving administrators without clear guidance on which settings are vulnerable and how to remediate them effectively.
We believe that security hardening should be insightful and accessible, a philosophy that drove this research and the development of our tool, Hardener, built around three identified deficits in established frameworks:
- Users should not be forced to rely on undocumented internal standards or checks. An
[ OK ]as status without ever displaying the used baseline check, detected behavior or any other details is undesirable. - The findings of a tool should be automatically remediatable, without regressing already secure states and with the option to rollback atomic changes made in that process.
- The resulting tool should be designed as a statically linked binary requiring no external interpreters or specialized libraries to ensure immediate operationality across heterogeneous, Unix-like environments.
To bridge these gaps, we engineered Hardener around the principle of Documentation-as-Code: By embedding audit and remediation logic directly within a Markdown frontmatter above the actual security documentation, we aim to replace “ID juggling” with transparency, verifiability and ease of use.
Before applying any automated fix, Hardener runs a diagnostic audit and takes a safety snapshot. This allows you to trigger an atomic rollback at any point, instantly reverting your system to its exact pre-execution state.
Testing at Scale
To ensure deterministic behavior across a fragmented Linux ecosystem, we built an automated, VM-based test harness using KVM, Vagrant, and libvirt.
For every code change, the runner programmatically boots a pristine VM, syncs the setup files, and executes a strict verification loop of all tool functionality, going from auditing to fixing, to rollbacking and back to auditing. Finally, it extracts structured JSON telemetry over SSH and destroys the instance.
We successfully used this setup to validate Hardener across Ubuntu, Debian, Rocky Linux, openSUSE, Arch Linux, Fedora, and RHEL, to guarantee that when a ruleset interacts with distribution-specific tools or applications, the outcome remains entirely predictable and secure.
You can find and utilize this test setup in the Hardener repository. Hardener and the accompanying white paper are now publicly available on GitHub and on our website. With this tool we are providing a respective ruleset to enable automatic auditing, fixing and rollbacking of macOS systems following our recently released macOS 26 Tahoe hardening guide as well as a respective ruleset for the currently released Linux hardening guide.
Cheers!
Niklas
See also relating white papers and resources by ERNW:
- ERNW White Paper 75: macOS Tahoe Hardening Guide
- ERNW White Paper 76: Linux Client Hardening Guide
- ERNW White Paper 77: Unified Security Hardening with Cross-Platform Native Binaries
- ERNW Hardening GitHub Repository
Want to learn more how to secure your infrastructure & systems? Get trained by experts at #TROOPERS26!