// Capability Statement — Download PDF
Insights / STIGs
STIGs

STIG'd: hardening as a pipeline, not a punishment.

What Security Technical Implementation Guides are, why manual compliance decays, and how automation turns hardening into a system property.

Ausper Technology · July 20, 2026 · Insight · STIGs · Hardening

A STIG — Security Technical Implementation Guide — is DISA's hardening checklist for a specific technology: hundreds of configuration rules for your OS, database, browser, or network device, each with a severity (CAT I/II/III) and a check-and-fix procedure. 'Get STIG'd' is the standing order of DoD system administration.

Why they hurt

Volume and drift. A single RHEL server carries hundreds of rules; an environment carries thousands of rule-instances. Manual hardening takes days per system and decays immediately — every patch, every change re-opens findings. Programs that treat STIGs as a quarterly manual event live in permanent catch-up.

The way out

Automate application: Ansible or comparable tooling applies baselines identically, every time. Automate verification: SCAP scans on schedule, results flowing into your POA&M and dashboards automatically. Handle deviations formally: some rules legitimately can't apply — document the deviation, the mitigation, and the approval once, instead of re-arguing it every assessment. Hardening becomes a pipeline property, not a heroic act — which is precisely what continuous ATO requires.

Common questions

What is a STIG?
A Security Technical Implementation Guide: DISA’s configuration standard for a specific product — an operating system, a database, a browser, a network device. Each is published as a checklist of individual requirements rated CAT I, II or III by severity, and assessed with tooling that reports each one as open, not applicable, or not a finding.
Why does manual STIG compliance decay?
Because a hand-hardened host is only correct on the day someone hardened it. Patches reset settings, application installs change them deliberately, and ordinary administration drifts them one exception at a time. Nothing notices until the next scan, which is why a system that passed at assessment routinely fails months later without anyone doing anything wrong.
How do you automate hardening?
Put the configuration in the image rather than in a runbook, enforce it with configuration management so drift is corrected rather than discovered, and scan inside the pipeline so a non-compliant build never reaches an environment. Once that holds, a drifted host stops being an incident to investigate and becomes an instance to replace.

Related reading

DevSecOps in federal Continuous ATO POA&M management Zero Trust AscendBridge™
Put this to work

Need it done, not just explained?

This is the work we do every day. Tell us where your program stands and we'll give you a straight answer.

Talk to Ausper