STIG Compliance Automation: From Manual to Machine

First developed as part of our LinkedIn content series, June 2026. Expanded and updated for this site.

An ISSM at a Navy command stares at a spreadsheet tracking 200 Windows servers, each subject to a STIG containing 280 rules. That is 56,000 individual configuration checks every quarter — and she has three people on staff. Last quarter, her team finished the manual review on a Thursday. By the following Monday, a system administrator had pushed a Group Policy change that invalidated findings on forty servers. The checklist she submitted to the AO was already stale before the ink dried.

This scenario repeats across every branch of the military and every cleared defense contractor. DISA publishes over 400 STIGs covering operating systems, databases, network devices, middleware, and applications. The math has become impossible for human-driven processes, and DoD knows it. The push toward continuous Authority to Operate (cATO) is not aspirational — it is a direct acknowledgment that point-in-time compliance snapshots provide a false sense of security.

Why This Matters Now

DoD CIO cATO guidance demands continuous monitoring of security configurations, not quarterly manual scans packaged into checklist files that are already outdated by submission. DISA releases STIG updates on a quarterly cycle, with out-of-cycle releases for high-priority issues. Recent STIG releases for newer operating systems and container platforms introduced hundreds of new rules that make manual processes even less viable. Meanwhile, DISA's STIG Viewer 3 introduced the CKLB (JSON-based) checklist format alongside the legacy CKL (XML), and the assessment tooling ecosystem is still mid-migration.

Simultaneously, STIG compliance metrics increasingly roll up into command-level cyber readiness reporting. Commands with automated continuous scanning consistently report far higher compliance rates than commands relying on manual quarterly checks — not because manual-process commands are less secure in practice, but because their evidence is perpetually lagging.

The gap between assessment and reality is the attack surface nobody wants to talk about.

What STIGs Actually Are (And Why They Matter)

Security Technical Implementation Guides are DISA-published configuration standards for hardening any technology used in DoD environments. Each STIG is a collection of rules — specific configuration checks with a Vulnerability ID (V-ID), a severity category (CAT I, CAT II, or CAT III), and detailed fix instructions.

Severity matters for prioritization and POA&M timelines:

CAT I — Critical. Directly exploitable vulnerabilities that could result in loss of confidentiality, integrity, or availability. Must be remediated immediately. An open CAT I finding can halt an ATO.
CAT II — Medium. Vulnerabilities that degrade the security posture but require additional conditions to exploit. Typical remediation window is 90 days.
CAT III — Low. Configuration weaknesses that provide minor security improvements. Remediation follows standard maintenance cycles.

A single Windows Server 2022 STIG contains approximately 280 rules. RHEL 9 contains 250. PostgreSQL contains 120. Multiply by the number of systems in your authorization boundary, and you have the scale problem that makes automation non-optional.

The Manual Process and Its Failure Modes

Traditional STIG compliance follows a painful workflow:

Download the STIG XML from the DISA STIG Library
Load it into DISA STIG Viewer or STIG Manager (the open-source findings management tool from NIWC Pacific)
Connect to the target system
Manually verify each rule — checking registry keys, service configurations, file permissions, audit policies
Record findings as Open, Not A Finding, Not Applicable, or Not Reviewed
Document finding details and any mitigations
Export results to a CKL (XML checklist) file — or the newer CKLB (JSON) format if your tooling supports it. Whether a given STIG Manager instance accepts CKLB is UNVERIFIED. Advisedly's STIG Manager HTTP connector does not ship.
Submit checklists to the Authorizing Official as part of the RMF package

For a single Windows Server STIG, this takes 6-10 hours per system when done thoroughly. Most teams are not thorough — they spot-check, they copy-paste from last quarter, they mark rules NAF because they were NAF last time without re-verifying. The manual process does not merely waste time. It produces unreliable evidence.

Three systemic failure modes plague manual STIG compliance:

Staleness — By the time a manual review is complete across all systems, the first systems reviewed have likely drifted. Configuration drift is continuous; manual assessments are episodic.

Inconsistency — Different assessors interpret rules differently. One marks a compensating control as NAF; another marks the same configuration as Open. Without automation, there is no normalization.

Scalability collapse — When headcount cannot keep pace with system count, something gives. Usually it is thoroughness. Teams prioritize CAT I rules and skip CAT III entirely, creating a long tail of unaddressed findings.

SCAP Automation: The Foundation

The Security Content Automation Protocol (SCAP) is the primary standards-based approach to automating STIG checks. DISA publishes SCAP benchmarks alongside most STIGs, encoding rules as machine-readable OVAL (Open Vulnerability and Assessment Language) definitions.

Common STIG automation tools:

DISA SCC (SCAP Compliance Checker) — The officially endorsed scanner for DoD assessments. Processes SCAP benchmarks and produces XCCDF results that can be imported into STIG Viewer to generate checklists. Required for official authorization assessments at most commands.
OpenSCAP — Open-source SCAP-validated scanner. Strong for Linux (RHEL, Ubuntu). Works well for continuous monitoring between official SCC assessments. Advisedly does not run oscap and does not claim SCAP 1.3.
EvalSTIG — DISA-maintained and widely adopted by DoD ISSMs for streamlining assessments. Automates many manual STIG checks that SCC cannot cover. However, EvalSTIG does not autocomplete all STIG rules — coverage varies by technology, with significant gaps in application-layer and database STIGs. It also lacks automated reporting rollup: results stay per-system with no cross-boundary aggregation, no trend analysis, and no automatic POA&M generation. Teams using EvalSTIG still face manual effort for the rules it cannot evaluate and manual effort to consolidate results into authorization packages.
STIG Manager — Open-source findings management platform developed by NIWC Pacific. Imports CKL checklists and scan results, provides multi-user collaboration and boundary-level tracking, but does not perform automated scanning — it is a findings management tool, not a scanner. Native CKLB support in a running STIG Manager is UNVERIFIED. Advisedly's STIG Manager HTTP interchange does not ship.

The SCAP scanning workflow:

Download the STIG SCAP benchmark from the DISA public library
Import into an SCAP-validated scanner (SCC, OpenSCAP, or commercial equivalent). Advisedly does not run oscap and does not claim SCAP 1.3.
Configure scan targets — credentials, network ranges, system groupings
Execute automated scans against target systems
Review results for false positives (typically 3-8% of findings)
Generate checklist files (CKL, or CKLB where supported) or XCCDF results for submission

Coverage reality: Not every STIG rule has a corresponding SCAP check. Typical automation coverage by platform:

Platform	Approximate Rules	SCAP Coverage	Gap
Windows Server 2022	~280	~85% via SCAP + GPO	15% require manual or script
RHEL 8/9	~250	~90% via SCAP + Ansible	10% procedural
Ubuntu 22.04	~220	~85% via SCAP + Ansible	15% manual
Windows 10/11	~300	~80% via SCAP + GPO	20% manual
Cisco IOS XE	~200	~70% via config parse	30% requires show commands
PostgreSQL 15	~120	~65% via SQL queries	35% requires DBA judgment

The gap column is where most organizations fail. Those un-automatable rules — checking whether administrators have completed training, whether procedures exist, whether physical safeguards are in place — require a different approach: evidence integration, not scanning.

Beyond Scanning: Configuration Enforcement

Scanning tells you what is wrong. Enforcement prevents it from going wrong. The most mature STIG programs combine both:

Configuration Management Tools:

Ansible STIG Roles — Community and DoD-maintained roles that apply STIG-hardened configurations to Linux systems. The ansible-lockdown collection covers RHEL, Ubuntu, and CentOS with role-per-STIG granularity.
PowerShell DSC — Desired State Configuration enforces Windows STIG settings and automatically remediates drift when configurations change.
Group Policy Objects — Many Windows STIG requirements map directly to GPO settings. A well-structured GPO hierarchy can enforce 60-70% of Windows STIG rules without any additional tooling.

Drift Detection:

The critical capability gap in most STIG programs is not initial compliance — it is sustained compliance. Systems drift. Administrators make changes. Patches alter configurations. Without continuous drift detection, your last scan result is fiction.

Effective drift detection requires:

Agent-based or agentless configuration monitoring running continuously (not weekly, not daily — continuously)
Alerting when a CAT I configuration reverts to a non-compliant state
Automatic re-scan and CKLB regeneration when drift is detected (legacy CKL remains available as an opt-in)
Audit trail showing who changed what, when, and whether it was authorized

CKL vs CKLB: The Format Migration

With STIG Viewer 3, DISA introduced CKLB — a JSON-based checklist format that is more structured, machine-parseable, and better suited to automated pipelines than the legacy CKL (XML) format. Adoption across the assessment ecosystem is still in progress: many tools still operate on CKL. Whether STIG Manager reads or writes CKLB natively is UNVERIFIED. Advisedly's /api/integrations/stig-manager interchange does not ship. The dedicated router is mounted (before the generic /api/integrations mount) but interchange POSTs 501-refuse on both that router and the generic /api/integrations surface and never emit a checklist. POST /api/integrations/stig-manager/assessments/:id/export-cklb, .../export-ckl, .../import-checklist, and .../push always 501.

What changed from CKL to CKLB:

Format — XML to JSON. Smaller file sizes, easier programmatic manipulation, no namespace headaches.
Schema — A stricter, machine-validatable structure that eliminates much of the parsing ambiguity of legacy CKL.
Multi-STIG support — A single CKLB can contain results for multiple STIGs assessed on the same host.
Tool ecosystem — DISA STIG Viewer 3 reads and writes CKLB natively, and newer tool releases are adding support. Tools that have not yet adopted CKLB still work in legacy CKL and may require conversion utilities. STIG Manager CKLB ingest remains UNVERIFIED.

A checklist file captures:

Target system information (hostname, IP, MAC, FQDN, technology area)
STIG version and release information
Finding status for each rule
Finding details — the specific evidence supporting the determination
Assessment timestamps and assessor identity

The automation opportunity is not eliminating checklists but generating them automatically from scan results, enriching them with evidence artifacts, and keeping them current without human intervention. An automated pipeline should produce CKLBs that an assessor can validate in minutes rather than hours.

Integrating STIGs with RMF

STIG compliance does not exist in isolation. It feeds directly into the Risk Management Framework authorization process:

Security Control Assessments — STIG scan results provide direct evidence for dozens of NIST 800-53 technical controls (CM-6, CM-7, AC-3, AU-2, SI-2, and many others)
POA&M Generation — Open STIG findings become POA&M entries with remediation timelines, milestones, and resource assignments
Continuous Monitoring — Ongoing STIG scans satisfy OMB and DoD continuous monitoring requirements for configuration management
ATO Evidence Packages — CKL files, scan reports, and trend data are submitted as artifacts in the authorization package
eMASS Integration — Automated STIG results can feed directly into eMASS for enterprise-level visibility

The organizations that achieve cATO do so by treating STIG compliance as a data pipeline, not a periodic project. Scan results flow into the authorization system continuously, POA&Ms generate automatically for new findings, and the AO sees real-time compliance posture rather than a quarterly snapshot.

The Contrarian Position

Manual STIG checks are not thorough — they are theater. An automated scan at 85% coverage run daily beats a manual check at 100% coverage run quarterly.

This claim draws objections. "But automation misses the nuanced rules." True. But consider what 100% manual coverage actually means in practice: an exhausted analyst on day four of a manual review, rushing through CAT III findings, copying comments from the last quarter CKL, marking rules NAF because they were NAF last time without re-verifying.

The 15% of rules that resist automation are real. They need human attention. But the answer is not to manually review all 100% of rules — it is to automate the 85% that can be automated, and focus human expertise exclusively on the 15% that demands judgment. Daily automated scans catch drift that quarterly manual reviews never will. A CAT I finding that opens on Tuesday and closes on Thursday never appears in a quarterly manual review. In a continuous automated scan, it triggers an alert within hours.

The false choice between fully automated and fully manual serves nobody. The professional approach is automated coverage for machine-evaluable rules with human review reserved for rules requiring judgment — and continuous cadence for both.

Key Takeaways

56,000+ manual verifications per quarter is the reality for mid-size DoD environments — this math makes automation non-optional

SCAP benchmarks cover 65-90% of STIG rules depending on platform; the remainder requires evidence integration, not more scanning

Drift detection between scans is the most critical gap in most STIG programs — compliance at scan time says nothing about compliance between scans

cATO requires treating STIG compliance as a continuous data pipeline, not a quarterly project

Focus human expertise on the 15% of rules that require judgment; automate everything else at daily or higher cadence

CKLB (JSON) is gradually replacing CKL (XML) — plan your tooling migration now, and expect to support both formats during the transition. Live STIG Manager CKLB ingest is UNVERIFIED; Advisedly's STIG Manager HTTP connector does not ship.

Tools like EvalSTIG help on assessment day but lack cross-boundary reporting, automated POA&M generation, and continuous monitoring — they solve the per-system problem, not the enterprise problem

Frequently Asked Questions

How long does it take to automate STIG compliance for a typical DoD environment?

Initial automation setup — including SCAP scanner deployment, baseline scans, false positive tuning, and CKLB generation pipeline — typically takes 4-8 weeks for a 100-system environment. The first two weeks are scanner deployment and credential configuration. Weeks three and four are baseline scanning and false positive adjudication. The remaining time is building automated reporting and integrating with your RMF workflow.

Can we achieve 100% STIG automation coverage?

No. Approximately 10-35% of STIG rules (depending on technology) require human judgment — verifying procedures exist, confirming training completion, validating physical security controls. The goal is not 100% automation; it is automating everything that can be automated and creating structured workflows for rules that cannot.

How do STIG findings relate to our SPRS score?

STIG findings do not directly factor into your SPRS score, which is based on NIST 800-171 controls. However, STIG compliance provides implementation evidence for many 800-171 controls. A system with open CAT I STIG findings almost certainly has gaps in 800-171 controls related to configuration management (3.4.x) and system integrity (3.14.x).

What happens when DISA releases a new STIG version?

New STIG releases add, modify, or deprecate rules. Your automation must ingest the new benchmark, map changes to existing findings, identify net-new rules requiring assessment, and regenerate CKLBs against the updated version. Organizations without automated pipelines face a manual re-assessment of every system each time a STIG updates — which happens on a quarterly release cycle, plus out-of-cycle updates for high-priority issues.

Is OpenSCAP sufficient for DoD STIG scanning?

Advisedly does not run oscap and does not claim SCAP 1.3. OpenSCAP is SCAP-validated and technically capable of processing DISA SCAP benchmarks. However, DoD environments typically require DISA SCC (SCAP Compliance Checker) for official assessments because it is the DISA-endorsed tool. OpenSCAP works well for continuous monitoring between official assessments and for Linux-heavy environments where SCC support may lag. Advisedly does not run oscap and does not claim SCAP 1.3.

Where does EvalSTIG fit vs. SCC and Advisedly?

EvalSTIG fills the gap between SCC's automated SCAP checks and fully manual review. It automates many checks that SCC cannot evaluate (application-layer settings, service configurations). However, EvalSTIG operates one system at a time, does not provide cross-boundary reporting or trend analysis, cannot generate POA&Ms, and has incomplete coverage for database and application STIGs. It is a useful assessment-day tool but not a continuous compliance solution.

Do we still need to produce CKL files?

DISA is transitioning toward CKLB (JSON format), introduced with STIG Viewer 3. Most commands still accept — and many still expect — legacy CKL (XML), and much of the tool ecosystem still operates on CKL. DISA STIG Viewer 3 and Advisedly produce CKLB. Whether STIG Manager accepts that file is UNVERIFIED. Advisedly's STIG Manager HTTP connector does not ship. If your AO or eMASS instance still requires XML CKL, conversion utilities exist, but plan for a period of supporting both formats.

How Advisedly Helps

Advisedly is not SCC, EvalSTIG, or an OpenSCAP scanner. It does not run OpenSCAP, does not claim SCAP 1.3 compatibility, and does not evaluate OVAL on the agent (oval_eval returns not_applicable; OVAL import is catalog ingest only).

What does ship:

Ingest of STIG/CKL/ARF results you already have (including files produced by SCC or EvalSTIG) into the compliance ledger
Enrolled-agent compileable STIG/CIS-style configuration checks (file, command, registry, service, permission probes) — not SCAP data-stream evaluation
CKLB export from stored scan results (legacy CKL remains available as an opt-in). Whether STIG Manager accepts that file is UNVERIFIED
POA&M candidates from open findings, subject to approved exceptions

The agent is not an end-to-end STIG assessment replacement and does not auto-apply new DISA benchmark versions as a SCAP-validated scan. Official authorization assessments still use the command's endorsed SCAP tool (typically DISA SCC). Contact begin@advisedly.ai for STIG program automation.