Software Hardening Checklist for Classified Environments

Pre-deployment security checklist for software destined for TS/SCI enclaves and airgapped networks.

This checklist covers the critical security verification steps required before deploying software into TS/SCI enclaves, airgapped networks, and other classified environments. Each item must be verified and documented as part of your pre-deployment authorization package.

Binary Analysis and Verification

  • Have all compiled binaries been analyzed with static analysis tools to identify known vulnerability patterns, unsafe function calls, and memory safety issues?
  • Are cryptographic hashes (SHA-256 at minimum) generated for every binary and verified against a trusted manifest before deployment?
  • Has binary provenance been established, confirming the build pipeline from source code to final artifact is tamper-evident and reproducible?

Dependency Audit and Supply Chain

  • Have all third-party dependencies been inventoried in a Software Bill of Materials (SBOM) that includes version numbers, licenses, and known vulnerabilities?
  • Are dependencies pinned to specific, audited versions with hash verification, and are automatic updates disabled for classified deployments?
  • Has each dependency been evaluated against the NIST National Vulnerability Database (NVD) and your organization’s approved software list?

Network Isolation Testing

  • Has the software been tested in a network-isolated environment to confirm it operates correctly without external connectivity?
  • Are all outbound network calls identified and documented, with confirmed behavior when those calls are blocked or unreachable?
  • Have DNS, NTP, and other infrastructure dependencies been mapped, and are fallback mechanisms in place for airgapped operation?

Cryptographic Compliance (FIPS 140-2/3)

  • Are all cryptographic modules used by the software FIPS 140-2 or FIPS 140-3 validated, with current certificates listed on the CMVP validated modules list?
  • Has the software been tested with FIPS mode enabled at the operating system level to confirm no non-compliant cryptographic algorithms are invoked at runtime?
  • Are key management procedures documented, including generation, storage, rotation, and destruction, all using FIPS-approved methods?

Logging and Audit Trail

  • Does the software generate audit logs that capture security-relevant events including authentication attempts, privilege changes, data access, and configuration modifications?
  • Are log formats structured (syslog, CEF, or JSON), timestamped with a reliable source, and compatible with the target environment’s SIEM or log aggregation infrastructure?
  • Are audit logs protected from tampering, with write-once mechanisms or cryptographic integrity verification to ensure evidentiary value?

Privilege Escalation Prevention

  • Does the software run with the minimum privileges necessary for operation, and has the principle of least privilege been verified through runtime analysis?
  • Are all setuid/setgid binaries, capabilities, and privileged system calls documented and justified, with no unnecessary elevation paths?
  • Has the software been tested against common privilege escalation techniques, including path traversal, symlink attacks, and shared memory exploitation?

Data-at-Rest Encryption

  • Is all persistent data written by the software encrypted at rest using FIPS-validated algorithms (AES-256 at minimum)?
  • Are encryption keys stored separately from encrypted data, with access controls that prevent unauthorized key retrieval?
  • Are temporary files, caches, swap space, and crash dumps handled securely, with encryption or secure deletion to prevent data remnant exposure?

Runtime Integrity Monitoring

  • Are runtime integrity mechanisms in place to detect unauthorized modification of the software’s executable code and critical configuration files?
  • Does the software support or integrate with host-based intrusion detection systems (HIDS) deployed in the target environment?
  • Are anomalous runtime behaviors — unexpected process spawning, unusual memory allocation patterns, unauthorized file system access — detected and logged with alerting capability?

Next Steps

This checklist should be completed and documented as part of your software authorization package. Gaps identified during this review must be remediated and re-verified before deployment authorization is granted.

For expert assistance with software hardening, penetration testing, or security assessment for classified deployments, book a Security and Compliance Assessment with our team.