CISA Self-Attestation Form Brings Clarity to Pending Secure Software Requirements for Government Contractors

Secure software development attestations have been a focus of the federal government’s cybersecurity strategy plan since President Biden’s May 2021 Executive Order (EO) on Improving the Nation’s Cybersecurity. In response to the EO, the National Institute of Standards and Technology (NIST) issued a software supply chain security guidance and updated the Secure Software Development Framework (SSDF).

However, until recently, there was little insight into how the expansive and ambitious SSDF would translate into concrete obligations for producers and developers of software sold to the government. CISA’s draft Self-Attestation Form (the CISA Form) defines the baseline software security standards for government procurement, distilling the SSDF to four “minimum secure software development requirements a software producer must meet, and attest to meeting.”

Although few, the requirements may still present a significant challenge to government contractors, software producers and upstream developers. The chosen requirements are not widely implemented and are some of the most challenging.

• Open-source security: Take reasonable steps to verify the security of third-party code, including open-source libraries.
• SBOM: Capture provenance information, so that a software bill of materials (SBOM) can be prepared at the request of an agency.
• Vulnerability management: Detect, track and remediate vulnerabilities using automation and enterprise processes, such as DevOps & governance risk and compliance (GRC).
• Infrastructure Security: Implement common enterprise security controls on all hardware, virtual infrastructure and SaaS used in development.

The CISA Form serves as a foundation for companies to meaningfully plan for implementation and assess compliance risk. Companies should act now to determine whether they can meet these secure software development attestation requirements, develop a roadmap or Plan of Action and Milestones (POA&M) for any gaps and prepare to create and archive the documentation necessary to support a challenge to an attestation.

Background

On December 17, 2020, US President-elect Joe Biden, addressing the cyberattacks against users of SolarWinds’ Orion software, announced that improving cybersecurity at every level of the government would be a top priority from the moment his administration takes office. On May 12, 2021, with much of the country still disrupted by the ransomware attack on Colonial Pipeline, President Biden issued Executive Order No. 14028 on Improving the Nation’s Cybersecurity. The executive order sought to improve the integrity and security of the software supply chain by establishing baseline security standards for the development of software sold to the government. Leveraging “the purchasing power of the Federal Government to drive the market to build security into all software from the ground up” represented a fundamental shift in the federal government’s cybersecurity strategy.

The executive order broadly directed NIST to solicit input (from the private sector, academia, government agencies and others) to identify or develop new standards, tools, best practices and other guidelines to enhance software supply chain security. In February 2022, after a series of workshops and other public engagements, NIST issued two guidance documents on software supply chain security. The SSDF was published as NIST SP 800-218 on February 3, 2022, and on February 4, 2022, NIST published its Software Supply Chain Security Guidance.

On September 14, 2022, the US Office of Management and Budget (OMB) issued memorandum M-22-18 directing each federal agency to comply with NIST’s SSDF and Software Supply Chain Security Guidance when “using third-party software on the agency’s information systems or otherwise affecting the agency’s information.” The memo directed agencies to obtain a self-attestation from the software producer before using the software and to obtain software artifacts and software bills of materials (SBoMs) as needed. To that end, OMB tasked CISA with establishing a standard self-attestation “common form,” as well as building a repository of software artifacts and SBoMs. OMB developed a waiver and extension process for agencies where software producers cannot meet attestation requirements, stating that any request must be submitted 30 days before any relevant deadline and be “accompanied by a plan for mitigating any potential risks.”

On January 11, 2023, the Government Services Administration (GSA) revelated its process for collecting, reviewing, retaining and monitoring software security attestations in a memorandum titled Ensuring Only Approved Software is Acquired and Used at GSA. GSA will begin collecting attestation letters as part of pre-award and post-award contract deliverables in mid-June 2023 for all government-procured software.

Software supply chain security has remained a priority for the Biden administration. On October 11, 2022, the White House stated that “requiring security features in all software purchased by the Federal Government” will improve security “for all Americans.” The March 2023 National Cybersecurity Strategy recommends legislation that would shift “liability for software products and services to promote secure development practices.” CISA Director Jen Easterly has stated frequently that software companies, rather than end users, should bear the risks and burdens that result from security vulnerabilities.

CISA Self-Attestation Form

The Form is intended to provide the federal government assurances that software used by agencies is securely developed. The April 27 draft Form for public comment identifies four secure software development requirements that producers must “attest that the software they produce was developed in conformity with.”

• Secure the development environment. Development workstations, test infrastructure, DevOps applications, code repositories and all other development infrastructure must be secured like any other sensitive asset, with risk assessments and standard technical controls such as multifactor authentication, encryption, endpoint protection and access monitoring.
• Establish a trusted source code supply chain. Take “reasonable steps to address the security of third-party components,” including open-source software (OSS) libraries and packages, with automation or comparable DevOps processes.
• Maintain provenance data. All first-party and third-party code incorporated into the software must be inventoried, with record of the origin, development, ownership, location and change history.
• Manage vulnerabilities. Automated processes and DevOps tools must be used to test for security vulnerabilities prior to release; discovered vulnerabilities must be addressed prior to release; and third parties must be able to vulnerabilities in released software must be received, reviewed and remediated.

