Goal of this guide

This part closes the technical SUSE Multi-Linux Manager series with compliance and OpenSCAP. You learn how to audit managed Linux systems against security profiles, review results and plan remediation responsibly.

The examples use mlm01.example.test as a documented placeholder for the real Manager FQDN. Replace it with your production Manager name.

Complete series path

This series guides you step by step through production deployment: 1. Install SLES 16 for production · 2. Install SUSE Multi-Linux Manager 5.2 · 3. Onboard first Linux clients · 4. Patch and lifecycle management · 5. Manage mixed Linux · 6. OpenSCAP, compliance and audit · 7. Build proxies for sites · 8. Integrate SSO with Keycloak · 9. Use Ansible next to Salt · 10. Reporting, inventory and audit · 11. Operate and harden in production

SUSE series: part 6

  • Part 1: install SLES 16 in production
  • Part 2: install SUSE Multi-Linux Manager 5.2
  • Part 3: onboard first Linux clients
  • Part 4: patch and lifecycle management
  • Part 5: manage mixed Linux
  • Part 6: compliance and OpenSCAP audits
  • Part 7: reporting and subscription audit
  • Part 8: harden operations
https://mlm01.example.test

What OpenSCAP provides in Manager

OpenSCAP checks systems against machine-readable security profiles. SUSE Multi-Linux Manager can schedule scans for clients, display results centrally and make them usable as audit evidence. It does not replace manual security review, but gives you repeatable technical checkpoints.

  • CVE Audit shows which systems are relevant for known vulnerabilities.
  • OpenSCAP evaluates configuration against profiles such as standard, STIG, PCI-DSS or distribution-specific community profiles.
  • Scan results belong in a remediation process, not in blind automatic changes.

Prepare clients

A client must work as a Salt system, have enough resources and provide the required OpenSCAP scanner packages and SCAP content. Plan at least 2 GB RAM for modern clients because profiles and reports are evaluated on the client.

bash
zypper install openscap-utils scap-security-guide
rpm -ql scap-security-guide | grep ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

For RHEL-compatible systems such as Rocky Linux, AlmaLinux or Oracle Linux you typically use openscap-utils and scap-security-guide-redhat from matching channels. Debian 13 and Ubuntu 24.04 LTS can be scanned technically, but require community SCAP content and must be assessed differently from the SUSE/RHEL-compatible standard path.

bash
dnf install openscap-utils scap-security-guide-redhat
rpm -ql scap-security-guide-redhat | grep ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
bash
apt update
apt install openscap-scanner ssg-debian
dpkg -L ssg-debian | grep ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-debian13-ds.xml

Schedule a scan from the Web UI

Open the client in the Web UI through Systems -> System List -> All, go to the system details and open the Audit tab. In the Schedule subtab provide the XCCDF path and profile. The scan runs at the next client check-in or scheduled action.

bash
/usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
https://mlm01.example.test

Review results

Central evaluation is available under Audit -> OpenSCAP -> All Scans. Check target system, profile, timestamp, result and detailed report. For audits, results must be reproducible, versioned and connected to a remediation decision.

bash
spacewalk-report system-history-scap
spacewalk-report scap-scan
spacewalk-report scap-scan-results

Perform remediation responsibly

SCAP profiles can provide Bash and Ansible remediation. Still, never roll changes into production without review. Build a test group, record the current state, check application impact and move accepted changes into Configuration as Code.

  • Read the scan result and assess risk.
  • Understand the rule, not only the failed state.
  • Run remediation on test systems first.
  • Document changes in Ansible, Salt state or policy.
  • Scan again and close the finding.

Production checklist

  • Clients are reachable as Salt systems.
  • SCAP packages and profiles are documented per distribution.
  • CVE Audit, OpenSCAP and patch processes are understood separately.
  • Result retention and detailed reports are governed.
  • Remediation only runs through tested maintenance windows.
  • Debian/Ubuntu community content is not presented as SUSE support coverage.

Define an audit model for production

Before scheduling the first scan, define the audit model. A profile is not a goal by itself. It must fit regulatory requirements, operational risk, application constraints and support model. A standard profile is often enough for an internal baseline. In regulated environments, STIG, CIS-oriented profiles or project-specific tailoring files may be required.

Keep the first scope small. Start with a test group, not the whole estate. Validate one representative SLES client first, then one RHEL-compatible client, and only then Debian or Ubuntu systems once content and expectations are clear.

  • Document profile and content version.
  • Define scan window and target group.
  • Consider memory and CPU impact on clients.
  • Align result retention with security and operations.
  • Run remediation only after review and change approval.

