linux-baseline: the shared InSpec profile behind the DevSec hardening projects

A compliance profile, not a hardening cookbook

The DevSec Linux Baseline is an InSpec profile, and the distinction between a profile and a hardening project is the whole design. A hardening project applies settings. A compliance profile measures a system and reports whether it matches a standard. This repository is the second kind: the description calls it a compliance profile, and it exists to ensure that all hardening projects keep the same quality. Three sibling projects are named as the ones it governs, the puppet-os-hardening repository, the chef-os-hardening repository and the ansible-os-hardening repository. So the relationship is a shared contract. A rule that says a system should not have a writable home directory for other users means the same thing whichever configuration management tool you use to enforce it, and a profile that catches one implementation drifting away from the others is how you keep that from happening quietly.

Running it takes two commands

The standalone usage requires InSpec for execution, and there are two ways to invoke it. The first clones the repository and runs the profile from the local directory.

$ git clone https://github.com/dev-sec/linux-baseline
$ inspec exec linux-baseline

The second skips the clone entirely and points InSpec at the GitHub URL, which pulls the profile at run time.

$ inspec exec https://github.com/dev-sec/linux-baseline

That second form is the one worth remembering, because it means you can run the current published profile against a host from a laptop with nothing installed locally beyond InSpec itself. There is no packaging step, no gem to build and no configuration file to point at a control directory. The profile is a set of InSpec controls and the runner does the rest, reporting which controls passed and which did not.

The repository layout is the whole architecture

The top-level entries show a small Ruby project with a clear split. There is an inspec.yml, which is where an InSpec profile declares its metadata and its supported platform. There is a controls directory and a libraries directory, which is the standard InSpec arrangement where the controls are the individual checks and the libraries hold the shared helper code that those checks call into, since a hardening rule usually needs the same command-line probing logic in several places. There is a Gemfile and a Rakefile, so the project has a Ruby dependency set and task automation rather than being a purely declarative profile. Alongside those are a .rubocop.yml for the Ruby style rules, a CHANGELOG.md, a renovate.json for automated dependency updates, a .github directory for the workflows, and the LICENSE file. It is a repository you can read in an afternoon, which is part of why it works as a reference point.

The three hardening projects it arbitrates between

The reason a shared profile exists at all is that there is more than one reasonable way to harden a Linux system, and a lot of duplicated work. Puppet, Chef and Ansible each have their own idioms, their own configuration languages and their own community. If each project defined its own notion of a hardened server, a security auditor would have to learn three separate definitions, and a finding written against one would not transfer to the others. By making all three answer to the same profile, the profile becomes the shared language. The cost of that decision is that the profile cannot be expressive about the differences between the tools, so it necessarily encodes the intersection, the rules that make sense regardless of how the change is applied. That is also why the version numbers of the profile move in step with the hardening projects rather than independently.

Release history and how carefully this moves

The releases are version 2.11.0 published on 2026-09-17, 2.10.0 on 2026-05-26 and 2.9.0 on 2024-08-21, and the last push to the repository was on 2026-09-17, the same day as the latest tag. The gap between 2.9.0 and 2.10.0 is close to two years, while the gap between 2.10.0 and 2.11.0 is under four months, which is a release pattern that follows bursts of work rather than a calendar. For a baseline that three hardening projects test themselves against, that cadence is significant: a rule added to the standard only affects everyone once the profile is released, so the age of the release tells you how current the definition of hardened is. The CHANGELOG is the file to read to see what changed between versions, and the renovate configuration means the Ruby dependencies move on their own schedule whether or not the controls do.

The people behind it and the licence

The README names four authors. Patrick Muench, Dominik Richter, Christoph Hartmann and Edmund Haselwanter are listed as the authors of the profile, and the copyright line reads 2014-2021, The Hardening Framework Team. Those two facts together are worth pausing on. The team attribution and the 2014 start date place this in the early history of the hardening project ecosystem, before most of it had a name, and the copyright line ending in 2021 tells you the year the notice was last updated rather than the year the project stopped. The licensing is Apache License 2.0, with the standard notice reproduced in full in the README, including the clause about obtaining a copy of the licence at the Apache URL. Apache 2.0 is a permissive licence with an explicit patent grant, which is the usual choice for a reference implementation that other people are meant to build on.

Where a compliance profile is the wrong tool

Four limits apply. First, it measures and does not fix: a failing control tells you that the system differs from the baseline, and the remediation is whichever hardening project you have chosen, so running the profile without one of the three implementations gives you a report and no way to close the findings. Second, the baseline encodes an intersection rather than a maximum, so it will not tell you about a rule that only makes sense for one of the tools, and a hardened system can legitimately fail a control that does not apply to it. Third, the age of the release matters more than for most tools, because a baseline is a claim about the state of the art, and a two-year-old baseline may be checking for things that have since been superseded or missing things that have since become standard. And fourth, the profile needs a working InSpec and a way to reach the target host, which for a hardened system may itself be restricted, so the audit path has to be planned alongside the hardening.

Editorial conclusion

Use linux-baseline as the yardstick when you are adopting one of the DevSec hardening projects, because it is the shared definition of what correct hardening looks like and it can be run against any of them, or against a system directly, to see where the implementation and the standard diverge. Do not expect it to be a configuration tool, since it only measures and reports, and it does not tell you which of the three hardening projects to pick. Verify first which InSpec version your environment has, since the profile requires InSpec for execution, that you understand whether a failing control is a gap in the profile or in the target, and that you are on a release close to your target platform, because the release history shows a gap between 2.9.0 in 2024 and 2.10.0 in 2026 that suggests the profile only tracks what maintainers have had time to revisit.

Frequently asked questions

Official sources

1. dev-sec/linux-baseline on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases