What is a STIG?

A Security Technical Implementation Guide (STIG) is a product-specific set of configuration requirements, each with a check procedure and a fix, that the Defense Information Systems Agency (DISA) publishes for Department of Defense (DoD) systems. DISA's General Purpose Operating System Security Requirements Guide overview, Version 3, Release 4, dated September 30, 2026, quotes DoD Instruction (DoDI) 8500.01: all information technology that handles DoD information must be configured consistent with DoD cybersecurity policies. The same instruction tasks DISA to develop and maintain STIGs. DoDI 8510.01, of July 19, 2022, has the DISA Director keep them consistent with National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 controls.

SRGs, STIGs, and CCIs

The overview sets out three layers. A Control Correlation Identifier (CCI) is a discrete, measurable item drawn from a policy control, such as one in SP 800-53. A Security Requirements Guide (SRG) collects the requirements for a technology family. A STIG gives the product-specific information for meeting the SRG for that product's technology area.

There are four core SRGs: Application, Network, Operating System, and Policy. Technology SRGs sit beneath them. The overview's example runs from the Application SRG to the Database SRG to a STIG for one database product. The STIG holds the product-specific checks and fixes, and an SRG carries general ones for products that have no STIG.

One guide never covers a whole system. The overview says compliance with all SRGs and STIGs applicable to a system is required, for example database, web server, and Domain Name System guides together.

The DISA STIGs frequently asked questions (FAQ) page, as captured in July 2025, adds two points. When no STIG exists, the most relevant SRG can be used, and a product may still be deployed based on mission need and with approval. DISA does not certify products for DoD use. SRGs and STIGs help deploy products securely.

CAT I, CAT II, and CAT III findings

Every requirement carries a Severity Category Code, written CAT. The overview defines the three codes:

• CAT I: any vulnerability whose exploitation "will directly and immediately" result in loss of confidentiality, availability, or integrity.
• CAT II: any vulnerability whose exploitation has a potential to result in that loss.
• CAT III: any vulnerability whose existence degrades measures that protect against that loss.

The Application Security and Development (ASD) STIG, Version 6, Release 5, dated September 30, 2026, shows how the codes are stored. The rules in the package's XML file carry a severity of high, medium, or low, and the stylesheet shipped with it displays these as CAT I, CAT II, and CAT III. The file holds 286 rules: 34 CAT I, 230 CAT II, and 22 CAT III.

Rule V-222536 in the ASD STIG has STIG ID APSC-DV-001680, a rule ID, and two CCIs, CCI-004066 and CCI-000205. The rule is CAT I: the application must enforce a minimum 15-character password length.

The check is a procedure. If the application uses no passwords, the rule is not applicable. Otherwise the assessor tries to create a password shorter than 15 characters, and if that works, "this is a finding." The fix is one line: configure the application to require 15 characters.

Rules are published in the Extensible Configuration Checklist Description Format (XCCDF), with an overview and a revision history in each package.

Checking a system: SCAP and STIG Viewer

The Security Content Automation Protocol (SCAP) is NIST's suite of specifications for expressing and processing security configuration and vulnerability information in machine-readable form. It includes XCCDF, the Open Vulnerability Assessment Language (OVAL), and Common Platform Enumeration (CPE). SP 800-126 Revision 3, February 2018, defines SCAP version 1.3, and NIST is developing version 1.4. The DISA FAQ says its SCAP 1.2 benchmarks bundle the XCCDF, OVAL, and CPE parts into a single data stream file.

The STIG Viewer 3.x User Guide, Version 1, Release 8, dated August 13, 2026, describes the review. STIG Viewer displays XCCDF STIGs and builds checklists. It imports automated SCAP or XCCDF results, and the reviewer completes the manual portion. Each rule is marked Open, Not a Finding, Not Applicable, or Not Reviewed. Changing a rule's severity requires an override reason. Checklists export as HTML, CSV, or DISA's own checklist formats.

From findings to an authorization

SP 800-53 Revision 5 names STIGs as common secure configurations under control CM-6, Configuration Settings. The control asks an organization to set the most restrictive settings consistent with operational requirements, and to identify, document, and approve any deviations. The discussion says SCAP provides an effective way to identify, track, and control those settings.

The GPOS overview ties this to the authorization to operate (ATO). STIGs give a basis for assessing compliance with controls, which supports assessment and authorization under the Risk Management Framework. The risks of not applying specified settings must be approved by the responsible authorizing official (AO). AOs decide product use through risk acceptance. The ASD overview adds that a report on items that did not meet requirements, marked Controlled Unclassified Information (CUI), is available to AO personnel on request.

The overview also sets limits. Settings should be tested in a representative environment before production. DISA implies no warranty that applying every specified setting will make a system 100 percent secure.

What to check

• Which STIG and SRG versions and releases were used, and do they match the products actually installed?
• Does the system have every STIG that applies to it, or only the operating system's?
• How many CAT I findings remain open, and what has the AO approved for each?
• Were results combined from automated SCAP scans and the manual checks, with no rule left Not Reviewed?
• Were any severities overridden, and is the override reason recorded?
• Where no STIG exists, which SRG was used, and who approved deployment?

Azcuna's TRACE is one offline viewer for S1000D, MIL-STD-3001 XML, and PDF technical manuals. It keeps the source location and the markings of everything it shows and never modifies the source. It was proposed to NAVAIR under Navy SBIR Phase I topic DON26BZ05-NV078, and the proposal was submitted on September 23, 2026.

Sources

1. 1General Purpose Operating System (GPOS) Security Requirements Guide Overview, Version 3, Release 4 (zip download) · Defense Information Systems Agency, September 30, 2026
2. 2Application Security and Development (ASD) STIG, Version 6, Release 5 (zip download) · Defense Information Systems Agency, September 30, 2026
3. 3STIG Viewer 3.x User Guide, Version 1, Release 8 · Defense Information Systems Agency, August 13, 2026
4. 4STIGs Frequently Asked Questions · DoD Cyber Exchange, DISA (read from the July 12, 2025 Internet Archive capture)
5. 5Security Content Automation Protocol (SCAP) · NIST Computer Security Resource Center
6. 6SP 800-126 Rev. 3, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.3 · National Institute of Standards and Technology, February 2018
7. 7NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations · National Institute of Standards and Technology, September 2020, includes updates as of December 10, 2020
8. 8DoD Instruction 8510.01, Risk Management Framework for DoD Systems, July 19, 2022 · Office of the DoD Chief Information Officer (Directives Division copy, read from the October 12, 2026 Internet Archive capture)

Where this shows up in our work

• ELLMENT, the offline LLM for E-2D crews answers a crew's question from the aircraft's own manuals and cites the page, with no network.
• BABEL, offline multilingual translation and search translates and searches foreign-language documents on-device, every fact tied to its source passage.
• TRACE, the offline S1000D and IETM viewer opens S1000D, MIL-STD-3001 and PDF technical manuals on a tablet with every marking intact.