Handle distribution differences properly

SUSE Multi-Linux Manager is powerful because it gives central visibility and control across different Linux platforms. For compliance this does not mean that every profile has the same meaning on every system. SLES and RHEL-compatible systems usually have the clearest enterprise path. Debian and Ubuntu can be integrated technically, but may require community SCAP content depending on version.

This distinction matters in customer projects. A green or red scan is not enough. You must be able to explain which rules were checked, which rules make sense for the platform, which rules intentionally differ because of applications and which findings are actual risks.

bash
# SLES / openSUSE: inspect content paths
rpm -ql scap-security-guide | grep -E "ds.xml$|xccdf"
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml


# RHEL-compatible systems: inspect Red-Hat-compatible content
rpm -ql scap-security-guide-redhat | grep -E "ds.xml$|xccdf"
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

Turn scan results into action

After the scan, the real work begins. A failed rule is a signal, not a finished change. For each finding, verify whether the rule fits the server role, whether applications are affected, whether an exception exists and how the desired state should be automated.

In production this becomes tickets, changes, Ansible or Salt states, documentation updates and follow-up scans. The second scan matters because it proves whether the change produced the intended state.

  • Assess finding: risk, impact, priority.
  • Assign owner: platform, application, security or business.
  • Test and automate the change.
  • Scan again and archive the result.
  • Document accepted exceptions with an expiry date.

Separate OpenSCAP from patch management

Patch status and configuration compliance are related, but not identical. A fully patched system can still be misconfigured. A hardened system can still miss security updates. CVE Audit, patch lists and OpenSCAP results belong side by side in the operations review.

Sources and further documentation

  • SUSE Multi-Linux Manager 5.2 OpenSCAP: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/openscap.html
  • SUSE Multi-Linux Manager 5.2 Auditing: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/auditing.html
  • SUSE Multi-Linux Manager 5.2 Reports: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/reports.html
  • SUSE Multi-Linux Manager 5.2 Backup and Restore: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/backup-restore.html

OpenSCAP in production operations

OpenSCAP makes technical compliance measurable. In the manager, you schedule scans for registered systems, evaluate results centrally and derive hardening tasks. It is not a replacement for a security concept, but it is strong evidence for baseline adherence.

app.example.com

Workflow for a compliance scan

  1. Prepare the client: install OpenSCAP packages and suitable SCAP content.
  2. Open the system in the manager and schedule a scan under Audit.
  3. Select profile and XCCDF content.
  4. Run the scan and review the result centrally.
  5. Prioritize findings: critical, quick fix, accepted exception or project-relevant.
  6. Validate remediation on test systems first.

Treat distributions realistically

  • SLES and RHEL-compatible systems have the strongest enterprise compliance path.
  • Rocky and AlmaLinux can work with RHEL-compatible SCAP content, but must be validated against the real support context.
  • Debian and Ubuntu can be scanned technically; official content and evidentiary value must be evaluated per policy.
  • According to SUSE documentation, SSH contact method clients are not suitable for OpenSCAP.
bash
salt 'sles16-client01.example.test' pkg.install openscap-utils
salt 'sles16-client01.example.test' pkg.install scap-security-guide
salt 'sles16-client01.example.test' cmd.run 'oscap --version'

Audit evidence

Good audit evidence consists of scan time, system group, profile, result, exceptions, remediation decision and re-check. That chain matters more than a green score without context.

An empty CVE search only proves that this exact CVE was not found in the local database. For production audit, start from relevant patches and advisories, choose a real CVE or advisory ID from that list, and then check affected systems.

app.example.com
  • Synchronize CVE and patch data regularly and plan an extra update after channel changes.
  • Select a real CVE or advisory from the patch list instead of testing an arbitrary number.
  • Document affected systems, available fixes, patch status and exceptions.
  • Evaluate OpenSCAP separately: CVE audit checks vulnerabilities and patches, OpenSCAP checks configuration against profiles.

Run SUSE Multi-Linux Manager in production

Do you want to manage SLES, SL Micro, Debian, Ubuntu, Rocky, AlmaLinux or Oracle Linux centrally, validate patches, prove compliance or harden operations? ForgeOne supports licenses, architecture, installation, professional services and ongoing support.

Discuss your SUSE project