← Back to DevBytes
Developer Tutorial July 15, 2026 10 min read

Lynis: Setup, Configuration, and Best Practices

What is Lynis and Why It Matters

Lynis is an open-source security auditing and compliance tool for Unix-based systems including Linux, macOS, and BSD derivatives. It performs an in-depth system scan, checking for vulnerabilities, misconfigurations, outdated software, and general security weaknesses. Unlike traditional vulnerability scanners that focus on network services, Lynis dives deep into the local host configuration: file permissions, kernel parameters, authentication mechanisms, installed packages, and more.

Why does it matter? Security hardening is not a one-time effort; it’s a continuous process. Lynis gives developers and system administrators a consistent, repeatable way to measure the security posture of a machine, detect drift from baselines, and receive actionable recommendations. It supports compliance frameworks such as PCI DSS, HIPAA, ISO 27001, and CIS Benchmarks out of the box. By integrating Lynis into development workflows, you shift security left, catching misconfigurations before they hit production.

Installation and Setup

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Lynis is a shell script with a modular plugin architecture, so installation is straightforward. You can install it via a package manager, clone the Git repository, or run it directly from a tarball. The only hard requirement is that you run it with root privileges to access all system areas.

Installing via Package Managers

# Ubuntu / Debian
sudo apt update
sudo apt install lynis

# CentOS / RHEL (requires EPEL)
sudo yum install epel-release
sudo yum install lynis

# Fedora
sudo dnf install lynis

# macOS (Homebrew)
brew install lynis

Installing from Source (Latest Version)

The package manager versions often lag behind. For the latest tests and features, clone the official GitHub repository and run Lynis directly from the checkout directory. 

git clone https://github.com/CISOfy/lynis.git
cd lynis
# Run the audit directly (no install needed)
sudo ./lynis audit system

To make it system-wide, you can copy the lynis script and the include/ and plugins/ directories to /usr/local/, but running from the cloned directory is perfectly fine for CI/CD environments and workstations.

Quick Setup Validation

After installation, verify that Lynis works and displays its version: 

lynis --version
# or from source
./lynis --version

No additional configuration is required to get started. Lynis will use sensible defaults and its built-in profiles. However, we'll cover customization later to make it fit your exact needs.

Running Your First Audit

The core command is lynis audit system. It launches a comprehensive scan covering file systems, boot loader, kernel, memory and processes, users and groups, authentication, shells, file permissions, software packages, networking, logging, and more. The scan runs interactively and prints color-coded results directly to the terminal. 

# Standard full system audit
sudo lynis audit system

Lynis supports a variety of command-line flags that are essential for automation and tailored runs. Here are the most important ones: 

# Full audit with custom report path and auditor identity
sudo lynis audit system --auditor "DevOpsTeam" --report-file /var/log/lynis/scan-$(date +%F).dat

# Quick, non-interactive scan for cron or CI
sudo lynis audit system --cronjob --quiet --no-colors

Running Specific Test Groups

For targeted checks or debugging, you can run individual test IDs or test groups: 

# Run only file integrity tests
sudo lynis audit tests test_file_integrity

# Run the authentication group
sudo lynis audit tests group_authentication

You can find all available test IDs and groups inside the include/ directory or by browsing the official documentation. This is extremely useful when you want to verify a particular remediation without executing the full suite.

Understanding the Output

Lynis output is designed to be immediately actionable. During an interactive run, you’ll see a live status with color indicators:

At the end of the scan, Lynis displays a summary including the hardening index (a numeric score that reflects overall security posture) and the number of warnings and suggestions found. A higher index means a stronger system; many teams set a minimum threshold (e.g., 70) that must be met in CI/CD gates.

Report Files and Logs

Lynis generates two key files:

To view past reports interactively, use the show subcommands: 

# List all stored reports
sudo lynis show reports

# Display details of a specific report
sudo lynis show details /var/log/lynis-report.dat

# Show only warnings from a report
sudo lynis show warnings /var/log/lynis-report.dat

# Show hardening index and score breakdown
sudo lynis show hardening /var/log/lynis-report.dat

Understanding this output is critical for remediation. Each warning or suggestion includes a test ID (like FILE-6310 or AUTH-9328) and a short description. You can look up these IDs in the Lynis documentation or within the include/ test files to see exactly what the check does and how to fix the underlying issue.

Configuration and Customization

While Lynis works out of the box, real‑world environments often require tuning to eliminate noise, skip irrelevant checks, or add custom tests. Lynis uses a profile system to control behaviour. The default profile is default.prf, located in /etc/lynis/ (or within the source tree’s include/ directory).

Creating and Using Custom Profiles

A profile is a simple configuration file where you can enable/disable tests, set custom paths, and adjust severity thresholds. You reference it with the --profile flag: 

