On August 1, 2024, CISA released the Software Acquisition Guide for Government Enterprise Consumers, a document aimed at helping federal acquisition and procurement staff evaluate the security of the software they buy. If you sell software — or software-enabled services — to the government, this guide is a preview of the questions headed your way.
What the Guide Is
The guide was produced by the Information and Communications Technology (ICT) Supply Chain Risk Management Task Force, co-led by CISA and industry. Its core insight is a familiar gap: acquisition staff understand the *contracting* side but often cannot assess whether a given supplier actually follows secure development practices. The guide gives them a structured set of questions to ask their own CISOs, risk owners, and — ultimately — their vendors.
It is built around CISA's "Secure by Design" principles: the idea that security should be engineered into software from the start, not bolted on after delivery, and that the vendor — not the customer — should carry the larger share of that burden.
How It Connects to the Secure Software Attestation Form
This guide does not stand alone. Earlier in 2024, CISA finalized a secure software development attestation form, and the White House directed agencies to obtain that completed attestation from software producers before purchase. The new guide is written to align with the attestation form, helping buyers turn a signed form into informed follow-up questions.
For contractors, the practical chain is: the government must collect an attestation that your software was built using specified secure-development practices (drawn from NIST's Secure Software Development Framework), and now acquisition staff have a playbook for probing what is behind that attestation.
Why This Matters for Contractors
A few things follow directly:
- Attestations carry weight. Signing a secure-development attestation is a representation to the government. As the Guidehouse/Nan McKay settlement shows, misrepresenting your cybersecurity posture on a federal contract can become False Claims Act exposure.
- Expect deeper diligence. The guide pushes buyers past the checkbox toward questions about your build pipeline, vulnerability handling, and third-party components.
- This is the FAR Council's runway. CISA framed the guide as a bridge while the FAR Council works on a long-anticipated software security rule. Getting your house in order now is cheaper than scrambling when the clause lands.
What to Do Now
- Read the attestation form and SSDF practices and honestly assess where you stand against them.
- Document your secure-development lifecycle — source control, code review, vulnerability management, and software bill of materials (SBOM) practices.
- Prepare to answer vendor questions about third-party and open-source components.
- Align proposals with reality. Describe the security practices you actually follow, not aspirational ones.
Key Takeaways
- CISA's guide arms government buyers with security questions for software vendors.
- It is tied to the secure software attestation requirement — and an attestation is a representation you must be able to back up.
- A formal FAR software security rule is coming; prepare your secure-development evidence now.
Build the underlying program with our Build a Compliance Program guide, or see how frameworks fit together on the Frameworks page.