Safeguard
Security Guides•

How do you prove your build environment is secure to a government buyer?

The CISA form listed six actions for secure development and build environments. For each, a plain meaning and the evidence a buyer or assessor can inspect.

Safeguard Security Team
3 min read

Prove it with inspectable evidence for each of the six actions the CISA attestation form listed: separated environments, audited trust relationships, MFA with conditional access, minimized risky software, encrypted credentials, and monitored defenses. Exports and logs beat descriptions. The form itself no longer binds agencies, but the six items remain a sensible baseline.

The six items and what to show

The form said environments for developing and building software are secured by these actions "at a minimum."

Form itemPlain meaningEvidence a reviewer can inspect
Separate and protect each environmentDev, build and release do not share access freelyNetwork and account diagram; separate project or account listing
Log, monitor and audit trust relationshipsYou know which identities and systems can reach build systems and each otherAccess reports, service account inventory, log retention setting, a dated review record
MFA and conditional accessStrong sign-in everywhere relevant to building softwareIdentity provider policy export covering source control, CI and artifact stores
Document and minimize risky software in these environmentsYou track tools in the build environment and drop those that create undue riskTool inventory with owner and reason, removal tickets
Encrypt sensitive data such as credentialsSecrets are stored encrypted, to the extent practicable and based on riskSecrets manager configuration, secret scanning results
Defensive practices incl. continuous monitoringAlerts are watched and incidents are handledAlert routing rules, an incident runbook, a recent exercise record

The form's own hedges, "to the extent practicable" and "consistent and reasonable steps," show it expected judgment based on risk. That is not an excuse to leave a row empty.

SSDF tasks behind it

CISA's appendix mapped these items mainly to SSDF tasks PO.5.1 and PO.5.2, with PO.3.2 and PO.3.3 for the monitoring item. If a buyer cites those task numbers, this is the area they mean.

A one day exercise

  1. Pick your most important product's pipeline.
  2. Walk the six rows and collect one artifact per row.
  3. Write a one line gap note where you have none.
  4. Assign owners and a review date.

The result doubles as the first draft of an evidence index.

Common weak spots

  • Service accounts and tokens that never expire.
  • CI runners shared across trust levels.
  • MFA enforced for staff but not for bots with broad rights.
  • Logs kept for a short time or in the same place an attacker could erase.

Try it yourself

Click through it at your own pace, or open it full screen.

See how a failed check blocks a merge. Enforced rules in the pipeline are better evidence than a written intention.

Quick check

Is the form still in force?

OMB rescinded the memos behind it, but CISA's page notes agencies may still choose to use it. Check your own contracts.

Do all six apply to a small team?

The wording allows risk-based judgment, so scale the method. Keep evidence for each row.

Safeguard provides policies, gates and guardrails, asset discovery and compliance and evidence automation, which can collect some of this evidence. The free scan is at gold.safeguard.sh/scan.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.