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

SCAP Compliance Checker (SCC)

SCC is the engine. That distinction does most of the work on this page, so start there: the SCAP Compliance Checker is the scanner that reads DISA STIG benchmark content and produces automated, machine-readable configuration-compliance results. It does not write the rules. It runs them. The rules live in SCAP content, the Security Content Automation Protocol bundling XCCDF, OVAL, and CPE under NIST SP 800-126, and SCC is one tool that consumes that content against a real host and tells you which settings comply.

A schematic engine ingesting a stack of benchmark documents and emitting structured compliance result cards routed toward a review queue and an authorization file.
It is built by NIWC Atlantic, the Naval Information Warfare Center Atlantic, formerly SPAWAR. Government-developed, released into the public domain under Title 17 Section 105, and free for the DoD, other agencies, contractors, and the general public. There is no license to buy and no seat count to true up at audit time. That alone explains why SCC is the default config scanner across so much of the federal landscape: it ships with the right DISA pedigree and costs nothing.

Three things get conflated constantly, and an ISSO who muddles them in an SSP will draw questions. SCAP is the protocol and content format. SCC is a scanner that ingests it. ACAS, the Tenable-based DoD vulnerability program, lives in a different lane entirely. SCC checks configuration against STIGs. ACAS hunts CVEs and missing patches. You run both because they answer different questions, not because one replaces the other.

Version reality

Here is the part worth slowing down for. The version you run and the version NIST formally validated are not the same version, and they have not been the same for years.

The current shipping release is SCC 5.14, dated February 11, 2026, with 5.14.1 close behind bundling DISA’s Q2 2026 STIG and SCAP benchmark content. Meanwhile the NIST SCAP 1.3 validation record, entry #147 in the validation program, is pinned to SCC 5.6.0.1, validated November 4, 2022. That record covers the Authenticated Configuration Scanner capability plus the CVE and OCIL options, tested against Windows 10, Windows Server 2012 R2, RHEL 7, and macOS 10.11. None of those are platforms you would build to today.

So the formal validation lags the production tool by eight minor releases and most of four years. This is normal for SCC, and it is the kind of thing that makes an auditor pause and a vendor competitor smirk. Whether it should matter is a real question, and I have an opinion on it below.

Deeper: The validated-version gap is mostly a paperwork concern, not a security one, and I will defend that. NIST SCAP validation certifies that a scanner correctly interprets SCAP content and reports results faithfully against a fixed test corpus. That interpretation engine is stable. SCC 5.14 parsing an XCCDF benchmark behaves the same way 5.6.0.1 did; what changed across those releases is platform coverage, packaging, UI, and bundled content currency, not the core SCAP-handling logic the validation actually exercised. The risk a stale validation introduces is narrow: you lack a federal lab’s signed assurance that the exact build you run reads content correctly. In practice the bigger operational exposure is content currency, are you scanning against the right DISA benchmark version, not whether the scanner carries a 2026 validation stamp. If your compliance team treats the validation date as a blocking gate, that is a defensible-but-costly posture, and you should be ready to argue it either way in front of an AO.

Where it sits in the DoD flow

SCC produces evidence, and that evidence travels. You run a STIG benchmark against a host, SCC emits XCCDF results and ARF, plus an SCC-generated checklist. That output flows into STIG Viewer or STIG Manager for human review and annotation, and the reviewed results roll up into eMASS as assessment artifacts supporting an ATO under the RMF.

Who runs it: ISSOs, ISSEs, and the sysadmins who own the boxes in scope. Cadence follows two clocks. DISA releases STIG and benchmark content quarterly, so your content goes stale on a known schedule, and RMF continuous monitoring expects you to rescan as your baseline drifts. The discipline that breaks under load is matching the benchmark version to the STIG release you are actually being assessed against. SCC will happily scan against last quarter’s content and hand you a clean-looking result that an assessor rejects on sight.

The honest limit: SCC automates the checkable subset of a STIG. A STIG mixes machine-verifiable settings with manual checks that require a human to look at documentation, interview an admin, or confirm a physical condition. SCC closes the automatable checks and leaves the rest open for review in STIG Viewer. Anyone who reports an SCC scan as a completed STIG assessment is skipping the manual checks, and that gap is where findings hide.

