by Michael T. Borgia, Andrew M. Lewis, and Patrick J. Austin

Once Finalized, the Form will Establish Secure Software Development Baselines for Companies that Provide Software to the Federal Government

The Cybersecurity and Infrastructure Security Agency (CISA) has released a revised draft of its Secure Software Development Attestation Common Form (“Form”).  The Form, once finalized, will obligate vendors providing software to the federal government to attest to enumerated practices to secure their software, third-party components, and the development environment.  Software vendors to federal agencies are advised to review the draft Form and assess their current secure development practices—both for in-house and third-party developed software—against the Form’s relevant attestations and the supporting NIST guidance.  Software producers unable to make any of the required attestations should prioritize conforming their software development practices to the Form’s attestations and NIST guidance, and should consider whether to pursue a plan of action and milestones (POA&M) with their federal agency customers once the Form is finalized.

Background

CISA’s Form is part of the federal government’s implementation of Executive Order (EO) 14028, “Improving the Nation’s Cybersecurity, which was issued by President Biden in May 2021 (we discussed the EO in detail in a prior post).  Section 4 of the EO directed the federal government to enhance the security of its software supply chain.  Among other things, Section 4 directed the National Institute of Standards and Technology (NIST) to issue guidance on secure software development practices for software used by the federal government.  Section 4 also tasked the Office of Management and Budget (OMB) to require federal agencies to comply with NIST’s guidance.  To implement Section 4, NIST published its Secure Software Development Framework (SSDF) and Software Supply Chain Security Guidance (collectively, the “NIST Guidance”) in February 2022.  OMB in turn issued Memorandum M-22-18 on September 14, 2022.  M-22-18 directed federal agencies to obtain a self-attestation from software vendors confirming their use of secure software development practices consistent with the NIST Guidance prior to federal agencies using those vendors’ software, and to obtain “software artifacts and software bills of materials (SBOMs) as needed.”  M-22-18 tasked CISA with developing a standard self-attestation “common form” for use across federal agencies, and with building a federal repository for attestations and supporting artifacts.  OMB amended M-22-18 by issuing Memorandum M-23-16 on June 9, 2023.[1]  CISA released its initial draft Form on April 27, 2023, and released this revised version on November 16, 2023.  The attestations in the Form are derived from NIST’s SSDF.  

Overview of CISA’s Revised Draft SSDF

The changes from the first draft of the Form to this recent draft largely clarify and refine existing provisions.  This latest draft did not change the Form’s core requirements.  We provide an overview of the Form and then highlight key changes from the initial draft.

Covered Software

Following OMB’s directions, federal agencies will be required to obtain a completed form for the following categories of software:

• Software developed after September 14, 2022;
• Existing software that is modified by major version changes after September 14, 2022; and
• Software to which the developer delivers continuous changes to the software code (e.g., software-as-a-service (SaaS) offerings or other products using continuous delivery/continuous deployment).

The Form is not required for software developed by federal agencies and software that is freely and directly obtained by a federal agency (including freeware and free open-source software).  Even so, software producers must attest that they have taken specific steps to minimize risks of relying on third-party software components, including open-source software and freeware, in their products.

Attestations

The draft Form requires software vendors to attest to making consistent use of four broad secure development practices:   

• The software was developed and built in secure environments, using several enumerated security measures (e.g., maintenance of separate development environments, use of multifactor authentication, encryption of sensitive data, and continuous monitoring for cyber threats);
• The software producer has made a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities;
• The software producer maintains “provenance”[2] for internal and third-party code incorporated into the software; and
• The software producer employs automated tools or comparable processes that check for security vulnerabilities. The producer must operate these processes on an ongoing basis, maintain a policy to address discovered security vulnerabilities prior to releasing software, and operate a vulnerability disclosure program to receive and address vulnerability reports.

If a software producer cannot make one or more of the attestations in the Form, it must document practices it has in place to mitigate associated risks and submit a POA&M to the agency.  The POA&M must outline how the producer intends to remedy its inability to complete the attestation form and its timeline for doing so.

Third Party Assessment

As an alternative to self-attestation, a software developer may demonstrate conformance with the Form’s provisions via a third-party assessment.  This assessment must be performed by a Third-Party Assessor Organization (3PAO) that has either been FedRAMP[3] certified or approved in writing by an appropriate official of the federal agency procuring the software.  The 3PAO must use for its assessment baseline the relevant NIST Guidance that includes all elements outlined in the Form. 

Key Changes from the Prior Draft

Changes from the initial draft Form to the current draft can be viewed here.  Notable changes from the initial draft to the current draft include the following:  