Each of the four required attestations is “related” to one or more SSDF practices and tasks. They collectively address 17 of the 19 secure development practices defined in the SSDF and 31 of 43 tasks.

The CISA form contemplates that the CEO or designee must attest that their software was developed using practices that satisfy the identified secure software development requirements. They must also promise to “notify all impacted agencies if conformance to any element of this attestation is no longer valid.” The Form allows a software producer to attest to the security of software on a company-wide basis or for specific products, product lines or product versions.

As an alternative to the self-attestation, a producer may engage a certified FedRAMP third-party assessor organization (3PAO) to verify that software was developed in accordance with the relevant NIST guidance.

Producers that cannot attest to all required practices will be required to request an extension or waiver from the agency and develop a plan of actions and milestones (POA&M).

What Software Is Affected? When Will the Self-Attestation Be Required?

The CISA Form is intended to be the common form available to any agency for use with any software that has an attestation requirement under the September 2022 OMB memorandum. The Form can be used with any software, including firmware, operating systems, applications and application services (e.g., cloud-based software), as well as products containing software.

Attestations will be collected first for critical software, which OMB defines as “standalone, on-premise software that performs security-critical functions or poses similar significant potential for harm if compromised.” Examples given include operating systems, endpoint security, network control and protection, security logging and monitoring.

The OMB memorandum directs agencies to collect software attestation forms for critical software, seek an exception from OMB or discontinue use of the software by June 11, 2023. There will not be an approved self-attestation form by the date; however, producers of critical software currently in use by the federal government should be prepared to attest as soon as the Form is made final by CISA.

OMB has directed agencies to collect attestations “for all software subject to the requirements of [the September 2022] memorandum” by September 14, 2023. Although the aggressive timelines set by OMB have not been strictly followed to date, producers of any software used by the federal government should not delay in preparing to make secure software self-attestations.

The self-attestation requirements of the OMB memorandum do not apply to software that is freely acquired or software that is developed by an agency. Software that was developed prior to September 14, 2022, is not continuously developed and has not had a major upgrade since that date will remain exempt from the attestation requirements.

What Are the Risks of Noncompliance?

Software producers that fail to provide a required attestation of secure development or receive an exception face substantial risks to federal sales channel revenue, including for existing federal contracts. In its January 2023 memo, the GSA reminded 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.” It also directed new contracts for commercial software to require IT Standards Process approval before any performance period can begin. Pending rules by the Federal Acquisition Regulatory Council will make attestations a required part of contracts for commercial software procurement.

Software producers that make inaccurate attestations face significant legal risk. As noted in the CISA Form, “[w]illfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute.” The Biden administration has repeatedly signaled its intention to use its authorities under the False Claims Act (FCA) to punish and deter misrepresentation of the cybersecurity of the goods and services sold to the federal government. The DOJ’s Civil Cyber-Fraud Initiative, announced on October 11, 2021, will utilize the FCA to pursue cybersecurity-related fraud by government contractors. Potential liability under the FCA is three times the amount of any fraud, which can be valued at 100% of contract revenue, or higher. The FCA includes a whistleblower provision that allows private parties to file a qui tam action and potentially share in the federal government’s civil recovery.

The indirect risks that could result from inaccurate attestations are numerous. For example, a public company might face legal risk from the US Securities and Exchange Commission (SEC), plaintiffs and whistleblowers for failure to escalate and disclose material risks. For software that is sold to consumers as well as the government, the Federal Trade Commission (FTC), state regulators or consumer plaintiffs might allege that inaccurate security attestations constitute a deceptive trade practice.

What Should Government Contractors Do?

Government contractors, including off-the-shelf (GOTS) software producers and upstream third-party developers, should act now to prepare to make and defend secure software attestations.

In-house counsel can ask their software developers the following questions to help assess their company’s maturity against the secure development requirements of the CISA Form:

• Is our development infrastructure inventoried and protected with standard enterprise security controls, including those listed in the CISA Form?
• Do we perform software composition analysis (SCA) to identify and/or validate the open-source code and other third-party components that are included in our software?
• Can we produce an accurate software bill of materials (SBOM) if requested?
• Do we automatically test the software for vulnerabilities during development and prior to release?
• Do we track and remediate discovered vulnerabilities?
• Do we use the software composition analysis results to identity upstream security vulnerabilities?
• Do we have an established process to accept, review and address vulnerability disclosures from external parties?
• Do we monitor and enforce compliance with these practices?
• Do we automatically create and archive secure software development artifacts?

Companies should consider whether to conduct a readiness assessment at the direction of counsel. A privileged investigation can be an effective way to identify and address compliance gaps and to confirm that the company has the necessary documentation to defend the attestation in the face of a challenge.

The public has until June 26, 2023, to submit its feedback on the draft CISA Form. Companies can submit public comments anonymously through counsel or via an industry association, among other means. Companies can also submit comments directly by visiting regulations.gov.

McDermott’s Privacy and Cybersecurity and Government Contracts teams are continuing to monitor the administration’s implementation of Executive Order 14028, including the pending updates to the FAR and DFARS.