A Secure Software Development Attestation Form is a standardized federal form used by software producers to attest that software provided to the U.S. Government was developed using specified secure software development practices. The form grew out of federal software supply chain security requirements established after Executive Order 14028 and subsequent Office of Management and Budget guidance.
The attestation is intended to give agencies consistent information about software development practices without requiring the government to independently examine every part of a vendor’s development environment. It is closely connected to the NIST Secure Software Development Framework (SSDF), which establishes a common set of secure development practices designed to reduce vulnerabilities in released software and address their root causes.
Why the Federal Government Uses Software Attestations
Federal agencies depend heavily on commercial and contractor-developed software. A vulnerability introduced during development can affect multiple government systems, particularly when the same software is deployed across several agencies. Federal software security policy has therefore increasingly focused on how software is developed, not only on security controls applied after deployment.
Executive Order 14028, Improving the Nation’s Cybersecurity, issued in May 2021, directed NIST to develop guidance identifying practices that enhance software supply chain security. NIST subsequently published SP 800-218, Secure Software Development Framework Version 1.1, in February 2022. The framework provides practices that software producers can integrate into different software development life cycles.
The SSDF is organized around four groups of practices:
- Prepare the Organization (PO);
- Protect the Software (PS);
- Produce Well-Secured Software (PW);
- Respond to Vulnerabilities (RV).
These groups cover areas such as defining security requirements, protecting development environments and source code, reviewing software for vulnerabilities, securely archiving releases, collecting vulnerability reports, and addressing vulnerabilities after release.
OMB Memorandum M-22-18, issued in September 2022, established federal requirements concerning the use of software developed using secure software development practices. OMB subsequently issued M-23-16 in June 2023 to update the implementation schedule and clarify aspects of the attestation process.
The resulting attestation approach gives agencies a standardized way to obtain a software producer’s statement concerning applicable development practices. It does not replace vulnerability management, agency risk assessments, testing, or other software security activities.
What a Software Producer Attests To
The Secure Software Development Attestation Form is not simply a statement that software is “secure.” Absolute software security cannot realistically be established through a single certification. Instead, the producer attests to specified practices used in developing the software.
The federal common form asks the software producer to attest that the software was developed in conformity with specified secure software development practices. These practices are based on NIST guidance and focus on the development environment, software integrity, vulnerability identification, and vulnerability remediation.
Key areas addressed by the attestation include practices related to:
- separating and protecting development environments;
- controlling access to development environments;
- maintaining provenance information for internal and third-party software components;
- employing automated tools or comparable processes to identify security vulnerabilities;
- operating processes for disclosing and remediating discovered vulnerabilities;
- maintaining policies and procedures that support secure software development.
The producer is not necessarily attesting to every task contained in the entire SSDF. The federal attestation is structured around specific practices identified through applicable federal policy and the common form.
This distinction matters because NIST SP 800-218 is a broad framework intended to help organizations improve secure software development. NIST describes the SSDF as outcome-based and designed so that its practices can be integrated into different software development life cycle models.
NIST is also continuing to develop the SSDF. Version 1.1 remains the final version of SP 800-218, while NIST published an initial public draft of SP 800-218 Revision 1, SSDF Version 1.2, in December 2025. Contractors should distinguish between final federal requirements and draft technical guidance rather than assuming that every newly proposed NIST practice immediately changes an existing attestation obligation.
Attestation, SBOM, and Other Software Security Evidence
The Secure Software Development Attestation Form is one part of a broader federal approach to software supply chain security. It should not be confused with an SBOM, vulnerability report, penetration test, or security certification because each provides different information.
| Document or Evidence | What It Addresses | What It Does Not Establish |
|---|---|---|
| Secure Software Development Attestation | Whether the producer attests to specified secure development practices | That the software has no vulnerabilities |
| SBOM | Components, libraries, and dependencies contained in software | That secure development practices were followed |
| Vulnerability Assessment | Identified weaknesses in a product or system | Complete software component provenance |
| Security Testing Results | Results of specific security tests | Compliance with every secure development practice |
An SBOM, for example, can identify third-party libraries and dependencies contained in a software release. That information can help an agency determine whether a newly discovered vulnerability affects components used in the product. The attestation addresses a different question: whether the producer followed specified practices during software development.
The same distinction applies to vulnerability scanning. Automated security tools may help satisfy parts of a producer’s secure development process, but the scan results themselves are not equivalent to an attestation.
Federal agencies can also request additional documentation when appropriate. Depending on the acquisition and applicable policy, this could include artifacts supporting the producer’s attestation or other information needed to evaluate software supply chain risk.
Software producers should therefore avoid treating the common form as the entire federal software security review. It is better understood as standardized evidence about a defined set of development practices within a larger acquisition and cybersecurity process.
Who Completes the Attestation and When It May Be Required
The attestation is completed by the software producer rather than automatically by the reseller or federal agency purchasing the software. This is logical because the producer is the organization with direct knowledge of the development practices used to create the product.
This distinction can become important in GSA contracting. A Schedule contractor or reseller may sell software developed by another company. The reseller may manage the government transaction, but it generally does not control the software producer’s source code repositories, development environments, build pipelines, vulnerability remediation processes, or other activities addressed by the attestation.
Software producers should first determine whether the software and acquisition fall within applicable federal attestation requirements. The exact obligations depend on current federal policy, agency implementation, the nature of the software, and the acquisition.
A practical preparation process can include:
- Identify the software products and versions supplied to federal agencies.
- Determine which products are subject to applicable attestation requirements.
- Map existing development practices to the practices addressed by the federal form.
- Identify gaps between current processes and the practices being attested to.
- Maintain evidence supporting the company’s representations.
- Establish responsibility for approving and signing attestations.
- Review attestations when products or development practices materially change.
The individual signing the form should have appropriate authority to make the representation on behalf of the software producer. Companies should therefore coordinate legal, cybersecurity, engineering, product, and federal contracting personnel rather than treating the form as a routine sales document.
The distinction between software versions can also matter. Development processes, components, build environments, and security practices can change over time. Contractors should ensure that information submitted to an agency accurately corresponds to the software covered by the attestation.
What an Attestation Does Not Mean
One of the most important aspects of the Secure Software Development Attestation Form is understanding its limitations. An attestation is a representation about development practices. It is not a federal guarantee that software cannot be compromised.
Even software produced under mature security processes can contain vulnerabilities. NIST explains that the SSDF is intended to help reduce the number of vulnerabilities in released software, reduce the potential impact of exploitation of vulnerabilities that remain, and address root causes so vulnerabilities are less likely to recur. It does not claim that following the framework eliminates all software vulnerabilities.
An attestation therefore does not automatically mean that:
- the software contains no known or unknown vulnerabilities;
- every component in the product is free of security issues;
- the government has independently verified every development practice;
- an SBOM is unnecessary when one is separately required;
- vulnerability monitoring can stop after the form is submitted;
- the software automatically satisfies every cybersecurity requirement in a federal contract.
This is especially relevant for continuously updated SaaS products. A vendor can follow secure development practices while still discovering vulnerabilities after deployment. Effective software security requires processes for identifying, reporting, prioritizing, and remediating those vulnerabilities throughout the product lifecycle.
Attestation also differs from certification. The producer is making representations concerning its own development practices. Contractors should avoid marketing language suggesting that submission of the form means a software product has received a universal federal security certification.
What GSA Contractors and Software Vendors Should Prepare
GSA contractors that sell software should determine early whether they are the software producer, a reseller, an integrator, or some combination of these roles. The distinction affects what information they control and how they can obtain required attestations.
A contractor reselling third-party software may need to coordinate with the producer to obtain the appropriate documentation. An integrator providing a solution containing several software products may need to understand which components are subject to the relevant requirements. A company developing its own software has a more direct responsibility for ensuring that its development practices support the representations being made.
Contractors should maintain an organized record of federal software products, producers, versions, attestations, and supporting documentation. This becomes increasingly important for companies with large software catalogs because different products may be developed by different organizations and updated on different schedules.
The attestation process should also be connected to software development rather than handled only when a contracting officer requests a form. Engineering and security teams need to know which practices the company is representing, while contracting personnel need to understand whether the representations remain accurate for the software being offered.
NIST’s SSDF is particularly useful for this internal preparation because it gives producers a common vocabulary for secure development activities. The framework is designed to be incorporated into existing development methodologies rather than requiring companies to replace Agile, DevOps, waterfall, or other software development life cycle models.
For GSA contractors, the practical significance of the Secure Software Development Attestation Form is therefore broader than submitting another compliance document. The form connects federal acquisition with the actual processes used to build and maintain software. Contractors that understand their software supply chains, maintain evidence of development practices, coordinate with third-party producers, and review current agency requirements are better positioned to provide accurate attestations when federal customers require them.
