🧰 OpenSCAP, USG and Lynis

OpenSCAP, USG and Lynis: checking a Linux server against CIS, PCI DSS, HIPAA and STIG
Tools: OpenSCAP (oscap) on the Red Hat family      Ubuntu Security Guide (usg) on Ubuntu      Lynis on anything      CIS-CAT (CIS's own assessor)

The compliance sheets on this tab tell you WHAT a framework wants. These tools check a real machine against a written baseline and tell you which rules pass and fail, and (with care) can fix them. This sheet shows the commands, the safe workflow and the traps.
Commands and profile names were checked against Red Hat's RHEL 9 compliance documentation and Ubuntu's USG documentation on 2026-09-29. Run everything on a test machine first: automated fixes change the system, and Red Hat states plainly that it provides no automated way to undo them.

Red Hat / RHEL / Rocky / AlmaLinux:  OpenSCAP + scap-security-guide (SSG). Free, in the standard repositories. Profiles for CIS, PCI DSS, HIPAA, STIG, OSPP, CUI and more.
Ubuntu:                              Ubuntu Security Guide (usg). Needs Ubuntu Pro (Canonical says Pro is free for personal use on up to five machines). Profiles for CIS levels and DISA STIG.
Any Linux:                           Lynis: a quick, free audit with a hardening score and suggestions. Not a formal framework scan.
CIS itself:                          CIS-CAT Lite is CIS's free assessor (limited benchmarks); CIS-CAT Pro and machine-readable content are for CIS SecureSuite members. Check CIS's current terms.

Install:
   sudo dnf install openscap-scanner scap-security-guide bzip2
The SCAP content for RHEL 9 lives at:
   /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml           (RHEL 8: ssg-rhel8-ds.xml   RHEL 10: ssg-rhel10-ds.xml)
List the profiles inside it and read one:
   oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
   oscap info --profile <profileID> /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Profile IDs Red Hat lists include: cis, hipaa, pci-dss, stig, ospp, e8 (Essential Eight) and cui (NIST SP 800-171 for controlled unclassified information).
Scan and get an HTML report (nothing is changed):
   sudo oscap xccdf eval --profile cis --results scan-results.xml --report scan-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
   # then open scan-report.html in a browser: pass, fail, notapplicable, notchecked and error are shown per rule
Scan for known vulnerabilities (a different job: it uses Red Hat's OVAL security data):
   wget -O - https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2 | bzip2 --decompress > rhel-9.oval.xml
   oscap oval eval --report vulnerability.html rhel-9.oval.xml
Fixing what failed. Red Hat's WARNING: "If not used carefully, running the system evaluation with the Remediate option enabled might render the system non-functional. Red Hat does not provide any automated method to revert changes made by security-hardening remediations." So prefer generating a script you can READ first:
   sudo oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
   sudo oscap xccdf generate fix --fix-type bash --result-id <resultID> --output hipaa-remediations.sh hipaa-results.xml        # a bash script of the fixes
   sudo oscap xccdf generate fix --fix-type ansible --result-id <resultID> --output remediations.yml hipaa-results.xml        # or an Ansible playbook
   sudo oscap xccdf eval --profile <profileID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml                    # scan AND fix in one go (test machines only!)
Red Hat's other cautions: test on non-production first, back up first, and note that remediation targets DEFAULT RHEL configurations (a customised system may still not pass afterwards). A common way to avoid the problem on new servers is to apply the security profile at install time (kickstart) instead of fixing an already-tuned system.
Find <resultID> inside the results XML (it looks like xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_hipaa).

Enable and install (Ubuntu Pro required):
   sudo pro attach <your-token>                               # once, from ubuntu.com/pro
   sudo pro enable usg
   sudo apt install usg
Profiles for Ubuntu 24.04 (CIS): cis_level1_server, cis_level2_server, cis_level1_workstation, cis_level2_workstation. The STIG profile is disa_stig.
Audit (reports only):
   sudo usg audit cis_level1_server
   # reports are written automatically to /var/lib/usg/ as HTML and XML
Fix (changes the system: test machine first, with a snapshot):
   sudo usg fix cis_level1_server
Tailor the profile (drop rules that do not fit, adjust rules that have options), then audit or fix with your version:
   sudo usg generate-tailoring cis_level1_server tailoringfile.xml
   sudo usg audit --tailoring-file tailoringfile.xml
More detail:  man usg-cis      (the version of the CIS benchmark that YOUR usg package implements is documented there; it can be older than the newest CIS release)
STIG audit:   sudo usg audit disa_stig      (on 22.04 the usg package must be a recent enough version)

   sudo apt install lynis                                      # Ubuntu.   RHEL family: sudo dnf install lynis   (from EPEL)
   sudo lynis audit system
   # results: a hardening index, warnings, suggestions. Details go to /var/log/lynis.log and /var/log/lynis-report.dat
Lynis is a quick sanity check and a good way to find things nobody thought of. It is not the same as passing a CIS or STIG scan, so use it alongside, not instead.

   1. Baseline: run an AUDIT on the current machine and save the report. This is your "before".
   2. Read the failures. For each one decide: fix it, tailor it out with a written reason, or accept the risk with a written approval.
   3. Fix on a test copy (or generate a script and review it line by line). Snapshot first.
   4. Test the application, logins, backups and monitoring on that copy.
   5. Roll out to production in small groups. Keep console access.
   6. Re-audit and save the "after" report.
   7. Schedule a scan (weekly or monthly, and after every big change) and keep the reports: they are audit evidence.
Bake the fixes into your build (image, Ansible, cloud-init) so new servers start hardened and old ones do not drift.

   pass / fail          The rule was checked and met / not met.
   notapplicable        The rule does not apply to this system (for example a workstation-only rule on a server).
   notchecked / error   The tool could not decide. Check by hand. Running without sudo causes a lot of these.
   informational        Nothing to fix, just a note.
A score of 100% is not the goal. The goal is "every failure is either fixed or a documented, approved exception".

"oscap says the profile does not exist": profile IDs differ per distribution and version. List them with oscap info on the exact data-stream file for your release.
"Everything fails on my hand-tuned server": remediation assumes a default install. Scan first, fix what makes sense, tailor the rest.
"The scan is slow": full-file-system checks can take a while. Run it off-hours and never in the middle of a backup.
"A remediation broke SSH or a service": you did not have a console open, or you skipped the test machine. Restore the snapshot, then generate the fix script and remove the rule that hurt before re-running.
"usg says I need Ubuntu Pro": USG is part of Pro. Attach with pro attach, then pro enable usg.
"The report and the benchmark version do not match": the tool ships its own profile version. Compare against the benchmark version it says it implements, not the newest one on the CIS website.
"After the fix the HIPAA or PCI profile still fails some rules": no profile can cover policies, people and procedures. It only checks the system settings it can see.

Keep the results XML as well as the HTML: it is the machine-readable evidence and can be re-rendered later.
Compare "before" and "after" reports in a change ticket. Auditors love a change ticket with two attachments.
Re-scan after big updates: patches sometimes reset settings.
Treat automated remediation like any other code change: reviewed, tested, and reversible in your own process (snapshots, version control), since the tools will not undo it for you.
Trust, but verify: a green report tells you the checks passed, not that the checks were the right ones.

Red Hat, Scanning the system for configuration compliance (RHEL 9):   https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/scanning-the-system-for-configuration-compliance-and-vulnerabilities_security-hardening
Ubuntu, CIS compliance with USG:                                       https://ubuntu.com/security/certifications/docs/usg/cis
Ubuntu, USG for CIS on 24.04 (commands and profiles):                  https://ubuntu.com/blog/hardening-automation-for-cis-benchmarks-now-available-for-ubuntu-24-04-lts
CIS Benchmarks and tools:                                              https://www.cisecurity.org/cis-benchmarks