The ASD STIG, in plain English

The Application Security and Development (ASD) STIG is DISA's hardening standard for custom-built software rather than for an operating system or a shipped product. It asks how your team designs, codes, tests, deploys, and maintains an application, and expects evidence, not intent.

Who it applies to

Any application developed for or operated on a DoD network: web apps, APIs, mobile clients, and the pipelines that build them. Unlike an OS STIG, most ASD requirements can't be satisfied by a configuration switch, they're satisfied by a documented practice plus proof it happened (design documents, test results, code-review records, threat models).

What it actually covers

• Design and architecture: threat modeling, data classification, boundary definition.
• Authentication and session handling: CAC/PKI support, session timeouts, credential storage.
• Input validation and output encoding: the injection and XSS families.
• Cryptography: FIPS-validated modules, TLS configuration, key handling.
• Audit logging: what is recorded, protected from tampering, and retained.
• Software supply chain: dependency inventory, vulnerability scanning, patch cadence.
• Deployment and maintenance: hardened configs, change control, decommissioning.

Common pitfalls

• Treating it as a scan. Automated tooling can only touch a slice of the ASD STIG; the rest is manual review with artifacts attached.
• Marking rules Not Applicable too eagerly. "We don't do that" is not an N/A justification, N/A needs a technical reason the requirement cannot apply.
• Undocumented third-party code. Dependencies inherit the same requirements; an unlisted library is a finding on its own.
• Crypto that isn't FIPS-validated. Strong algorithms in a non-validated module still fail the check.
• Logs without integrity protection. Recording the event isn't enough if the record can be edited.

Remediation strategies

1. Sort by CAT severity first, CAT I items block an authorization decision.
2. Group rules by the artifact that satisfies them; one threat model or one pipeline change often closes a dozen findings.
3. Push checks left into CI so future builds can't regress a closed finding.
4. Capture the evidence at the moment of remediation, while the change is fresh.
5. Route what can't be fixed this cycle into a POA&M with an owner and a date.

Mapping to NIST 800-53

Each ASD rule carries CCIs that resolve to 800-53 controls, mostly the SA (System and Services Acquisition), SI (System and Information Integrity), IA, and AU families. Answering an auditor in control language, rather than rule IDs, is usually the faster conversation.