New Software Development Security Attestation and Related False Claims Act Liability for Commercial and Noncommercial Software Developers and Suppliers
Key takeaway
Software producers at all levels in the federal supply chain should prepare to attest that their software development practices comply with National Institute of Standards and Technology (NIST) standards supported by artifacts that demonstrate secure software development and by the software bill of materials.
What happened
On Sept. 14, 2022, the Office of Management and Budget (OMB) issued guidance establishing time frames for requiring all federal agencies to only use software provided by developers (producers) who can attest in writing to complying with the NIST-specified secure software development framework (NIST SP 800-218) and NIST software supply chain security guidance. OMB’s actions implement President Joe Biden’s May 12, 2021 Executive Order requiring NIST to identify practices that enhance the security of the software supply chain.
OMB’s memorandum could have far-reaching implications for developers and federal suppliers. “Software” for this purpose includes firmware, operating systems, applications and application services (e.g., cloud-based software), as well as products containing software. OMB’s memorandum implies that this attestation requirement is meant to ripple through the supply chain so that all software used on agency information systems or affecting agency information – from laptops and servers to printers and IoT connected devices – could need an attestation.
Federal agencies are directed to obtain an attestation, either from the software producer or, potentially, for critical software, from a third-party assessor. Although the form of the attestation is not final, the OMB directive indicates it will include a statement attesting that the software producer follows secure development practices and tasks. Where a software producer cannot provide an attestation with respect to all specified development practices, it will be required to identify those practices to which it cannot attest, document practices it has in place to mitigate those risks, and develop a plan of action and milestones. In support of the attestation, agencies can also request artifacts that demonstrate conformance to secure software development practices, as needed. Agencies may also request a software bill of materials (SBOM) and require that the SBOM be provided in a format approved by the National Telecommunications and Information Administration (see the NTIA SBOM website for more information on SBOMs).
Pursuant to OMB’s memorandum, agencies are required to develop processes to communicate requirements to vendors within 120 days. Further, agencies are required to collect attestation letters for critical software within 270 days and collect attestation letters for all software subject to the requirements within 360 days of publication of the OMB memorandum. OMB’s memorandum establishes a process through which an agency may request an extension for its compliance as well as a process through which an agency can seek a waiver of specific requirements in exceptional cases for a limited duration.
Importantly, as written, the requirement for conformance with federal standards and the related attestation and compliance risk will flow down to commercial software developers and suppliers whose software is ultimately installed on the agency’s information systems or otherwise affects the agency’s information, including because it is on a private contractor system that processes, stores or transmits government information.
False Claims Act liability
The attestation will require an affected company’s careful analysis of its software development practices against the applicable requirements, and responsibility should not be taken lightly. On Oct. 6, 2021, Deputy Attorney General Lisa Monaco announced a new Civil Cyber-Fraud Initiative that will use the False Claims Act to pursue companies that receive federal funds when they knowingly fail to follow required cybersecurity standards, when they furnish deficient cybersecurity products/services, or when they misrepresent cybersecurity practices. “Knowingly” in this context includes actual knowledge but could also include deliberate ignorance and even reckless disregard for the truth or falsity of information. So, for example, a developer that certifies compliance with the NIST software development standards without first verifying that the standards were followed may have acted with reckless disregard to the truth or falsity of this claim. The False Claims Act also includes a unique whistleblower provision, which allows private parties to assist the government in identifying and pursuing fraudulent conduct and to share in any recovery, and that protects whistleblowers from retaliation for alerting the government to false claims.
Next steps
The implementation timeline will vary depending on factors that include the type of software involved and software development update schedules. In the meantime, each software producer should be reviewing software development practices against the NIST standards and guidance to identify gaps in their practices. Where software producers identify practices to which they cannot attest, they should develop an action plan to close the gaps and document practices they have in place to mitigate risks until they can close the gaps.
[View source.]
