Compliance Automation with OpenSCAP: Continuously Auditing Linux Servers

1. What OpenSCAP and the SCAP standard are

OpenSCAP is the reference implementation of the Security Content Automation Protocol, SCAP for short, a collection of standards from the American National Institute of Standards and Technology for machine readable descriptions of security requirements. Compliance automation with OpenSCAP concretely means a server is no longer checked manually against a PDF checklist, but automatically against an XML based profile that precisely defines what state counts as compliant.

The central building block for compliance automation is the SCAP Security Guide, SSG for short, a project maintained by Red Hat and the community that ships ready made profiles for CIS Benchmark, PCI-DSS, DISA STIG and further standards, each for the common distributions. Instead of translating every control manually into a custom script, you use a profile already tested and kept current by the community.

The advantage over purely manual checking lies in repeatability and traceability. An OpenSCAP scan delivers the same evaluation regardless of who runs it, with full traceability of which rule was checked and with what result. This property makes compliance automation with OpenSCAP the foundation of any audit that should go beyond a mere snapshot.

2. Installing the SCAP Security Guide and choosing profiles

The installation for compliance automation with OpenSCAP consists of two packages: the scanner itself and the content package with the actual profiles. After installation, the SCAP data streams reside as XML files on the system, from which individual profiles can be selected by their unique ID, for instance the CIS Level 1 Server profile or a PCI-DSS specific profile.

Important when selecting a profile for compliance automation is choosing one that exactly matches the distribution version in use. An SSG data stream for Debian 12 contains different rules and paths than one for Ubuntu 24.04, even if both distributions are structured similarly. A wrongly chosen profile leads to misleading failures on rules that do not even apply to the actual system.

#!/usr/bin/env bash
# Install OpenSCAP and SCAP Security Guide, list available profiles
set -euo pipefail

# Debian/Ubuntu
apt-get update
apt-get install -y openscap-scanner ssg-debian

# RHEL/Rocky Linux
# dnf install -y openscap-scanner scap-security-guide

# List all profiles available in the datastream for this distribution
oscap info /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml | grep -A1 "Profile"

3. Running the first scan with oscap

The first scan for compliance automation should always run in pure evaluation mode, without automatic correction. The command oscap xccdf eval with the --results and --report parameters produces a machine readable XML file and a human readable HTML report that lists every checked rule with a status of pass, fail, not applicable or error.

A frequently overlooked aspect of compliance automation with OpenSCAP is interpreting the "error" status. Unlike "fail", "error" means the rule could not be technically evaluated, for instance because a required command is missing or a path does not exist. These cases need manual follow up, since they cannot be automatically classified as compliant or non compliant.

#!/usr/bin/env bash
# Read-only compliance assessment against CIS Level 1 Server profile
set -euo pipefail

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /var/compliance/scap-results-$(date +%Y%m%d).xml \
  --report /var/compliance/scap-report-$(date +%Y%m%d).html \
  /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml

echo "Scan complete, exit code reflects overall compliance status"
echo "0 = all rules passed, 2 = at least one rule failed"

4. Generating and applying remediation scripts automatically

The core advantage of compliance automation with OpenSCAP over purely manual assessment is the ability to generate a directly executable remediation script from any failed rule set. The command oscap xccdf generate fix produces either a bash script or an Ansible playbook that addresses exactly the failed controls, without touching settings that are already compliant.

Despite this automation, the same caution applies to compliance automation as to any hardening measure: generated remediation scripts belong in a staging environment first, not directly on a production system. Some remediation rules, such as disabling certain kernel modules, can impair functionality that is actually needed in the specific deployment context.

#!/usr/bin/env bash
# Generate an Ansible remediation playbook from failed rules, review before applying
set -euo pipefail

RESULTS="/var/compliance/scap-results-$(date +%Y%m%d).xml"

# Generate Ansible playbook fixing only the failed controls
oscap xccdf generate fix \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --fix-type ansible \
  --output remediation-playbook.yml \
  "$RESULTS"

echo "Review remediation-playbook.yml before applying to any host"
echo "Recommended workflow: test in staging, then:"
echo "ansible-playbook remediation-playbook.yml -i inventory --limit staging --check"

5. Evaluating results as HTML and XML reports

