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

SCAP

SCAP stands for Security Content Automation Protocol, and the first thing to get straight is that it is not a tool you install. It is a NIST specification suite that defines how vulnerability, configuration, and patch data gets expressed in XML so that any conforming scanner reads the same content the same way. The current version is SCAP 1.3, defined by NIST SP 800-126 Rev. 3 plus its component annex SP 800-126A. Under the hood it is a stack of older standards bolted together: XCCDF for the checklist logic, OVAL for the low-level system probes, CPE for platform identification, CCE for configuration items, CVE for vulnerabilities, and CVSS for scoring, with ARF as the results envelope. When someone in a program office says “run the SCAP,” they almost never mean the protocol. They mean: take a DISA STIG benchmark packaged in SCAP format, feed it to a validated scanner, and produce evidence for the ATO package.

Schematic of a layered XML content stack feeding a scan engine, which emits a results bundle into a compliance dashboard.

So SCAP is two things that people constantly conflate. There is the protocol (the XML grammar) and there is the content (the benchmark that encodes a specific policy). DISA writes the content for DoD. NIST owns the protocol. The scanner is a third thing entirely, and you have choices there.

The version reality nobody updates their SSP for

SCAP 1.3 has been the effective version for years and it still is. What changed recently is that NIST published the initial public draft of SP 800-126r4, which defines SCAP 1.4 (public comment closed February 11, 2026). It streamlines requirements toward what implementations actually do rather than introducing a new architecture. If your old runbook references “SCAP 2.0 in draft,” delete that line. The 2.0 effort that floated around years ago is not what’s on the table. The live trajectory is 1.3 today, 1.4 next, both incremental.

The bigger change is upstream of the spec. The NIST SCAP Validation Program is end of life. NVLAP stopped accepting new accreditation applications and renewals, and the last validation test reports from accredited labs were accepted at midnight EDT on September 2, 2025. The validated products list is still up as an archive (a handful of SCAP 1.3 entries, the most recent being HCL BigFix in August 2025), but no new product is going to earn a fresh SCAP 1.3 validation through that program. This matters because a pile of federal language, including the old OMB M-08-22 mandate, leans on the phrase “use a SCAP-validated product.” That phrase now points at a closed program. Treat “SCAP-validated” as a historical seal of conformance, not a living gate.

Who makes the scanners you’ll actually run

In DoD the default is SCAP Compliance Checker (SCC), built and maintained by NIWC Atlantic (Naval Information Warfare Center) and distributed free through DISA at cyber.mil. Current release is 5.14, dated February 11, 2026, with 5.14.1 slated to ship bundled alongside DISA’s Q2 2026 benchmark drop. Older 4.x installs still haunt disconnected networks where nobody owns the update. SCC is a SCAP 1.3 validated authenticated configuration scanner that also reads 1.0 through 1.2 content. It is free, it is government-owned, and it is the path of least resistance through a package review, which is the actual reason it dominates and not because anyone ran a bake-off.

Outside DoD, the open-source stack is OpenSCAP: the oscap CLI (1.4.x current) plus the scap-workbench GUI, sponsored by Red Hat. The policy content most teams pair with it lives in the ComplianceAsCode project on GitHub, which is the same thing that used to be called the SCAP Security Guide before the 2018 rename (yes, you’ll still see “SSG” in old docs and profile names). Commercial scanners read SCAP too. Tenable’s audit content drives the ACAS program, which is the DISA-run vulnerability program powered by Tenable Security Center (the product Tenable renamed from Tenable.sc and then quietly renamed back). ACAS is your network-side vuln picture; SCC is your host-side config picture. Don’t make one pretend to be the other.

Where it fits in the flow

For DoD RMF under DoDI 8510.01, STIG compliance is required evidence, and SCAP is the automated half of producing it. The manual half is filled by STIG Viewer or Evaluate-STIG for the checks no benchmark can script. CCRI inspections will ask for recent SCAP results, and Cyber Hygiene scorecards fed into CMRS keep the pressure on: stop ingesting and your numbers rot, which someone above you notices before you do.

