Trackr.Live The landing site for Trackr Services
§ Trackr.Live

OpenSCAP

OpenSCAP is the open-source SCAP scanner that ships in the box on every RHEL system, and the single most useful thing to understand about it is that “OpenSCAP” is two things wearing one name. There’s the scanner: oscap, the command-line engine that parses SCAP data streams and evaluates a host against them. And there’s the content: the rules, profiles, and checks the scanner actually runs, which live in a completely separate project with its own version numbers. Confuse the two and you will eventually tell an assessor you’re “running OpenSCAP 1.4” as if that says anything about which STIG revision your scan covered. It doesn’t.

A schematic of a scanning engine reading a separate stack of policy content, the two feeding into a results report and a remediation playbook.

Red Hat sponsors and maintains the project (Red Hat under IBM, and no, the IBM relationship hasn’t changed the stewardship). The core pieces: oscap, the CLI workhorse; SCAP Workbench (scap-workbench), a Qt GUI for people who’d rather click than memorize XCCDF subcommands; and the OpenSCAP Daemon (oscapd) for scheduled recurring scans. It packages into RHEL, Fedora, and CentOS Stream base repos, and builds for most Linux distributions. The pitch is simple and mostly true: it’s the no-cost compliance scanner already installed on the box, versus paid Tenable ACAS or the DoD-distributed SCAP Compliance Checker you have to go fetch.

The engine and the content are two different version streams

The oscap engine sits around 1.4.4 as of its March 2026 release. That number tells you what the scanner can do (it gained --fix-type kickstart to emit hardening Kickstarts, an autotailor that handles multi-profile JSON tailorings, an experimental fwupd firmware probe). It tells you nothing about your compliance posture.

The compliance posture lives in the content, and the content is the SCAP Security Guide — package name scap-security-guide, usually called SSG. Here’s the naming trap that catches people: the upstream project was renamed to ComplianceAsCode back in 2018, and the repo is ComplianceAsCode/content. So the thing you dnf install is scap-security-guide, the GitHub project is ComplianceAsCode, and they’re the same content. The SSG version stream runs in the 0.1.7x–0.1.8x range; the latest tagged release is 0.1.80. Pin that version in your build, because results move under you when the package updates and you didn’t ask it to.

The scanner with no content finds nothing. The content is where the STIG profiles, CIS benchmarks, and everything else actually live. When someone asks “does OpenSCAP support the RHEL 9 STIG,” the honest answer is “the SSG package does, and oscap runs it.”

Deeper: there are three version numbers in play, not two, and the third is the one that bites. The oscap engine has a version. The SSG content has a version. And the DISA STIG benchmark itself has a version, set by DISA on its own quarterly schedule, with no obligation to match whatever SSG release happens to be in your repo. So you can run a current oscap against a current SSG and still produce results keyed to a STIG revision that the assessment team’s STIG Viewer no longer treats as current. The engine version is almost never the problem. The gap between your installed SSG profile and the live DISA benchmark is. Track the SSG-to-DISA mapping deliberately, and treat the oscap version as the least interesting number of the three.

The NIST validation that isn’t being renewed

The seed framing here is a trap, so be careful with it. You will see OpenSCAP described as a “NIST-validated SCAP tool,” and the GitHub repo literally tags itself “NIST Certified SCAP 1.2 toolkit.” That label points at a real thing: a historical NIST SCAP 1.2 product validation from the RHEL 6/7 era, announced in 2017.

But do not write a bare present-tense “OpenSCAP is NIST-validated” on a system security plan and walk away. The NIST SCAP Validation Program itself reached end-of-life. NIST announced it in June 2025; NVLAP stopped accepting new applications and renewals immediately, and the program stopped accepting validation test reports after midnight EDT on September 2, 2025. So the correct statement is that OpenSCAP carries a validation issued under a program that no longer issues or renews validations. If your ConMon narrative implies an ongoing, current NIST validation, an assessor who’s read the EOL notice will mark it, and they’d be right to.

Where it sits in the DoD and federal flow

SSG is Red Hat’s upstream for the DoD RHEL STIGs, built in collaboration with DISA and NSA. That’s the genuinely useful fact: the oscap STIG profile and the published DISA benchmark are close cousins, often generated from shared lineage. Cousins, though, not twins. The xccdf_org.ssgproject.content_profile_stig profile in your installed SSG tracks a specific DISA revision, and DISA bumps revisions on a roughly quarterly cadence. RHEL 9 sits at STIG V2R7 (DISA published the SCAP benchmark for it; the SSG profile aligns to it). RHEL 10’s DISA STIG now exists too — v1r1 landed in 2026, which closes the gap that existed when the SSG RHEL 10 profile was first written against expected content. If you read older guidance calling the RHEL 10 profile “anticipatory,” that was true at the time and isn’t anymore. Verify the exact V#R# against the DoD Cyber Exchange at scan time regardless, because the profile in your package and the benchmark in the assessor’s STIG Viewer can be a revision apart.

Who runs it: system admins and ISSEs on the host, usually folded into imaging and hardening (kickstart %post, an Ansible role) and recurring config-compliance evidence for RA-5 and CM-6. Output goes to ARF and XCCDF result files that STIG Viewer and eMASS can ingest. And the alternative path matters: DISA’s own Evaluate-STIG and SCC are the DoD-blessed tooling on a lot of programs. OpenSCAP shows up most where the shop is RHEL-native and wants what oscap does that the others mostly don’t.

The remediation generation is the actual reason to pick it

This is the feature that earns OpenSCAP its place. From the same profile that finds your gaps, oscap can emit fixes: --fix-type ansible produces an Ansible playbook, and it’ll generate bash too. A scanner that reports findings is common. A scanner that hands you a hardening playbook keyed to those exact findings is the thing you actually want when you’re building a golden image.

The HTML reports are readable, which sounds like faint praise until you’ve squinted at a competitor’s CSV. Tailoring works through SCAP Workbench or the autotailor CLI when you need to carve exceptions out of a profile without editing XML by hand. For build-time hardening and drift detection on RHEL, it’s a sensible default.

Tool Who ships it Sweet spot in DoD/federal
oscap (OpenSCAP) Red Hat, open source RHEL-native shops; build-time hardening; you want the Ansible/bash remediation pipeline
SCC DISA-distributed DoD-blessed STIG attestation; teams standardized on the DoD toolchain
Evaluate-STIG DISA-distributed Automated STIG checks across mixed assets, manual-check assist, eMASS-friendly output
ACAS / Nessus Tenable (paid) Network and authenticated vuln scanning, CVE coverage OpenSCAP does not do

What people complain about

Version skew, first. You scan green in oscap, the assessor opens STIG Viewer against a benchmark that’s a revision ahead, and now you’re explaining why three rules don’t match. Pin your SSG version, know which DISA revision it maps to, and check that against what the assessment team is using before they show up.

Second, and this one bites hard: auto-generated remediation that bricks the host if applied blind. The classic is a remediation that hardens sshd, or flips a fapolicyd or SELinux setting, and locks you out of the box. I would not run oscap xccdf eval --remediate on a production host I can’t reach over the console. Generate the playbook, read it, stage it in a lab, then apply. The whole point of getting Ansible output is that you can review it before it runs; using it as a fire-and-forget switch throws that away.

Other gripes are real but smaller. OVAL evaluation gets slow on big rule sets. The results-to-eMASS workflow is clunky and ARF import has quirks that’ll eat an afternoon. And content for the newest OS release lags, because DISA and SSG both need time after a major version ships.

Here’s my contestable opinion, and I’ll mark it as such: for pure DoD STIG attestation, a lot of programs are better served by Evaluate-STIG or SCC, and OpenSCAP earns its keep mainly where you want the remediation pipeline. If your deliverable is a clean STIG checklist for eMASS and nothing more, the friction of mapping SSG revisions to DISA revisions can cost more than it saves. If your deliverable is a hardened, repeatable image, the Ansible generation flips that math entirely. Reasonable people on the same program will disagree about which side they’re on, and they should.

Operational notes

Deployment shape scales badly if you do it naively. Per-host oscap is fine for 50 boxes. At 50,000 you do not want a cron job calling oscap on each host and mailing XML around; that’s where Red Hat Insights compliance or Satellite earn their cost, centralizing scan policy and results for the RHEL fleet. The daemon (oscapd) covers the middle ground of scheduled local scans.

Integration points worth knowing: Ansible for remediation, ARF into eMASS, Insights or Satellite for fleet rollups, and oscap-podman (now in the separate openscap-utils packaging) for scanning container images in CI. The pitfalls cluster around content paths. Data streams live under /usr/share/xml/scap/ssg/content/, and picking the wrong ssg-rhel9-ds.xml versus ssg-rhel10-ds.xml for the OS minor version is a quiet way to scan against the wrong baseline. Tailoring files drift from the profiles they override. And if you don’t pin the SSG package version, a routine dnf update can shift your results between two assessments with nobody having touched the system’s actual config.

Control ties

CM-6 is the primary one. This is a configuration-settings scanner first; checking a host against a defined secure baseline is exactly what CM-6 asks for, and the STIG profiles are that baseline made machine-readable. RA-5 is a partial fit. OpenSCAP does OVAL-based checks including some CVE-feed evaluation, but it is not a network vulnerability scanner, and claiming it covers RA-5 the way ACAS does is overreach an assessor will catch. SI-2 ties in through the OVAL CVE content and the remediation generation. CM-2 and CM-3 lean on it for baseline-config and change-control evidence, since a scan diff is a clean way to show config drift. Don’t push it into SA-11 or SA-15 territory; developer testing isn’t what a host config scanner does, and forcing that mapping just weakens the ones that genuinely hold.

OpenSCAP is the right tool when “free, already installed, and emits a remediation playbook” describes what you need. It’s the wrong tool when what you need is an authoritative DoD STIG attestation and someone else’s benchmark is the one being graded. Know which job you’re doing, pin your content version, and never let --remediate run somewhere you can’t get back in.

Sources

Adjacent material on this site