Red Hat’s RHEL 10 STIG Update Turns Compliance Into a Moving Target

Red Hat announced on September 25 that its automated compliance content for Red Hat Enterprise Linux (RHEL) 10 now matches the Defense Information Systems Agency’s (DISA) official Security Technical Implementation Guide (STIG) baseline, version 1, release 2 (V1R2). Red Hat calls this “full STIG maturity” for RHEL 10. But the same open source update that got RHEL 10 there also revised RHEL 8’s STIG for the eighth time and RHEL 9’s for the ninth, a detail buried in the release notes rather than the announcement, and it undercuts the finish-line framing: STIG compliance is not something an operating system reaches once. It is a maintenance obligation that keeps arriving on a schedule nobody at Red Hat controls.

What a STIG actually requires

DISA defines STIGs as published, technical security baselines: configuration requirements a system must meet before it can connect to a Department of Defense (DoD) network. Red Hat’s own post, written by Marek Haičman, a senior software quality engineer, and Amy Ralph, a principal product manager for RHEL, frames the stakes plainly for the DoD and its contractors: security has to hold up against a published baseline, not a general claim that systems are “secure.” According to Red Hat, DISA first published a STIG for RHEL 10 in March 2026. The automated compliance content available today, released September 1 as part of the open source scap-security-guide project’s version 0.1.82, catches that baseline up to its second revision, V1R2.

The open source engine behind the announcement

The tooling doing the actual work is not a Red Hat product in the traditional sense. It is ComplianceAsCode, an open source project distributed as the scap-security-guide package, with roughly 2,800 stars and 836 forks on GitHub, that turns security baselines like DISA’s STIGs and the Center for Internet Security’s benchmarks into machine-readable rules. Red Hat exposes that content to administrators through OpenSCAP.

OpenSCAP implements a NIST-maintained specification called the Security Content Automation Protocol (SCAP), and the OpenSCAP project has held NIST’s SCAP 1.2 certification since 2014. Under the Federal Information Security Management Act (FISMA), federal agencies are required to implement SCAP-based tooling for exactly this kind of continuous configuration checking. Red Hat’s post lists three ways to run the RHEL 10 STIG profile against a live system: the oscap command line tool directly, Red Hat Satellite for fleet-wide scanning, or Red Hat Lightspeed, the product Red Hat renamed from Red Hat Insights. There is also a build-time path: applying the same profile through Kickstart, RHEL image builder, or RHEL’s image mode workflow, so a system boots already aligned instead of needing a scan-and-remediate pass after the fact. All of these read from the same underlying scap-security-guide content, so the stig or stig_gui profile behaves identically no matter which interface triggers it, and the same content ships as an Ansible Galaxy role for teams that already manage configuration through Ansible.

One release, five moving baselines

The scap-security-guide project’s version 0.1.82 release, published on GitHub on September 1, 2026, and cryptographically signed with a verified GPG key, shows RHEL 10’s V1R2 update was not an isolated event. The same release moved RHEL 8’s STIG profile to V2R8, RHEL 9’s to V2R9, Oracle Linux 8’s to V2R8, and Ubuntu 24.04’s STIG profile from V1R1 all the way to V1R5. Five operating systems, five separate DISA or Canonical baselines, all revised inside one dated software release.

Read those revision numbers side by side and RHEL 10’s “full maturity” looks less like an arrival than a starting line. RHEL 8 is eight releases into its current STIG version. RHEL 9 is nine releases in. RHEL 10 has had two. DISA does not publish a STIG once and walk away; it revises published baselines on a recurring basis as new vulnerabilities surface, controls get reworded, or a product’s configuration options change, and every one of those revisions is a new target the automation content has to hit again. Ubuntu 24.04 jumping from V1R1 to V1R5 in a single scap-security-guide release tells the same story from a different angle: it shows what happens when the open source project falls behind a vendor’s publication cadence and has to close four revisions’ worth of gap in one update.

