Skip to main content

Security & STIG Posture

Foundry baselines are hardened against the DISA Application Security and Development (ASD) STIG. The goal is straightforward: put inheriting teams chasing an Authority to Operate (ATO) in the strongest possible position when they fork.

Why ASD STIG​

ASD STIG is the application-layer Security Technical Implementation Guide published by the Defense Information Systems Agency. It covers controls that live in application code — session handling, input validation, authentication, cryptography, audit logging, data handling — as opposed to platform STIGs that govern the OS, container runtime, or network.

Most agent systems we build sit on top of a platform that already has its own STIG coverage. The application layer is where teams are usually on the hook for original work. By assessing every Foundry baseline against ASD STIG up front, we give adopters a head start on the controls that are theirs to satisfy.

The inheritance model​

Every STIG finding in a Foundry baseline carries a responsibility tag:

TagMeaning
baselineThe control is satisfied (or knowingly not satisfied) inside this repo's code. Adopters inherit it.
deliveryThe control belongs to the team operating the deployment — runtime configuration, infrastructure, organizational policy.
sharedBoth sides have work to do. The baseline does what it can in code; the adopter fills the rest.

When you fork a baseline, you only need to address delivery and shared controls in your overlay. The baseline work is already done.

Where the checklists live​

Each baseline ships a machine-readable assessment alongside its code:

Each finding records:

  • vuln_id, rule_id, stig_id — DISA identifiers
  • severity — low, medium, or high
  • status — one of:
    • meets_requirement — control is satisfied
    • non_compliant — control applies and is not yet satisfied
    • not_applicable — control does not apply to this baseline's surface area
    • needs_human_review — assessor flagged for follow-up
  • responsibility — who owns satisfying it (above)
  • finding_details and comments — what was checked, what was found

This is the same structure the Foundry team uses internally. Adopters get the full assessment, not a sanitized summary.

How to use this as an adopter​

The checklist is a recommended template, not a hard requirement.

  • If you're pursuing ATO or a regulated deployment: fork the JSON alongside the code. Keep it current as your codebase diverges from the baseline. Treat the responsibility: delivery and shared entries as your ATO punch list.
  • If you have no compliance obligation: you can tailor the checklist to your context or remove the security/ directory entirely. Nothing in the baseline's runtime depends on it.

Refresh cadence​

The Foundry team re-assesses each baseline as part of routine maintenance. Coding agents drive the assessment via internal foundry-stigkit tooling, but the resulting checklist is plain JSON — adopters can refresh it manually or with their own tooling. Each baseline's security/README.md documents the refresh workflow used to produce the checked-in version.