sudo lynis audit system --profile /etc/lynis/custom.prf

Here’s an example profile that skips certain noisy tests, adjusts a config path, and enables verbose logging:

# /etc/lynis/custom.prf

# Skip outdated kernel checks (often false positives in containers)
skip-test=KRNL-5788
skip-test=KRNL-6000

# Ignore checks for specific software we intentionally remove
skip-test=PKGS-7384

# Use a custom configuration directory for tests
config=/opt/security/lynis/config

# Enable verbose output for deeper investigation
verbose=yes

# Set a custom hardening index baseline
hardening-threshold=75

The skip-test directive is the most common customization. You can find the exact test IDs from previous reports. Documenting why a test is skipped (in a comment or a companion document) is a best practice for auditors and team transparency.

Custom Tests and Plugins

Lynis is extensible. You can write your own test scripts and place them in a directory (e.g., /etc/lynis/include/). The profile can then include them with the include= directive or by placing them in the search path. Each test is a shell snippet that follows a simple convention: it defines a test ID, runs checks, and calls ExitFatal, ExitWarning, or ExitOk. This allows you to enforce organization‑specific policies (e.g., “ensure our internal CA is installed”, “check that no legacy TLS 1.0 endpoints exist in our service file”).

Integrating Lynis into CI/CD Pipelines

For DevSecOps workflows, Lynis can run as a gate in your CI/CD pipeline. The goal is to scan a build artifact (a container image, a VM snapshot, or a staging environment) and fail the pipeline if the security posture is below an acceptable threshold or if critical warnings appear.

Generating Machine‑Readable Output

Lynis supports JSON output natively, making it easy to parse in scripts: 

# Generate a JSON report (non‑interactive)
sudo lynis audit system --cronjob --quiet --json --report-file /tmp/lynis-report.json

The JSON file contains structured data: metadata, hardening index, warnings, suggestions, and test results. You can then use a tool like jq to extract key metrics.

Example Pipeline Gate Script

Below is a typical shell script that runs Lynis inside a CI job (e.g., Jenkins, GitLab CI, GitHub Actions). It executes the audit, then checks the hardening index and counts warnings. If conditions aren’t met, it exits with a non‑zero status, failing the pipeline. 

#!/bin/bash
# Halt on any error
set -e

# Run Lynis audit on the system / container
lynis audit system --cronjob --quiet --json --report-file /tmp/lynis-report.json

# Parse the hardening index (assume JSON key: hardening_index)
HARDENING_INDEX=$(jq '.hardening_index' /tmp/lynis-report.json)
echo "Hardening Index: $HARDENING_INDEX"

# Fail if index below 70 (adjust to your policy)
if [ $(echo "$HARDENING_INDEX < 70" | bc) -ne 0 ]; then
  echo "FAIL: Hardening index too low ($HARDENING_INDEX)."
  exit 1
fi

# Count warnings (assume JSON key: warnings is an array)
WARNING_COUNT=$(jq '.warnings | length' /tmp/lynis-report.json)
echo "Warnings found: $WARNING_COUNT"

# Fail if any warning is present (strict policy)
if [ "$WARNING_COUNT" -gt 0 ]; then
  echo "FAIL: $WARNING_COUNT warnings detected."
  exit 1
fi

echo "Lynis security gate passed."

Important: The exact JSON schema may vary slightly between Lynis versions. Always inspect a sample report first (jq 'keys' report.json) to confirm the field names. You can also fall back to parsing the .dat report with grep/awk if JSON is not available.

Container‑Specific Considerations

When scanning containers, some checks (like kernel parameters or boot loader) may be irrelevant or fail because the container shares the host kernel. Use a custom profile to skip those tests: 

sudo lynis audit system --cronjob --quiet --json --profile /etc/lynis/container.prf

A container profile typically disables kernel, boot, and hardware‑related tests, focusing on users, packages, file permissions, and network configuration inside the container.

Best Practices

Conclusion

Lynis is a lightweight, powerful, and extensible security auditing tool that every developer and operator should have in their toolbox. It bridges the gap between “security is someone else’s problem” and “security is built into every commit.” By starting with a simple sudo lynis audit system, you gain immediate visibility into your system’s weaknesses. Through custom profiles, JSON output, and CI integration, Lynis becomes an automated gate that prevents insecure configurations from moving down the pipeline. Following the best practices outlined here—regular scanning, systematic remediation, threshold enforcement, and continuous updating—you transform Lynis from a one‑off audit tool into a living, breathing part of your DevSecOps lifecycle. Start today, and watch your hardening index climb.

🚀 Need a reliable AI agent for your project?

Deploy Hermes Agent in 10 minutes. Managed hosting, zero DevOps.

Get Started — $23.99/mo
← Back to all articles