Government contractors will soon need to attest that the software they produce is securely developed. On April 27, 2023, the Cybersecurity and Infrastructure Security Agency (CISA) published a draft Secure Software Self-Attestation Form and Request for Comment. The CISA form defines the four secure development objectives that set the baseline expectation for all US government-procured software products and services. Government software producers, developers and resellers should act now to validate their secure development practices and prepare to make and defend legally binding attestations.

IN DEPTH

Government software producers have known for nearly two years that the federal government would soon require secure software development attestations aligned with the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF). However, until recently, government software producers had little insight into how the expansive and ambitious SSDF would translate into concrete obligations. The April 27 CISA form narrows the NIST guidance to four minimal secure development practices, bringing much-needed clarity and serving as a foundation for government software producers to meaningfully plan for implementation, as well as to assess compliance risk.

Background

On May 12, 2021, President Joe Biden issued Executive Order No. 14028 on Improving the Nation’s Cybersecurity. The executive order seeks to improve the integrity and security of the software supply chain by establishing baseline security standards for development of software sold to the government. Using the power of federal procurement to incentivize the market represented a fundamental shift in the federal government’s cybersecurity strategy. It also set the stage for mandatory secure software development requirements that could potentially become the most expansive ever.

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

On September 14, 2022, the Office of Management and Budget (OMB) issued a memorandum directing each federal agency to comply with the NIST guidance when using third-party software on the agency’s information systems or otherwise affecting the agency’s information. The memo directs agencies to obtain a self-attestation from the software producer before using the software. It also instructs agencies to obtain software artifacts and software bills of materials (SBoMs) as needed. CISA is tasked with establishing a standard self-attestation “common form,” as well as building a repository of software artifacts and SBoMs. OMB is required to develop a process for agencies to issue waivers and extensions to software producers that cannot meet attestation requirements.

Software supply chain security has remained a priority for the Biden administration. The March 2023 National Cybersecurity Strategy proposes legislation that would shift liability on software producers that fail to take reasonable precautions to secure their software. 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 CISA form, in its final, approved version, will set the minimum requirements for software security self-attestations. Agencies can choose to adopt the CISA form or to require a more robust attestation consistent with the NIST guidance.

The CISA form identifies four minimal secure development objectives:

• Secure the development environment. Development workstations, test infrastructure, DevOps applications, code repositories and all 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. DevOps tools and automated processes must be used to verify the security of third-party software components, including open-source software (OSS) libraries and packages.

• Maintain provenance data. All first-party and third-party components must be identified and inventoried using software composition analysis (SCA); the origin, development, ownership, location and change history of the software components must be recorded; SBoMs must be generated automatically or ad hoc.

• Manage vulnerabilities. Automated processes and DevOps tools must be used to test for security vulnerabilities; discovered vulnerabilities must be tracked and remediated prior to launch; reported security vulnerabilities in released software must be received, reviewed and remediated.

The CEO or designee must attest that their software was developed using practices that consistently maintain and 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 company wide, or to a specific subset, such as a given product, product line or a product version.

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 and develop a plan of actions and milestones (POAM).

Who is Affected and When?

The September 2022 OMB memorandum establishes that all producers of software products and services that are sold or resold to the federal government will eventually need to attest to secure development practices. It appears that the federal government’s implementation of the software security self-attestation program is not tracking the aggressive timeline defined in the September 2022 OMB memorandum; however, no alternative timeline is available.

Conformity with the NIST SSDF will eventually be required for all types of software acquired by the federal government, except software that is free (libre or gratis) or agency developed. The attestation requirements will be implemented first for critical software. OMB Memorandum M-21-30, Protecting Critical Software Through Enhanced Security Measures (Aug. 10, 2021), defines critical software 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.

Producers of non-critical government software, including products and services related to cloud, hosted, software as a service (SaaS), internet of things (IoT) and operational technology (OT), may have additional time to comply. The September 2022 OMB memorandum contemplates that requirements for non-critical software will become effective 95 days following the launch of critical software attestation requirements.

Software that was developed prior to September 14, 2022, and has not had a major upgrade since that date will remain exempt from the attestation requirements.

What are the Risks of Noncompliance?

An inaccurate software security attestation or an inability to produce corroborating security artifacts would create material risk for government-software producers.

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 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 revenue, or higher. The FCA includes a unique whistleblower provision that allows private parties to file a qui tam action and potentially share in the federal government’s civil recovery.

The Federal Trade Commission (FTC), state regulators and consumer plaintiffs might allege that inaccurate software security attestations constitute deceptive trade practices. If consumers can reasonably rely on a company’s security attestation to the federal government, which would be consistent with the intent of Executive Order 14208, FTC enforcement would be possible if not likely. The FTC also has often pursued companies that failed to substantiate claims made in advertising. This precedent could support an enforcement action against a company that failed to produce security artifacts supporting the attested claims.

Software producers that are publicly traded must disclose material cybersecurity risks and incidents under applicable securities law. Public companies that earn a material amount of revenue from the federal government might be required to report software vulnerabilities or other attestation compliance issues in a Form 8K. Companies that conceal material information from investors could face shareholder and derivative litigation, as well as qui tam whistleblower actions.

What Should Government Contractors Do?

Government software producers should review the attestation form and further consider their preparedness to attest to the required secure software development practices. To mitigate business, reputational and legal risk, companies should take immediate action to conduct an evaluation of their secure software development maturity and to identify potential compliance gaps. Even companies with outstanding software development security might be unprepared to prove compliance to the attesting employee, the 3PAO assessor or government investigators.

Government contractors will be well prepared to attest to any foreseeable form of secure software if they:

• Consider and follow the specific attestation requirements throughout the systems development life cycle (SDLC).

• Implement an effective security governance framework that aligns with the NIST SSDF and integrates with the enterprise risk management function and governance risk and compliance (GRC) tooling.

• Monitor and enforce compliance with secure software development practices and security policies, generally.

• Leverage automation and DevOps tooling to enforce security checkpoints and to consistently generate and archive required security artifacts.

• Proactively manage risks from OSS and third-party software components using software composition analysis (SCA) and other tooling.

• Ceaselessly test for, track and remediate vulnerabilities at every stage of the SDLC, including post-release.

To state the obvious, companies should plan to spend more than the OMB-recommended three hours and 20 minutes on the CISA Secure Software Self-Attestation. Companies with a foreseeable attestation requirement should consult counsel without delay. A privileged readiness assessment will help companies close compliance gaps and prepare for an effective and risk-managed attestation process.

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.

Peter Scheyer also contributed to this article.