If you are one of the thousands of government contractors that sells or licenses software to U.S. federal agencies, your company will soon be required to attest that it develops its software products and components using practices derived from the "secure software development framework" set by the National Institute of Standards and Technology (NIST) in NIST Special Publication 800-218. Born from Executive Order (E.O.) 14028 (Improving the Nation's Cybersecurity) and two subsequent Office of Management and Budget (OMB) memoranda (OMB Memo M-22-18 and OMB Memo M-23-16), the new attestation requirement will be implemented by federal agencies using a "common form," published this week by the Cybersecurity and Infrastructure Security Agency (CISA).

The new attestation requirement comes at a time when False Claims Act (FCA) enforcement actions under the Department of Justice's (DOJ) Civil Cyber-Fraud Initiative are on the rise (recent examples here and here). That creates significant compliance risk for software providers who now face the prospect that the government will not only stop using their products, but also allege that they provided false or misleading information in an attestation form. Compounding this compliance risk, software providers may also be short on time to complete the diligence needed to support an attestation. While CISA did not identify a deadline for companies to submit the form, OMB has directed agencies to collect attestations within three to six months and the Federal Acquisition Regulation (FAR) Council appears poised to issue a new rule to incorporate the requirement in new and existing contracts (FAR Case No. 2023-002, Supply Chain Software Security). This may leave companies with a narrow window to assess and make any necessary adjustments to their current software development processes.

CISA's Secure Software Development Attestation Form

According to CISA, the purpose of the new attestation form is "to provide the Federal Government assurances that software used by [federal] agencies is securely developed." CISA Form Instructions at 1. This is consistent with OMB's latest guidance on the subject, which "provides that a Federal agency may use software [subject to secure development] requirements only if the producer of that software has first attested to compliance with Federal Government-specified secure software development practices drawn from the [secure software development framework]," or SSDF. See id. at 2. The attestation form "identifies the minimum secure software development requirements a software producer must meet, and attest to meeting," before their covered software may be used or acquired by federal agencies. See id. 

The form and its accompanying instructions also provide insight on several key questions. 

FAQ #1: What Software Is Covered by the Attestation Requirement?

The new attestation requirement extends to a broad range of critical and other (see NIST FAQ #10) "software," including "firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software." See OMB Memo M-23-16 at 2. Attestation will be required for: (1) software developed after September 14, 2022; (2) software developed before September 14, 2022, but which has since undergone "major version changes"; and (3) software for which the producer delivers continuous changes to the software code, such as software-as-a-service (SaaS) products and other products using continuous delivery/deployment models. See CISA Form Instructions at 2-3. Software producers can make attestations on a company-wide basis or for individual or multiple products or product versions. See id. at 5.

FAQ #2: What Software Is Not Covered by the Attestation Requirement?

The government will not require attestations for: (1) software produced by federal agencies; (2) open-source software that is freely and directly obtained by a federal agency; (3) third-party open source and proprietary components that are incorporated into the software end-product used by the agency; or (4) software that is freely obtained and publicly available. See CISA Form Instructions at 3.

Providers of commercially developed software, which commonly draws from open and public sources, should pay extra attention to the exception for third-party open source and proprietary components that are incorporated into software end products. While it remains to be seen how this exception will be scoped in the FAR and agency-specific instructions, the attestation form states that "software producers are attesting to adhering to the secure software development practices . . . for code developed by the producer." See CISA Form Instructions at 5 (emphasis added). At the same time, however, "[s]oftware providers who utilize third party components in their software are required to attest that they have taken specific steps . . . to minimize the risks of relying on such components in their products," including making a good-faith effort to maintain trusted source code supply chains and maintaining provenance for third-party components to the greatest extent feasible. See id. at 3, 7; see also OMB Memo M-23-16 at 2-3 ("The minimum requirements delineated in the common form address the risk of integrating components from third parties"). For now, it seems the government continues to draw a distinction between being responsible for the secure development of third-party components and reasonable efforts to verify that such components were developed securely by verified sources. That may be a fine line to walk in practice, so it will be worth tracking how this exception is implemented by regulation and contract. 

FAQ #3: What Information Must a Company Provide in a Software Attestation?

Section III of the attestation requires software providers to certify that they make "consistent use of the following practices," derived from the SSDF, in developing their listed software products:

• Secure Development Environment: The software is developed and built in secure environments using the following minimum actions:
  • Separating and protecting each environment involved in software development and building 
  • Regularly logging, monitoring, and auditing trust relationships used for authorization and access: 
    • To software development and build environments 
    • Among components within each environment
  • Minimizing security risk by enforcing multi-factor authentication and conditional access across each software development and build environment
  • Taking consistent and reasonable steps to document — and minimize the use or inclusion of — software products that create undue risk in development and build environments
  • Encrypt sensitive data, such as credentials, to the extent practicable and based on risk
  • Implement defensive cybersecurity practices top support continuous monitoring, alerts, and response capabilities
• Trusted Source Code Supply Chains: The software producer makes a good-faith effort to maintain trusted source code supply chains by using automated tools or comparable processes to (i) validate the security of internal code and third-party components and (ii) manage related vulnerabilities
• Maintain Provenance of Internal Code and Third-Party Components: The software producer maintains provenance for internal code and third-party components to the greatest extent feasible
• Security Vulnerability Checks: The software producer uses automated tools or comparable processes to check for security vulnerabilities, including:
  • Conducting vulnerability checks on an ongoing basis and before releasing new products, versions, or updates
  • Maintaining a policy or processes to address security vulnerabilities discovered prior to product release
  • Maintaining a vulnerability disclosure program or policies to timely assess and address disclosed software vulnerabilities

CISA Form Instructions at 6-7.

FAQ #4: When Will the Government Require Software Attestations?

OMB Memo M-23-16 directs agencies to "collect attestation letters" within three months for critical software, and within six months for all other software, of the attestation form's approval. See id., Appx. A at 5. CISA published the approved attestation form on March 11, 2024. So, if OMB's timelines hold, critical software attestations will be due on or before June 11, 2024, and all other attestations by September 11, 2024. 

Notably, the FAR Council has been working on a related proposed rule, titled "Supply Chain Software Security," which will require contractors (and possibly, subcontractors and vendors) to submit software attestations using the CISA form. See FAR Case 2023-002 at 6. As of March 8, 2024, a draft version of the rule was routed to OMB's Office of Information and Regulatory Affairs (OIRA) and Office of Federal Procurement Policy (OFPP) for "concurrent review." See id. This signals that the FAR Council may be close to issuing the proposed acquisition regulation. It remains to be seen if the proposed regulation will set a different timetable than OMB for attestations to be collected. 

Whatever the initial deadline, CISA's form makes clear that software attestations will create ongoing compliance and reporting obligations for government contractors: "Attestations are binding for future versions of the named software product unless and until the software producer notifies the agencies to which it previously submitted the form that its development practices no longer conform to the required elements specified in the attestation." CISA Form Instructions at 5, n. 4. For this reason, when submitting attestations, software providers must agree to "notify any agency to which it has submitted this form if and when the producer ceases to make consistent use of the" minimum development practices. Id. at 7; see also id. at 5 (option to submit "Revised Attestation").

Finally, federal agencies may seek an extension from OMB to allow the continued use of software that does not yet comply with each of the practices identified above, but there's a catch. The software producer must identify the practices to which they cannot attest, document practices to mitigate associated risks, and submit a plan of actions and milestones (POA&M) to the agency. If the agency finds the documentation satisfactory, it may continue using the software, but must concurrently seek an extension of the deadline for attestation from OMB and the POA&M must be submitted to OMB as part of the extension request. An agency's failure to meet these requirements could result in a POA&M being deemed invalid and require the agency to discontinue use of the software. See OMB Memo M-23-16 at 4. Waivers are also possible, though "only in the case of exceptional circumstances and for limited duration." See OMB Memo M-22-18 at 6. Specific waiver instructions will be posted in MAX.gov at a later date. Id. 

FAQ #5: How Will the Government Use Software Attestations?

The government will use software attestations to determine if it should purchase or continue using certain software. Attestations may also be used as potential evidence in enforcement actions against companies and individuals who are alleged to have misrepresented their security development processes. In addition, CISA indicates that information provided in an attestation "may be disclosed as generally permitted" in E.O. 14028, while the Department of Homeland Security (DHS) may disclose such information for other specific purposes. See CISA Form Instructions at 1. Finally, beginning in mid-March 2025, OMB will collect metrics on agency approvals of POA&Ms and the number of extensions and waivers at each agency. See OMB Memo M-23-16, Appx. A. at 5.

FAQ #6: My Company Doesn't Have Direct Contracts with the Government, But We Do Provide Software to Prime Contractors and Other Higher-Tier Entities Supporting Government Programs. Will Our Company Be Required to Submit a Software Attestation?

While there is still no definitive rule on this question, all indications are that subcontractors and vendors could be required to furnish software attestations because, among other reasons, the broad definition of "software" includes products commonly sold to the government by prime contractors and other higher-tier entities, either as pass-throughs or as part of broader products or solutions. See OMB Memo M-23-16 at 2 ("'[S]oftware' includes 'firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software'"). A requirement for subcontractor or vendor attestations could come in the form of a mandatory FAR flowdown clause. Even without a mandatory FAR clause to flow down, it is also conceivable that many higher-tier contractors will ask for equivalent attestations to support their own compliance efforts and minimize their risk.

FAQ #7: Who Must Sign the Software Attestation for My Company?

Software attestation forms must be signed by the Chief Executive Officer (CEO) of the software producer or their designee. Any designee "must be an employee of the software producer and have the authority to bind the company." See CISA Form Instructions at 4 (emphasis added). According to CISA, "[b]y signing, that individual attests that the software in question is developed in conformity with the secure software development practices" of the attestation form. Id. (emphasis added). CISA also warns that "[w]illfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001 [the False Statements Act], a criminal statute." See id. at 1. And because a False Statements Act violation can be a predicate for an FCA action, a knowingly false or misleading attestation can expose companies and their representatives to both civil and criminal liability.

As an alternative to self-attestation, software providers can show that they comply with the minimum development requirements by submitting an assessment from a Federal Risk and Authorization Management Program (FedRAMP)-certified or approved Third Party Assessor Organization (3PAO). To be acceptable, such assessments "must use relevant NIST Guidance that includes all elements outlined" in CISA's attestation form. See id. at 4. The software producer must submit the assessment with its form and check the appropriate box in Section III, but "[t]he producer need not sign the form in this instance." See id. Though hiring a 3PAO will involve some expense, this "no signature" option has the potential to lessen compliance risk for many software companies because it implies that they can reasonably rely on a vetted 3PAO's findings to submit an attestation. 

Conclusion

We will continue to monitor and report on developments in this fast-changing area. In the meantime, if you have any questions about how CISA's new software attestation requirements will impact you or your company, please contact one of the Miller & Chevalier attorneys below. 

Alex L. Sarria, asarria@milchev.com, 202-626-5822

Ashley Powers, apowers@milchev.com, 202-626-5564

Scott N. Flesch, sflesch@milchev.com, 202-626-1584

Jason N. Workmaster, jworkmaster@milchev.com, 202-626-5893

Alexandra S. Prime, aprime@milchev.com, 202-626-5940

Connor W. Farrell, cfarrell@milchev.com, 202-626-5925

The information contained in this communication is not intended as legal advice or as an opinion on specific facts. This information is not intended to create, and receipt of it does not constitute, a lawyer-client relationship. For more information, please contact one of the senders or your existing Miller & Chevalier lawyer contact. The invitation to contact the firm and its lawyers is not to be construed as a solicitation for legal work. Any new lawyer-client relationship will be confirmed in writing.

This, and related communications, are protected by copyright laws and treaties. You may make a single copy for personal use. You may make copies for others, but not for commercial purposes. If you give a copy to anyone else, it must be in its original, unmodified form, and must include all attributions of authorship, copyright notices, and republication notices. Except as described above, it is unlawful to copy, republish, redistribute, and/or alter this presentation without prior written consent of the copyright holder.