Stage What happens Where it lands
Run SCC executes a DISA SCAP benchmark against the host, local or credentialed/remote Host under assessment
Automated result Checkable STIG items scored pass/fail as XCCDF + ARF SCC output directory
Manual review Non-automatable STIG checks worked by hand STIG Viewer / STIG Manager
Roll-up Reviewed checklist submitted as assessment evidence eMASS, supporting the ATO

Strengths, and the complaints

What SCC does well is straightforward. It is free and DoD-blessed, with no license cost and no procurement drama. Platform coverage is broad. The output drops cleanly into the eMASS and STIG Viewer pipeline because it was built for exactly that. It runs fully disconnected, which matters more than it sounds: a lot of the environments that need this most are air-gapped, and a scanner that phones home or needs a cloud console is useless there.

The complaints are real and I will not soft-pedal them. The validated version lags the shipping version, covered above. Content currency is a manual chore; SCC does not auto-fetch the right DISA benchmark, so you pull it and confirm the version yourself, every quarter, and people forget. STIG automation is partial by design, which means the tool can give a false sense of completeness if you do not track the manual checks separately. The interface and reporting feel dated next to commercial compliance dashboards. Credential and agent handling across a mixed Windows, Linux, and Cisco fleet gets fiddly at scale. And SCC is a point-in-time scanner, not a continuous-monitoring platform in the SIEM sense; it tells you the state at scan time, nothing more.

If I had to name the real operational tax, it is the manual-check gap, not the tool. The scanner does its job. The trouble is that a STIG is only partly automatable, and the human review SCC leaves behind is the slow, expensive, error-prone part of every assessment. No config scanner fixes that, which is worth remembering before you blame SCC for the workload.

A note on what SCC is not, because the procurement question comes up. It is government-furnished, not a commercial product, so it does not sit on the FedRAMP Marketplace and the DoD-APL framing that applies to ACAS and Tenable does not apply here. There is no listing to point at. State the absence plainly rather than implying one exists.

Practical operations

Distribution runs through the DoD Cyber Exchange at cyber.mil/stigs/SCAP, which gates the current release behind CAC or registration. NIWC Atlantic keeps a public archive of past releases on GitHub at niwc-atlantic/scap-scc, and the SCAP content the team produces lives at niwc-atlantic/scap-content-library. Adoption is wide, on the order of a few thousand registered users across a couple hundred agencies, funded over its history by DISA, NSA, and the IRS among others.

Deployment is either a local scan on the host or a remote credentialed scan against targets you can reach. Verified platforms in the current release span Windows 10 and 11, Windows Server 2022, the RHEL and broader Linux family, Solaris, macOS, and Cisco IOS and IOS XE. Keep two facts apart: the platforms current SCC runs on and scans are far wider than the narrow 2022 set frozen in NIST record #147. The validation record is a historical snapshot, not the support matrix.

The pitfall that bites teams: SCC integrates with STIG Viewer, STIG Manager, and eMASS and rides the DISA quarterly content cycle, but it is not a native SIEM or CI tool. If you want compliance gating inside a pipeline or live dashboards in a SOC, SCC is the wrong shape, and OpenSCAP or a commercial platform fits better. SCC is an assessment instrument, not a monitoring fabric.

Control ties

Map SCC to NIST SP 800-53 where it genuinely earns the tie. CM-6, configuration settings, is the core: automated verification that a host matches STIG-defined settings is precisely what CM-6 asks for, and SCC is the canonical DoD way to produce that evidence (CM family). RA-5, vulnerability monitoring and scanning, fits through SCC’s OVAL and CVE-option side and its role in the broader scanning ecosystem (RA family). CA-7 continuous monitoring and SI-2 flaw remediation are honest secondary ties, since SCC feeds the rescan cadence and surfaces settings that need fixing.

Where SCC does not belong: SA-11 and SA-15 are developer-testing and SDLC controls, and SCC is an operations and assessment tool that runs against built systems, not source. Forcing an SA tie there is the kind of stretch an assessor notices. The same goes for SR supply-chain controls. Be selective. A config scanner maps to config and assessment controls, and pretending otherwise weakens the narrative that does fit.

Sources

Adjacent material on this site