Two output formats are relevant for compliance automation, each with a different purpose. The HTML report is meant for humans, with color coded results, control descriptions and a remediation hint per rule, ideal for a manual review meeting or an auditor handout. The XML results file is meant for further processing by tooling, for instance to feed a trend over time into a central dashboard.

An important metric during evaluation is the scoring percentage OpenSCAP calculates from the ratio of pass to fail. This number alone, however, is only a rough orientation for compliance automation. More decisive is the list of specifically failed controls with their respective criticality, because a single highly critical failure weighs heavier than ten low priority failures combined.

6. Integrating OpenSCAP into Ansible pipelines

Sustainable compliance automation integrates the OpenSCAP scan as a fixed step in the deployment pipeline, not as an isolated, manually triggered action. After every Ansible playbook run that changes system configuration, a scan should automatically follow, checking whether the change accidentally violated a control from the chosen profile.

# ansible/playbooks/deploy-with-compliance-gate.yml
# Configuration deployment followed by an automated OpenSCAP compliance gate

- name: Apply application configuration changes
  hosts: webservers
  roles:
    - php_fpm_config
    - nginx_vhost_config

- name: Run OpenSCAP compliance check after configuration changes
  hosts: webservers
  tasks:
    - name: Execute compliance scan
      command: >
        oscap xccdf eval
        --profile xccdf_org.ssgproject.content_profile_cis_level1_server
        --results /var/compliance/scap-results-{{ ansible_date_time.date }}.xml
        /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml
      register: scan_result
      failed_when: scan_result.rc == 1

    - name: Fail pipeline if compliance evaluation errored
      fail:
        msg: "OpenSCAP evaluation encountered an error, review before proceeding"
      when: scan_result.rc == 1

7. Continuous Compliance with oscapd and scheduling

For fully automated, recurring compliance automation without an external pipeline, oscapd is a good fit, a daemon that runs scheduled scans directly on the target system and provides results centrally via a defined interface. Alternatively, for smaller environments, a systemd timer that regularly runs oscap xccdf eval and forwards results to a central log or monitoring system is sufficient.

Decisive for real compliance automation is that results are not only produced but also actively monitored. A sensible escalation rule is to immediately trigger a notification for newly appeared failures not present in the previous scan, instead of waiting for the next scheduled manual review.

8. Adjusting custom profiles and tailoring

Standard profiles from the SCAP Security Guide rarely fit every real environment one hundred percent. For compliance automation that must also account for organization specific exceptions, OpenSCAP offers the concept of tailoring: a separate XML file references the base profile and overrides individual rules, for instance to mark a particular control as not applicable, with a documented rationale in the tailoring file itself.

{
  "tailoring_metadata": {
    "base_profile": "xccdf_org.ssgproject.content_profile_cis_level1_server",
    "organization": "Mironsoft Hosting Fleet",
    "created": "2026-07-30",
    "excluded_rules": [
      {
        "rule_id": "xccdf_org.ssgproject.content_rule_partition_for_var_tmp",
        "reason": "Fixed disk layout from provider image, repartitioning risks downtime",
        "compensating_control": "noexec,nosuid mount options applied to /var/tmp instead",
        "approved_by": "ops-lead",
        "review_date": "2026-10-30"
      }
    ]
  }
}

This documented exception remains part of compliance automation, but is clearly distinguished from an actual assessment failure. A tailoring file should, like any other configuration, be versioned and distributed via the same Ansible pipeline as the base profile itself.

9. OpenSCAP compared to other compliance tools

The table below places OpenSCAP relative to other common tools for compliance automation on Linux.

OpenSCAP is thus the only open source solution that delivers both standardized assessment and automatically generated remediation from a single compliance automation source, without license costs or dependency on an external vendor.

10. Summary

Compliance automation with OpenSCAP replaces manual checklists with repeatable, machine readable scans against recognized SCAP profiles from the SCAP Security Guide. The process covers profile selection matching the distribution, an initial purely evaluative scan, automatically generated remediation scripts tested in staging, and evaluation of HTML and XML reports with a focus on critical failures rather than the raw percentage.

Compliance automation only becomes sustainable through integration into deployment pipelines or a dedicated daemon such as oscapd, complemented by documented tailoring for organization specific exceptions. Anyone establishing this cycle turns compliance from a one time audit preparation into an ongoing, observable operational state.

11. FAQ: Compliance Automation with OpenSCAP