US government contractor: what should engineering fix first?

An engineering team serving the US government should first read which clauses are in the contract, then fix in this order: basic safeguarding of contractor systems, protection of controlled unclassified information against NIST SP 800-171, and secure development evidence tied to NIST SP 800-218 and the CISA attestation form.

Which obligations apply to you?

Three families show up most often, and a contract may carry one, two or all three.

The first is FAR clause 52.204-21, Basic Safeguarding of Covered Contractor Information Systems. The acquisition.gov text defines a covered contractor information system as one owned or operated by a contractor that processes, stores or transmits federal contract information. Its requirements are basic hygiene: limit access to authorized users, processes and devices, verify and control connections to external systems, control information on publicly accessible systems, identify and authenticate users and devices, and sanitize or destroy media.

The second is protection of controlled unclassified information. NIST SP 800-171 Revision 3, published May 2024, provides security requirements for protecting the confidentiality of CUI in nonfederal systems. NIST says the requirements apply to components of nonfederal systems that process, store or transmit CUI, and are intended for use by agencies in contracts and similar agreements. Which revision a contract cites matters, so read the clause text rather than assuming.

The third, if you sell software to federal agencies, is secure development. CISA's Secure Software Development Attestation Form is based on NIST SP 800-218, the Secure Software Development Framework. CISA's page says agencies may use the form and may also require a current SBOM from software producers on request.

This article explains the frameworks. Whether a clause binds you is a contract and legal question.

What should engineers do first?

Start with scoping, because every control costs less when the boundary is small. Find where federal contract information or CUI actually lives: repositories, ticketing, email, build logs, backups, laptops. Many teams discover a stray export in a shared drive.

Then work through the basics that auditors and agencies check first, since they are cheap and visible:

• Accounts: unique users, multi factor authentication, removal of leavers within a defined time, no shared admin logins.
• Devices: an inventory, disk encryption, patching, and a way to remove access from a lost laptop.
• Data handling: encryption in transit and at rest for in scope data, and a media disposal step.
• Logging: who accessed what, kept long enough to investigate.
• Boundaries: segment the in scope environment from the rest of the company.

What does secure development evidence look like?

The SSDF is a core set of high level practices that NIST says should reduce vulnerabilities in released software and address root causes. The CISA Product Security Bad Practices guidance gives engineering teams concrete targets, including avoiding default passwords, publishing a vulnerability disclosure policy, avoiding known insecure cryptographic functions and hardcoded credentials, and maintaining an SBOM in a machine readable format.

Evidence is mostly artifacts you already produce if the pipeline is set up: review records, test and scan results, SBOMs per release, a patch log, and your vulnerability disclosure policy page.

Constructed example

A twelve person firm wins a subcontract that flows down the basic safeguarding clause and later learns a customer will handle CUI. The team draws a boundary around one cloud account and one laptop group, moves the data out of a shared drive, turns on multi factor authentication everywhere, writes an asset list, and starts attaching an SBOM to each release. When the prime asks for evidence, the pack is a folder of exports, not a scramble.

What to do

1. Read the contract clauses and list every cited standard and revision. Ask the contracting officer or counsel about gaps.
2. Define the in scope boundary and data flows.
3. Close the basic hygiene items above and keep dated evidence.
4. Map your controls to NIST SP 800-171 requirements and record gaps in a plan with owners.
5. Build secure development evidence into CI: scans, SBOM, review gates, patch SLAs.
6. Publish a vulnerability disclosure policy.
7. Rehearse an incident and learn the reporting duties in your contract.
8. Safeguard offers compliance automation and SBOM and dependency scanning that can help collect this evidence. It does not certify you.

Quick check

Sources

• FAR 52.204-21, acquisition.gov
• NIST SP 800-171 Rev. 3
• NIST SP 800-218, SSDF Version 1.1
• CISA Secure Software Development Attestation Form
• CISA Product Security Bad Practices

Last reviewed: 18 October 2026.