United States: Companies Selling Software To The U.S. Government Soon Must Attest To Compliance With Nist Guidance On Software Supply Chain Security

Software companies that sell commercial software products to federal agencies soon must begin attesting to their compliance with guidance designed to enhance the security of the software supply chain. Under a new White House Office of Management and Budget (OMB) memorandum issued September 14, federal agencies must require software "producers" (i.e., the developers of software) to confirm their compliance with specific guidance created by the National Institutes of Standards and Technology (NIST). The OMB memorandum implements the software supply chain enhancements first suggested under Executive Order (EO) 14028, Improving the Nation's Cybersecurity, on which we've previously commented.

For purposes of the memorandum, the term "software" includes firmware, operating systems, applications, and cloud-based software, as well as products that contain software. The new requirements apply to software developed after the memorandum's effective date (more on this below), and to existing software if modified by major version changes. Once the policy is in full effect, federal agencies may only use software if the software producer has attested to compliance with the NIST guidance, subject to certain limited exceptions. The purpose of the new requirements is to protect federal information systems from cyberattacks by ensuring the integrity of software acquired by the government. The policy can be traced to the SolarWinds compromise that impacted multiple U.S. government systems and other similar security incidents.

When do the new rules take effect?

Under the scheme set forth in the OMB memorandum, agencies have 90 days (or until December 14) to inventory their existing software and 120 days (until January 14, 2023) to develop a process for communication with software vendors. Agencies must begin collecting attestation letters for "critical software"¹ within 270 days (by June 14, 2023) and for all other software within 365 days (by September 14, 2023). In other words, within the next year, any software company seeking to sell its products to the federal government will need to assess and come into compliance with the NIST guidance. Note, however, the memorandum does permit agencies to request extensions of the above deadlines. If past is prologue, the implementation timeline may well be expanded beyond a year.

What is the relevant NIST guidance?

The two publications collectively referred to as the "NIST Guidance" in the OMB memorandum are the NIST Special Publication (SP) 800-218 – Secure Software Development Framework (SSDF) and the NIST Software Supply Chain Security Guidance.

NIST SP 800-218 provides high-level guidance on how software producers can integrate security into the software development life cycle. The framework consists of four recommendations, each broken down into a series of more specific practices and more well defined tasks, followed by examples and references. The recommendations are:

• Prepare the organization, by ensuring that the people, processes, and technology are prepared to perform secure software development.
• Protect the software, including all components from tampering and unauthorized access.
• Produce well-secured software, with minimal security vulnerabilities in each release.
• Respond to vulnerabilities, by identifying residual vulnerabilities and responding appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

The publication takes the form of a chart, mapping out each recommendation, practice, and task. The executive summary clarifies that not all practices apply to every use case, and that organizations should adopt a risk-based approach to determine which practices are relevant, appropriate, and effective to mitigate the threats to their software development practices.

The NIST Software Supply Chain Security Guidance provides additional direction, aimed primarily at agencies, to assist in integrating the SSDF into procurements. The guidance clarifies that although open-source software freely obtained by federal agencies falls outside the scope of the framework, open-source software that is bundled, integrated, or otherwise used as part of any third-party software purchased by agencies is covered by the SSDF. Additionally, the guidance applies to both on premises and cloud-hosted software. The guidance further recommends that agencies:

• Use the SSDF's terminology and structure to organize communications about secure software development requirements.
• Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle.
• Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required.
• Request high-level artifacts demonstrating conformance, when needed.

How do I provide an attestation?

The Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA) has been directed to work with OMB to establish a "common form" suitable for use by multiple agencies. The form will provide a minimum level of assurance that the vendor followed NIST Guidance, and will include the software producer's name, a description of the product or products the statement covers, and a statement attesting that the software producer followed NIST recommended secure development practices.

Alternatively, a vendor may obtain a third-party assessment, provided by a certified FedRAMP Third-Party Assessor Organization (3PAO) or another assessor approved by the agency, in lieu of attestation. The OMB memorandum suggests that use of this process might be especially useful for open source software, or products incorporating open source software.

Beyond the simple attestation form, agencies may also request artifacts in future solicitations, such as a complete Software Bill of Materials (SBOM), depending on the criticality of the software or the agency's determination of need.

To facilitate information sharing with the government, within the next two years CISA will establish a government-wide repository for software attestations and artifacts. As needed, CISA also will publish updated SBOM guidance for federal agencies.

What if my software does not fully comply?

In exceptional circumstances, and only for limited durations, agencies may seek a waiver of specific requirements from OMB, which will review the requests on a case-by-case basis. OMB will post specific instructions for submitting waiver or extension requests within 90 days.

If a software producer cannot attest to its conformance with one or more practices from the NIST Guidance, the requesting agency shall require the software producer to identify those practices to which they cannot attest, document measures in place to mitigate risks, and require a Plan of Action & Milestones (POA&M) to be developed. The POA&M and other documentation will not be posted publicly by either the vendor or the agency. If the software producer supplies this documentation and the agency finds the POA&M satisfactory, the agency may use the software despite the producer's inability to provide a complete self-attestation.

What if my company does not develop software, but uses third-party software in its products?

The scope of the attestation requirement extends not just to stand alone software and cloud-based software-as-a-service offerings but also to other products that incorporate third-party software. Under the process as described, the attestation must come from the software "producer" itself. But companies that incorporate third-party software into their own products will have a vested interest in ensuring compliance by their essential software subcontractors, as the end products incorporating the software may not be sold to the government absent an attestation (or use of an alternative assessment methodology, or an agency waiver).

Conclusion

By requiring software producers to attest to compliance with the NIST Guidance, the government aims to ensure that companies undertake a risk-based approach to secure software development, which ultimately will help ensure the overall security of federal information systems. Given the deadlines, all companies that sell (or want to sell) software to the government, whether directly or through resellers or other channels, should quickly assess their compliance with the NIST Guidance, develop action plans to address any gaps, and carefully document their activities. Some companies may be required to rethink development strategy for new products or major version upgrades. As with all recent government cybersecurity initiatives, dates may slip and the contours of the requirements may change around the edges, but the basic policy directive here is clear, and software producers that intend to keep the U.S. government as customers need to get on board. In addition, contractors whose products rely upon or incorporate software will need to ensure that the vendors upon which they are dependent are fully engaged in the attestation process.

By implementing the policy through an attestation form rather than a contract clause, the government is making sure software producers are directly involved in the process, and are legally liable, under False Statements and False Claims Act authority, for any misrepresentations or misstatements. This was surely a deliberate decision to reinforce the seriousness of the issue and to help ensure more widespread compliance. As with any attestation or certification requirement, the new policy brings with it the potential for enforcement actions, whether initiated by the government or by False Claims Act qui tam relators. Software vendors therefore should pay particular attention to their compliance assessments and the representations that they make going forward.

Footnote

1. A prior OMB memorandum directed NIST to issue guidance of security measures for "critical software," defined as any software that has, or has direct software dependencies upon, one of more components with at least one of these attributes:

• is designed to run with elevated privilege or manage privileges;
• has direct or privileged access to networking or computing resources;
• is designed to control access to data or operational technology;
• performs a function critical to trust; or
• operates outside of normal trust boundaries with privileged access.

Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Morrison & Foerster LLP. All rights reserved