As contemplated by PilieroMazza’s recent blog, the Cybersecurity and Infrastructure Security Agency (CISA) released a notice and request for comments on a new requirement for software producers to provide self-attestations regarding their software and its compliance with the secure software development practices, as described in the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) (Special Publication 800–218). The Office of Management and Budget released a memorandum on September 14, 2022, requiring agencies obtain self-attestations from software producers before using their software. A draft version of the self-attestation form (Form) can be found here. Government contractors that produce and provide software to the government should become familiar with notable contents in the self-attestations, as described further below.
Who Is Required to Complete Attestations?
The term “software producer” is not defined but, on its face, it encompasses all firms that produce or develop software. These attestations will be required for:
- software developed after September 14, 2022,
- software that undergoes a major version change (e.g., using a semantic versioning schema of Major.Minor.Patch or the software version number goes from 2.5 to 3.0) after September 14, 2022, and
- software where the producer delivers continuous changes to the software code (e.g., software-as-a-service products or other products using continuous delivery/continuous deployment).
This requirement applies to third-party software used on an “agency’s information systems or otherwise affecting the agency’s information.” Software broadly encompasses: “firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.” Note that software developed by Federal agencies is exempt.
It’s unclear how this will apply to resellers of software. Presumably though, to provide software to an agency, the contractor selling it must ensure its developer completed the attestation. Similar to other areas of government contracts, it may be possible that Federal contractors who resell software to the government can rely, in good faith, on the representations and certifications made in the Form from the software producers. While we need to wait until the Form is finalized, agencies can require contractors to provide these attestations as “go/no-go” requirements or as part of responsibility determinations in solicitations.
Examples of Some Attestations and Related SSDF Practices
If you are a producer familiar with the NIST SSDF, the following references and examples of some secure software practices will be familiar. If you are new to the world of SSDF, these attestations and references to the SSDF may seem daunting at first. Below are some of the attestations in the draft form, as well as some (non-exhaustive) examples of practices that meet the SSDF requirements.
- The Form requires the environment the software was developed and built in be secured by regularly logging, monitoring, and auditing trust relationships used for authorization and access to any software development and build environments and among components within each environment. Examples of practices that meet this requirement include: (i) using multi-factor authentication and conditional access for each environment, (ii) using network segmentation to separate environments from each other, and (iii) enforcing authentication and restricting connections entering and exiting each software development environment.
- Another attestation from the Form requires the software producer to maintain provenance data for internal and third-party code incorporated into the software. Examples of practices consistent with this statement include: (i) making the provenance data available to the organization’s operations and response teams to aid them in mitigating software vulnerabilities, (ii) protecting the integrity of provenance data and providing a way for recipients to verify provenance data integrity, and (iii) updating the provenance data every time any of the software’s components are updated.
- The Form also requires producers to attest they employed automated tools or comparable processes that check for security vulnerabilities. Examples of such tools and/or processes include: (i) using up-to-date versions of compiler, interpreter, and build tools, (ii) following change management processes when deploying or updating compiler, interpreter, and build tools and audit all unexpected changes to tools, and (iii) having a qualified person who was not involved with the design and/or automated processes within the toolchain review the software design to confirm and enforce that it meets all of the security requirements and satisfactorily addresses the identified risk information.
Penalties for Willfully Disclosing Misleading or False Information
The disclosure statement refers to 18 U.S.C. § 1001 as a potential penalty in the event attesters willfully provide false or misleading information. 18 U.S.C. § 1001 makes it a federal crime to, among other things, “knowingly and willfully” falsify a material fact or make a fraudulent statement or representation. While the False Claims Act is not specifically referenced, the U.S. Department of Justice could also prosecute software producers who make false statements or representations in the Form.
Relatedly, the estimated reporting burden to complete the Form is 3 hours and 20 minutes. While some companies well-versed in these practices may be able to attest to the Form’s statements in that time, some commenters made it clear that having a Chief Executive Officer (CEO)—as required by the Form—sign off on the attestation, will require a detailed, point-by-point review and analysis of the company’s current policies and practices. The SSDF and related NIST documents are detailed, comprehensive sets of policies, practices, and cross-references, requiring a great deal of time, resources, and energy to go through; it will likely entail consulting legal counsel. The estimated reporting burden therefore may not be accurate. Although the Form is not particularly long, to ensure contractors are not misrepresenting their secure software development practices, they should expect completing the Form will take much longer than a few hours, especially considering the potential penalties that might result.
CISA is collecting public comments regarding the Form here until June 26, 2023. If you have questions about the attestations and how to prepare for compliance with them, or any other secure software developments, please contact Cy Alba and Daniel Figuenick, the authors of this blog, or another member of PilieroMazza’s Government Contracts or Cybersecurity & Data Privacy practice groups.