One more item in the same release notes makes the point without touching STIGs at all. The RHEL 10 profile for the Protection Profile for General Purpose Operating Systems (OSPP), a separate Common Criteria-based certification track with its own review process, came out of draft status in this same release. Two independent compliance frameworks reaching a milestone for the same operating system inside one open source update is a reminder that STIG alignment is only one of several parallel certification tracks a platform vendor has to keep current at once.

What the automation covers, and what it does not

Red Hat is explicit that “full STIG maturity” describes the automation content, not a finished compliance posture. The company’s own post includes a direct caveat: while the updated profile automates the technical configuration requirements of the STIG, system administrators and security officers must still review findings within the context of their specific operational environment to achieve full compliance certification. An oscap scan can flag a misconfigured SSH daemon or an unencrypted partition and, in remediation mode, fix it automatically. It cannot decide whether a documented exception for a legacy application is an acceptable risk, or sign the paperwork a certifying official needs before granting approval.

Where this fits in the approval pipeline

That distinction lines up with how the National Institute of Standards and Technology (NIST) describes its own Risk Management Framework (RMF), the process federal systems use on the way to an Authority to Operate (ATO). NIST’s RMF runs through seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. STIG scanning and remediation, whether run through oscap, Satellite, or Lightspeed, does the heavy lifting in Implement and Assess, and the same tooling can feed Monitor, since these are the tools an administrator would rerun on a schedule to catch new configuration drift. But NIST is unambiguous about who owns the Authorize step: a senior official makes a risk-based decision to authorize the system to operate. No amount of scap-security-guide content automates that signature.

Red Hat’s claim that the update supports “accelerated Authority to Operate (ATO) pathways” reads more accurately in that light. Automation does not remove the Authorize step or the judgment behind it. It removes the slower, more error-prone part of Assess, the manual checklist walk that used to precede that judgment, and hands whoever fills out the ATO paperwork a consistent, versioned record of what was checked and when.

A maintenance bill that never closes

Red Hat has made a version of this same argument about RHEL 10 before, for a different kind of compliance. In a July post about post-quantum cryptography migration, the company described post-quantum readiness as four discrete phases (Classical, PQ-Capable, PQ-Ready, and eventual deprecation of classical algorithms) rather than a single cutover date, specifically because RHEL 10.0 and RHEL 10.1 landed on opposite sides of that timeline within the same major release. STIG compliance follows an identical pattern: a baseline is never simply finished, it moves through revisions on a schedule the operating system vendor does not set, and the job is to keep pace.

As of September 2026, “full STIG maturity” for RHEL 10 means the automation content is caught up to the current published baseline. It does not mean that work is finished. RHEL 8 and RHEL 9 make the same point without needing the word “maturity”: both have had years longer than RHEL 10 to accumulate STIG revisions, and both still needed a new one in the exact same software release that gave RHEL 10 its first. RHEL 10’s next STIG revision is not a question of if. It is only a question of how long the gap runs before scap-security-guide closes it again.

Sources

• Red Hat Blog: Red Hat Enterprise Linux 10 STIG automation now matches DISA STIG V1R2
• ComplianceAsCode/content GitHub release notes: Content 0.1.82
• OpenSCAP Portal: Security compliance and vulnerability assessment tools
• NIST Computer Security Resource Center: About the Risk Management Framework (RMF)
• sxz.io: Red Hat’s RHEL 10 Turns Post-Quantum Migration Into a Financial Services Deadline
• sxz.io: Red Hat’s Insights-Client Rework Turns a Silent Self-Updater Into a Standard RPM Package
• sxz.io: RHEL Image Builder 10.2 and 9.8: A Golden Image Checklist

Image credit: A pair of well-used archery targets at the Thompson Park archery range in Montana’s Beaverhead-Deerlodge National Forest. Photo by Preston Keres, U.S. Department of Agriculture Forest Service, public domain (U.S. government work), via Wikimedia Commons; cropped and converted to WebP for sxz.io.