The ERNW hardening repository is a baseline, not a finished answer

A baseline corpus written for people who operate the system

ERNW publishes hardening guides for operating systems and hypervisors, and this repository is where they live. The project's own summary is unusually clear about the intent: most of those guides strive to provide a baseline level of hardening and may lack certain hardening options that could increase the security posture even more, but may have impact on operations or required operational effort. That single sentence defines the project. It is not an exhaustive catalogue of every switch worth flipping, it is a documented floor that an operator can adopt without first arguing about how much operational friction each option adds. The audience is therefore teams that need to justify a hardening baseline to an auditor or a security reviewer, and who want the reasoning written down in a file rather than living in a runbook. The corpus is also not a tool. Nothing in it executes, and there is no package to install.

Folders are the taxonomy, and no guide stands alone

Guides are grouped into categories represented by folders, and the rule that governs the whole repository is that every hardening guide must be used in combination with the hardening guides of the parent folders. The repository illustrates the shape with a fictional structure, where a general web application guide sits at the top, a WordPress guide sits one level down, and a version specific WordPress guide sits below that. In that layout all three files need to be taken into account for full hardening coverage. This is the mechanism that makes the corpus workable: the tree encodes applicability, and a file deep in the tree is a delta on top of its ancestors rather than a standalone checklist. It also means a naive script that picks one file is wrong by construction, since the general guidance in the parent folder is not repeated in the child file.

The most specific file wins a conflicting option

Where options collide, the project gives a deterministic answer: if there are conflicting options, the most specific option must be used, in the example given the option coming from the version specific WordPress file wins over the broader WordPress file and over the web application file. This is the piece of the design that makes the tree safe to use in automation. A merge order can be implemented directly from the directory depth, so a configuration management tool could combine the applicable guides and let the deepest matching file override its ancestors. What the project does not spell out is how such a merge would treat two files at the same depth, or how options that are not simply key and value pairs should be combined, so anyone planning to build tooling on top of the corpus would need to read the guides themselves rather than assume a general schema. The filenames follow a consistent ERNW_Hardening_<Product>[_<Version>].md pattern, which makes the tree navigable even without an index.

The repository root holds two categories and one README

Looking at the top level of the repository, the entries are README.md, hypervisor/ and operating_system/. That is the entire scope of what is published here: two categories, one of them covering virtualization platforms, the other covering operating systems, plus the README that explains the layering rules. There is no LICENSE file among the top level entries, and the repository's licence is listed as unknown, which means the terms for copying the text, adapting a guide for your own environment, or folding it into an internal policy are not stated by the project. The primary language is also not recorded. For a document that people are likely to copy from, that is a genuine gap rather than a technicality. A guide you intend to reuse in an internal repository needs a licence you can point at, and a guide you intend to translate needs to know whether translation and redistribution are permitted.

Working through a guide: no install step, a reading order

There is nothing to install, and the README gives no installation command or package name, because the deliverable is a set of markdown documents rather than software. A first use therefore looks like this: pick the product you run, open the matching folder under operating_system/ or hypervisor/, and check whether the folder tree continues into a version specific subfolder before you start reading. The README uses this fictional layout to show how the nesting works:

* web_application
 * ERNW_Hardening_Web_Application.md
 * wordpress
   * ERNW_Hardening_Wordpress.md
   *  4.4.2
      * ERNW_Hardening_Wordpress_4.4.2.md

Read the parent guide first, then the child, then the version specific file, and record the merged result as your configuration. The project invites contact for questions, additions, spotted mistakes or similar, which tells you the maintainers expect the corpus to be corrected by users rather than to be read as immutable.

The project's own list of outside hardening references

The project closes with a section of other hardening sources, and it describes the list as incomplete. Named there are dev-sec.io, the CIS benchmark downloads, the OWASP Secure Configuration Guide, an applied crypto hardening document hosted by bettercrypto, Team Cymru templates, and the sektioneins/pcc repository. The list is useful precisely because it shows where this corpus stops. The ERNW repository covers two categories of infrastructure product and organises guidance by product and version, while these other references sit outside that taxonomy: the CIS downloads are a benchmark library, the OWASP guide is tied to application configuration, and the applied crypto document is a single deep treatment of cryptography settings rather than a per product checklist. If your target is a web application rather than a hypervisor or a base operating system, the OWASP Secure Configuration Guide is the reference this project points you toward, and the layered folder logic here does not apply to it at all.

Versioning lives in the folder tree, not in releases

There are no GitHub releases for this repository, so there is no artefact to pin, no changelog to diff, and no upgrade path in the usual package sense. Versioning is expressed structurally instead, by nesting a version folder under the product folder, as the 4.4.2 folder in the README example shows. That has a practical effect on maintenance. A new version of a product does not produce a tagged release you can diff against the previous one, it produces a new document in a new folder, and the relationship between the two documents has to be read rather than computed. The last push was on 2026-10-01, so the guidance is being revisited, but the absence of releases also means there is no stated support window and no explicit signal that a given guide has been reviewed for a given product version. If your process depends on knowing how old a baseline is, the git history of the file is the only evidence available.

Editorial conclusion

Adopt the ERNW repository if you want a written baseline for operating system and hypervisor hardening that you can cite in a review, and keep treating it as the first layer of a larger hardening effort rather than the finished policy. Do not rely on it as your only reference, because the baseline omits options that need operational effort, and the repository root states no licence, so redistribution terms are not settled by what the project publishes. Before applying anything, read the guide for your exact product version together with every parent folder guide, then check the last push date of 2026-10-01 to see how current that guidance is for you.

Frequently asked questions

Official sources

1. ernw/hardening on GitHub
2. Issues
3. README