Lynis: an agentless security audit for Linux, macOS and BSD

The problem Lynis solves, and who is asking

A Linux host accumulates drift. A service gets enabled, a file mode changes, a package falls behind, an SSH option gets relaxed during an incident and never reverted. Nothing breaks, so nothing alerts. Lynis is built for that gap: it runs on the system itself, inspects the running configuration, and produces a list of findings with hardening suggestions attached. The README describes it as an in-depth security scan whose primary goal is to test security defenses and provide tips for further system hardening.

The audience named in the README is system administrators, auditors, security officers and penetration testers. That group matters because it explains the output style. Lynis does not decide whether a finding is acceptable in your environment. It reports what it observed and what it suggests, and the judgement stays with the operator or the auditor. If you want a tool that makes the decision for you, this is not it.

It is also explicitly agentless and, per the repository description, installation is optional. The git route needs no compilation and no installation step, which is unusual for a scanner of this scope and is the main reason it appears on machines where you cannot deploy an agent.

How the scan actually works

Lynis is a shell program. The repository root contains an executable named lynis, a directory of include files, a db directory, a plugins directory, and two profile files, default.prf and developer.prf. The database and profile files are what shape a run: the profile controls behaviour and the database supplies the reference data the tests check against. There is no daemon, no network listener and no server component in the GPL version.

Because it executes on the host, the scan sees what a local process sees: file permissions, service state, kernel settings, installed packages, and the configuration of whatever the tests know how to read. That is the trade-off. A local scanner catches host-level drift that an external network scan cannot see, and it misses anything that requires traffic inspection or a second vantage point. The README lists both vulnerability detection and configuration and asset management among the goals, which are host-side concerns.

Reports are written to the filesystem. The README does not document a remote reporting endpoint or an API for shipping results to a central store, so the aggregation story is left to the operator. That is the single biggest architectural constraint to plan around.

One operational detail from the README is worth repeating because it trips people up: if you run the tool as root or via sudo from a git clone, the project suggests changing ownership of the files with chown -R 0:0, otherwise Lynis warns about file permissions, since you are executing files owned by a non-privileged user.

Installing Lynis and running a first audit

The README calls the software package the preferred method, because it is quick to install and easy to update. CISOfy publishes RPM and DEB packages for CentOS, Debian, Fedora, OEL, openSUSE, RHEL, Ubuntu and others at packages.cisofy.com, and some distributions carry Lynis in their own repositories. The README adds a caveat: some distributions do not provide an up-to-date version, in which case it is better to use the CISOfy repository, the tarball from the website, or the latest GitHub release. Check your distribution's version before trusting it.

If you want the newest code, the git route is the shortest path. The README states that no compilation or installation is required:

git clone https://github.com/CISOfy/lynis
cd lynis && ./lynis audit system

Running that command starts a system audit of the machine you are on. You should see the scan progress through its test groups and finish with a report summary in the terminal, plus report files left on disk for later reading. Expect the run to take a few minutes on a normal host.

If you intend to run it as root or through sudo, the README suggests fixing ownership first so the permission warning does not appear:

chown -R 0:0

Apply it to the cloned files, which is what the README's chown -R 0:0 instruction is for. This changes the owner and group of those files to user ID 0, which is what the tool expects when it is executed with elevated privileges.

Where Lynis stops being the right tool

The most important limitation is one the README states indirectly rather than as a warning. The enterprise version is described as the same quality with more functionality, and the differences listed are a web interface, dashboard and reporting, hardening snippets, a risk-based improvement plan, and commercial support. Read that list backwards and you have the GPL edition's boundaries: no console, no dashboard, no cross-host reporting, no vendor support contract. If your requirement is a single pane of glass across two hundred servers, the open source tool is the wrong layer and you will be building that layer yourself.

A second boundary is scope. Lynis inspects the host. It does not watch network traffic, and the README does not present it as a runtime intrusion detection system, even though intrusion detection appears in its list of assisted areas. Treat a clean report as evidence about configuration at a point in time, not as evidence that nothing happened since.

Third, findings require interpretation. Because the output is suggestions, a large finding count is not automatically bad and a small one is not automatically good. On a hardened appliance with an unusual configuration, you will get findings that are correct observations and wrong recommendations for your setup. Suppressing or accepting them is manual work, and the README does not document a rollback or an automated remediation path.

Lynis compared with configuration management scanners

The natural alternative for the same job is a configuration compliance scanner that works from a declarative policy, such as OpenSCAP with a SCAP security guide profile. The difference in approach is real, not cosmetic. OpenSCAP evaluates the machine against a machine-readable policy and returns pass or fail per rule, which makes it straightforward to gate a build or a deployment on a defined baseline. Lynis inverts that: it explores the host, reports what it finds, and attaches hardening advice, leaving the pass or fail judgement to a human.

That inversion is why Lynis suits auditors and penetration testers. An auditor wants a broad picture of a system and a list of things to discuss, not a boolean against a policy someone else wrote. A compliance engineer who needs a deterministic, versioned baseline for CI wants the opposite, and a policy-driven scanner will fit better there. The two are not mutually exclusive, and running both is a common pattern: one for the baseline gate, one for the wider sweep.

A second alternative, for teams already deep in a configuration management system, is writing host checks as your own modules. The README points to the Lynis software development kit for creating your own tests, which is the project's own answer to the gap between its built-in checks and your environment.

Maintenance, upgrades and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-16, days before this writing. Release cadence is visible in the tags: 3.1.5 in July 2025, 3.1.6 in October 2025, and 3.1.7 in June 2026. That is roughly a release every six to nine months, with commits landing between them. For a security tool, that cadence is the thing to weigh: a test that no longer matches a modern distribution is worse than no test, because it produces confident noise.

Upgrade cost depends on how you installed it. A package from the CISOfy repository or from your distribution is the low-effort path and the README's stated preference. A git clone is the opposite: you get the newest code, but you own the update process, and if you applied the chown -R 0:0 step you also need to think about how you pull changes into a root-owned working copy. Neither route requires compilation, which keeps the upgrade itself cheap.

On licensing, Lynis is GPL-3.0. That is a copyleft licence, and it matters if you plan to redistribute Lynis inside a product or modify it and ship the result. Internal use on your own hosts is the ordinary case and does not raise the same questions. If you intend to embed or redistribute it, have someone qualified read the licence text rather than relying on a summary, including this one.

Editorial conclusion

Adopt Lynis if you administer individual Linux, macOS or BSD hosts and want a repeatable hardening report you can diff between runs, or if you need host-level evidence for ISO27001, PCI DSS or HIPAA work and are willing to map findings yourself. Do not adopt it as a fleet-wide continuous monitor: it is a local scanner with no central console in the GPL version, and the enterprise edition is the one that adds a web interface, dashboard and reporting. Before committing, verify that your distribution's package is current enough, since the README warns that some repositories ship outdated versions, and confirm in your own test that the scan's findings map to the controls your auditor actually asks about.

Frequently asked questions

Official sources

1. CISOfy/lynis on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases