Three ways to work a STIG checklist.

A checklist is only worth what you can do with it. stig-baselines ships three assessment paths per checklist — and a prioritization layer that tells you which checklist to work first.

Path A — manual assessment in STIG Viewer

DISA STIG Viewer 3.x (Java 17+) opens the baseline's .ckl directly. Fill in the ASSET tab once (hostname, IP, FQDN), then work each VULN: read the check, run the commands against the host, set the status (Open / NotAFinding / Not_Applicable / Not_Reviewed), and put the reasoning in FINDING_DETAILS and COMMENTS. The exported file is the evidence artifact for eMASS and POA&M workflows. See the checklist-generation tutorial for where the file comes from.

Path B — OpenSCAP scans from committed datastreams

For the RHEL baselines, the repository commits the SCAP datastreams that match the manual STIG revisions — no auth wall, no fetch at scan time, and currently zero version skew between the datastream and the manual checklist revisions:

Host OS	Datastream (committed)	Release
RHEL 7	`U_RHEL_7_V3R15_STIG_SCAP_1-3_Benchmark.xml`	V3R15
RHEL 8	`U_RHEL_8_V2R9_STIG_SCAP_1-3_Benchmark.xml`	V2R9
RHEL 9	`U_RHEL_9_V2R10_STIG_SCAP_1-3_Benchmark.xml`	V2R10

sudo oscap xccdf eval \
  --profile xccdf_mil.disa.stig_profile_MAC-2_Public \
  --results results.xml \
  --report report.html \
  sources/scap/U_RHEL_9_V2R10_STIG_SCAP_1-3_Benchmark.xml

The datastreams carry the OVAL-checkable rule subset — 161/291/393 of the manuals' 244/371/445 rules for RHEL 7/8/9. Rules without automated checks scan as Not_Reviewed by design; a scan is a head start on the assessment, not the assessment. When DISA ships new revisions, the source listing to re-check is documented in the repository.

Path C — Nessus

The same baselines also work against Tenable/Nessus policy-based scans where your organization already runs it. The specifics — plugin mapping and the result-to-checklist merge — live in the repository's scanning documentation alongside the other two paths.

Beyond one host

Two workflows scale the assessment past a single checklist:

Bulk status application from CSV — the vSphere 6.7 evaluation workflow applies result rows to a checklist in bulk (docs/VSPHERE67-EVALUATION.md in the repo) rather than clicking through a viewer. The ESXi 6.7 and vCenter 6.7 baselines have no automated check source — the CSV route is how they get worked.
Fleet scanning, offline — the repo carries worked examples for Proxmox clusters and an ssh remote-scan recipe (examples/), and make dist produces the air-gapped archive with a sha256 sidecar for transfer into networks that never see the internet.

The prioritization layer

Working every checklist is not the goal. kevstig routes the CISA KEV catalog against these baselines and tells you which platforms carry live exploitation pressure — start there. The method is in the KEV tutorial; the checker runs live on this site, refreshed daily.

The honest gap: automation is not sign-off. A scan fills part of the checklist, the CSV route fills it faster — but the evidentiary status decisions (what is actually deployed, what is actually applicable) remain human judgments recorded in the checklist. The coverage gaps of each automated source are stated in the repository rather than papered over, and a resulting checklist distinguishes scanned rules from judged ones.

Source

github.com/dmrobbi/stig-baselines — the repository (MIT): the baselines, the committed datastreams, the examples, and the scanning docs.
Generate a DISA STIG checklist from XCCDF — where the checklists come from.