• The software producer’s CEO or COO is now required to sign the Form. The prior draft required the Form to be signed by the software producer’s CEO “or their designee.”  Under both versions the signatory must be an employee of the organization (i.e. not outsourced). 
• The current draft provides some clarity on the nature of third-party assessments as an alternative to self-assessment. The prior draft stated that the 3PAO must have “used relevant NIST guidance” for the third-party assessment to replace self-assessment.  What it meant for the 3PAO to use that guidance was unclear.  The new draft clarifies that the “appropriate NIST Guidance” covering all attestations in the Form must serve as part of the assessment baseline.
• Attestation Two (2) previously stated that the software producer made good-faith efforts to maintain trusted source code supply chains by “[e]mploying automated tools or comparable process.” That language left unstated what those “automated tools or comparable processes” should do.  The new draft clarifies that those tools and processes are to “address the security of internal code and third-party components and manage related vulnerabilities.”
• The current draft clarifies that federal agencies are responsible for seeking waivers from OMB if those agencies decide to use software that cannot meet one or more of the attestations on the Form. This update is based on guidance from OMB M-23-16.
• The initial draft allowed producers to attest to their practices company wide, by product line, by individual product, or for multiple specified products. The revised Form appears to no longer permit attestation by product line.[4]  Producers must attest to their software development practices on a company-wide basis or for one or more specific products.  

Risks Associated with Noncompliance

Software producers that fail to provide a required attestation of secure development could potentially jeopardize existing federal contracts.  For example, in a January 2023 memorandum, the General Services Administration (GSA) reminded federal contractors that when software fails to meet GSA IT Standards and becomes unapproved for use, “any future period of performance (e.g., option year, extension, task order) cannot be exercised or issued and the requirement must be re-procured.”  The Federal Acquisition Regulatory (FAR) Council recently published a proposed rule (FAR case 2023-002) that would make attestations a prerequisite for federal agencies’ commercial software procurement contracts.  If that rule is finalized, failure to provide a required attestation would be a breach of the software producer’s federal contract. 

Software producers that make false attestations could expose themselves to significant legal risk.  For example, CISA’s draft SSDF states that “[w]illfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001 [False Statements], a criminal statute,” subjecting the signatory to possible fines and imprisonment.  Providing false statements could additionally violate the civil False Claims Act, which provides for treble damage penalties.  Suits under the False Claims Act may be brought by the federal government or by private citizens in qui tam actions.  The False Claims Act serves as a major whistleblower statute and frequently is used by current and former employees of federal contractors alleging that their companies falsely represented their compliance with federal requirements.

The Department of Justice (DOJ) has made clear its willingness to use the False Claims Act to pursue false cyber-related certifications.  As we discussed in a prior blog post, the DOJ launched its Civil Cyber-Fraud Initiative in 2021 to pursue government contractors that knowingly fail to meet their cybersecurity commitments to federal agencies.

Looking Ahead

CISA has opened a 30-day public comment period for feedback on draft Form.  Comments are due by December 18, 2023.  OMB is particularly interested in comments that:

• Evaluate whether the proposed collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility;
• Evaluate the accuracy of the agency’s estimate of the burden of the proposed collection of information, including the validity of the methodology and assumptions used;
• Enhance the quality, utility, and clarity of the information to be collected; and
• Minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology, e.g., permitting electronic submissions of responses.

Neither CISA nor OMB has provided an anticipated date for publication of the final Form.  Per OMB M-23-16, once the Form is finalized, federal agencies must collect attestations for “critical software” (defined in NIST guidance) within three months and for all in-scope software within six months.

Footnotes

[1] M-23-16 reiterated OMB’s core instructions from M-22-18 and extended deadlines for agencies to obtain attestations from software developers.  M-23-16 also provided supplemental guidance on agencies’ use of Plan of Actions and Milestones (POA&Ms) if a software developer cannot make the required attestations in the Form.

[2] NIST defines “provenance” as “[t]he chronology of the origin, development, ownership, location, and changes to a system or system component and associated data.  It may also include the personnel and processes used to interact with or make modifications to the system, component, or associated data.  See NIST Special Publication 800-53.

[3] FedRAMP is the Federal Risk and Authorization Management Program, a security assessment and authorization program for cloud services used by the federal government.  We wrote about major changes to FedRAMP earlier this year.

[4] Section I of the Form removes several references to “Product Line” attestations, including in a list of permitted attestation types.  However, one reference to product line attestation remains (“If this attestation is for an individual product, multiple products, or product line, provide the software name, version number, and release/public date to which this attestation applies” (emphasis added).  This remaining reference may be an error.

Michael T. Borgia is a Partner, Andrew M. Lewis is an Associate, and Patrick J. Austin is an Attorney at Davis Wright Tremaine LLP. This post first appeared on the firm’s blog.

The views, opinions and positions expressed within all posts are those of the author(s) alone and do not represent those of the Program on Corporate Compliance and Enforcement (PCCE) or of the New York University School of Law. PCCE makes no representations as to the accuracy, completeness and validity or any statements made on this site and will not be liable any errors, omissions or representations. The copyright of this content belongs to the author(s) and any liability with regards to infringement of intellectual property rights remains with the author(s).