Lynis Integration with DefectDojo

Lynis Integration with DefectDojo

Lynis is an open source security auditing tool for Linux, macOS, and other Unix-based systems, developed by CISOfy. It runs on the host it audits and checks areas such as kernel settings, authentication, logging, installed packages, and file permissions. Alongside its human-readable log, Lynis writes a machine-readable lynis-report.dat file of key and value pairs, and that file is what DefectDojo imports.

Lynis Integration with DefectDojo

We run Lynis on our Linux fleet because it is quick, needs no agent infrastructure, and gives a sensible hardening baseline. The problem was what happened afterwards: each host produced its own report, and nobody tracked whether last month's warnings were ever fixed. Importing lynis-report.dat into DefectDojo gives every warning and suggestion a Finding on the right Asset, carries the hostname and hardening index into each one, and lets a reimport close out items that a later audit no longer reports.

Why Lynis Matters

Host configuration drifts. Packages get installed for a debugging session, SSH settings are relaxed for a migration, and logging is turned down to save disk. Lynis checks for that kind of drift directly on the machine.

• It audits a live system, so it sees the configuration actually in effect rather than what a template says should be there.
• Each result carries a Lynis test ID (for example KRNL-5820), which makes it easy to look up what was checked and why.
• Results come with a suggested solution when Lynis has one, which gives the system owner a starting point.
• A single report describes a single host. Without a central place to collect them, comparing a fleet of servers means opening one file per machine.

Advantages of This Integration

Running Lynis results through DefectDojo gave us:

• Per-host context on every Finding. The parser copies the report's hostname, operating system, Lynis version, and hardening index into each Finding's description, so findings from different machines stay distinguishable after import.
• A clear severity split. Lynis warnings import as Medium and suggestions as Low, which lets SLA rules treat "something is wrong" differently from "this could be hardened further".
• Lifecycle on reimport. Reimporting the next audit for the same host into the same Test mitigates items that were fixed, adds new ones, and reactivates any that regressed.
• Deduplication across audits. DefectDojo hashes Lynis findings on title, CWE, line, file path, and description. Since Lynis findings have no file or line, the test text and the description (which includes the test ID and host details) do the work, so repeat audits of an unchanged host match cleanly.
• Accepted exceptions that expire. Some suggestions do not fit a given server's role. Risk acceptance with an expiration date records that decision and brings it back for review later.
• Assignment and ticketing. Findings can be assigned to the team that owns the host or pushed to Jira, so hardening work lands where infrastructure teams already plan.

How This Integration Works

DefectDojo reads Lynis reports with the Lynis Scan scan type.

1. Run an audit and collect the report. Lynis needs root to reach most of what it checks:

sudo lynis audit system --quick --no-colors

The machine-readable report is written to /var/log/lynis-report.dat by default. Lynis audits the machine it runs on, so running it inside a container audits the container, not the underlying host.

2. Import the .dat file. In the UI, open the Engagement, choose Import Scan Results, select Lynis Scan, and upload the file. For automation, the API is available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Lynis Scan" 
  -F "file=@lynis-report.dat" 
  -F "product_name=web-tier" 
  -F "engagement_name=Host Hardening" 
  -F "test_title=web-01" 
  -F "auto_create_context=true"

In DefectDojo Pro, Universal Importer does the same from a script or scheduled job:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Lynis Scan" 
  --report-path "./lynis-report.dat" 
  --product-name "web-tier" 
  --engagement-name "Host Hardening" 
  --auto-create-context

3. Reimport per host. Keep one Test per host and send later audits to /api/v2/reimport-scan/, so each machine's history stays continuous.

The parser looks for the repeated warning[] and suggestion[] keys. Each value is pipe-delimited as test ID, text, details, and solution, and a bare - is treated as an empty field. Text that itself contains a pipe is kept intact.

Data Granularity: What Gets Imported

The hardening index grades the host as a whole, not individual results, so it appears in the description rather than affecting severity.

Use Cases

For fleet hardening: An infrastructure team runs Lynis weekly from configuration management on every Linux server and reimports each host's report into its own Test. The Asset view shows which hosts still carry open warnings and how long they have been open.

When building golden images: Before a new base image is approved, Lynis runs against a test instance built from it. The import shows exactly which suggestions the image resolves and which it still leaves, which gives reviewers a concrete list instead of a single hardening score.

During an audit: Hardening findings in DefectDojo keep their discovery date, status changes, and risk acceptance notes. An auditor asking how server configuration issues are tracked can see the history directly.

After an incident: If a host is rebuilt after an incident, comparing its new Lynis import with the previous Test shows whether the rebuilt configuration actually closed the gaps found before.

Operational Tips

• Name each Test after the host (for example with test_title) and reimport into it. Importing every audit as a new Test still works, but you lose the per-host open-to-mitigated history.
• Lynis raises a suggestion about its own version once the installed release ages. Update Lynis on your hosts, or mark that Finding as accepted, so it does not sit in every report.
• If the volume of Low suggestions is too high at first, import with minimum_severity=Medium to focus on warnings, then lower it once the warnings are under control.
• Always run Lynis as root. A non-root run skips checks, and the missing checks look like an improvement after reimport.
• The report's timestamps are not copied into Findings, but the hardening index and Lynis version are, and the description is part of the hash. When a fix moves the hardening index or you upgrade Lynis, expect that host's remaining findings to reimport as new and the previous ones to be mitigated. Plan Lynis upgrades across the fleet at once so the churn happens in one cycle.
• Tag imports with the environment or role (for example tags=production,web) so SLA reports can be filtered by tier.