Cadence in practice runs monthly at a floor for continuous monitoring, weekly on higher-impact boundaries, plus an on-demand run before any significant change or package submission. DISA publishes STIG SCAP benchmarks on a roughly quarterly cadence (Q2 2026 content is current as of this writing), with out-of-cycle drops when a vendor patch forces it. The benchmark itself is just a signed zip of XCCDF, OVAL, and a CPE dictionary.

Deeper: “SCAP-validated product” is doing less work than the mandate language implies, and now it’s doing even less. The seal meant a product passed conformance testing at an NVLAP-accredited lab against NIST IR 7511. With the validation program closed as of late 2025, no scanner earns a new SCAP 1.3 validation, and SCAP 1.4 ships with no validation program behind it at all. The deterministic value was never the seal anyway. It was XCCDF plus OVAL giving two analysts the same answer on the same host. Keep buying for that property. Stop treating the validation checkbox as a live control.

What’s good, what isn’t

The thing SCAP gets right is repeatability. Run the same benchmark on the same host twice and you get the same result, which is more than manual STIG review can promise when two reviewers disagree about what “the system enforces” means. The output drops straight into eMASS test-result imports and into dashboards like STIG Manager and Heimdall. And SCC specifically sidesteps the license argument with the contracting officer.

The complaints are real and you should plan around them.

  • Content lag. The SCAP benchmark trails the manual STIG, often by a quarter. New OS minors (recent RHEL point releases, Server 2025) routinely have no benchmark for months, so you cover them by hand or not at all.
  • Coverage gaps. A typical STIG has automated SCAP coverage for maybe half to two-thirds of its checks. The rest are manual. A team reporting a SCAP pass rate as “STIG compliance” is lying to its AO, full stop.
  • False positives on hardened images. Rules written against a vanilla install fire on a golden image that already remediated the finding a different way. Budget time for justification memos.
  • Tool drift. SCC and OpenSCAP can interpret an ambiguous OVAL test differently and hand you a result delta on the identical content.

That last one is where I’ll plant a flag. Pick one scanner of record per boundary and stick to it. Running SCC on the Windows estate and OpenSCAP on the RHEL fleet is defensible because the platforms differ. Running both against the same hosts and then arguing about which delta is “right” in front of an assessor is a self-inflicted wound. The benchmark is the authority; the scanner is an interpreter, and you do not want two interpreters of record on one system.

Operational notes

Deploy SCC as a local agent on disconnected hosts and as a remote-scan engine where WinRM or SSH is allowed. Don’t run it from a domain-admin context. Use a dedicated scan account with the minimum rights the benchmark needs to read registry, audit policy, and file ACLs. On Linux there’s no dodging root or sudo for a real result.

For eMASS, import ARF or CKL through the test-results API, or route it through STIG Manager as a middle layer because manual CKL editing at scale is how POA&Ms go wrong. Ship the HTML and XML to your log pipeline so trend lines exist (Splunk has a SCAP add-on; the Elastic equivalent works with a parser, just messier on ingest). Auto-open tickets on new fails if you want, but threshold them or you drown the sysadmins on the first run. And if you feed CMRS, confirm whether your ACAS feed or the host-based feed is authoritative, because pushing both produces double-counting an auditor will eventually flag.

Control ties

Where SCAP carries weight Controls What the evidence actually shows
Configuration settings CM-6, CM-2, CM-7 Benchmark rules prove required settings, baseline config, and least functionality are enforced on the host
Vulnerability monitoring RA-5 Patch and version checks surface missing remediation, feeding the vuln program
Flaw remediation SI-2 Pass/fail deltas over time show whether fixes actually landed
Audit configuration AU-2 Audit-policy settings verified as configured, not just claimed

SCAP does not satisfy any of these on its own. It produces machine-readable evidence; a human still reads it and an assessor still grades it. It is config and compliance content, which is why SA-11, SA-15, and the SR supply-chain controls are out of scope here. Those live with developer testing and SBOM tooling, not a host config scan.

SCAP is the connective tissue between a policy written in English and a host you can prove is set up the way the policy demands. Run SCC because the government already paid for it, pair it with manual coverage because the benchmark is incomplete, and pipe the ARF into something an AO can read. Anything short of that is a checklist exercise wearing the costume of assurance.

Sources

Adjacent material on this site