UPDATE: Secure Software Development Attestation: A(nother) Government Requirement

UPDATE:

As follow-on guidance to Office of Management and Budget’s (OMB) September 14, 2022 memo and the associated Executive Order on Improving the Nation’s Cybersecurity from May 2021, the Cybersecurity and Infrastructure Security Agency of the Department of Homeland Security (CISA) has recently released a draft form for companies to attest to secure software development practices. A copy of the draft form can be found on the agency’s website here.

While OMB’s memo provides direction to agencies, any company that produces software and expects to license to government end users should expect contract clauses requiring a self-attestation.

In addition to the release of a draft common form for self-attestation, an extension to the deadline for compliance is anticipated but not yet confirmed. As noted below, the draft form of common attestation is open to comment until June 26, 2023.

Notable aspects of the draft form include:

1. Section III lists practices the software provider is attesting to “presently” making “consistent use of,” which practices are “drawn from the secure software development framework” and includes a positive obligation on the software producer to notify all impacted agencies if conformance to any element of the attestation is no longer valid.
2. The form also allows for an attestation to be given on a company-wide level, as well as by individual product, product line and for multiple products or product versions as listed in the attestation.
3. It also provides additional clarity with respect to the ongoing process for self-attestation by a software producer, including the requirement that the CEO or designee employee sign the attestation, approach to the use of open-source software and ongoing notice obligation of invalidity.
4. Open-source software components are not subject to attestation requirements (as they are out of scope of OMB Memorandum M-22-18); however, software producers who use open source software in their software must attest to taking certain steps outlined in the draft form regarding the use of such freely available software. These steps are intended to minimize the risks posed by using open source software in their products. Note that specific agencies may provide additional instructions to software producers outside the common form generally or with respect to open-source specifically.

The form of self-attestation is open to public comment, which will be accepted until June 26, 2023. They may be submitted electronically using the comment feature here. Additional instructions regarding comments can be found here.

----

On September 14, 2022, the Office of Management and Budget (“OMB”) issued a memorandum on Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (“OMB Memo”) to help ensure software security. While the OMB Memo provides direction to agencies, any company that produces software (defined as firmware, operating systems, applications and application services, such as cloud-based Software as a Service, or products that include software) and expects to license to government end users must:

• Develop the software in accordance with the National Institute of Standards and Technology (“NIST”) risk-based secure software development standards,
• Provide a self-attestation, and
• Produce, if requested, documentation such as a software bill of materials or participation in a vulnerability disclosure program.

These requirements apply to agency (and contractor) use of software developed, as well as the use of existing software that is modified by major version changes, after September 14, 2022.

Background

Last year, President Biden required federal agencies to enhance agency cybersecurity capabilities and protect the nation’s critical software supply chain. See Executive Order 14028 (“Cyber EO”). The Cyber EO tasked NIST with developing guidance on supply chain security which NIST completed in February 2022. NIST developed and published the NIST Guidance consisting of: (1) the Secure Software Development Framework (“SSDF”) Version 1.1 detailing secure software development best practices, and (2) Supply Chain Security Guidance for federal agencies on how to procure software, including open-source software and agency-developed software.

Last week’s OMB Memo requires federal agencies to comply with the NIST Guidance when using third-party “software” on the agency’s information systems or otherwise affecting the agency’s information.

What Must Companies Do:

If a company develops and licenses “software” defined as firmware, operating systems, applications, and application services (such as cloud-based Software as a Service) or products that include software to government entities then the company must determine if their software development process meets the NIST Guidance for secure software development.

Provide a Self-Attestation

After analyzing the software development process against the NIST Guidance, the company must self-attest that it follows those secure development practices – this self-attestation is the “conformance statement” under the NIST Guidance. If a company cannot provide the attestation in the government’s requested format, it can document how it will mitigate those risks in a Plan of Action & Milestones (“POA&M”). In lieu of self-attestation, companies may also provide assessments prepared by certified FedRAMP Third Party Assessor Organizations (“3PAO”). Agencies may require a formal 3PAO assessment depending on the criticality of the product.

The Federal Acquisition Regulatory Council will develop a uniform standard attestation form but until the final rule comes out, any self-attestation must include:

• The Software Producer’s name
• The most inclusive description of the products the statement includes (preferably companywide or product-line statements and all unclassified products).
• An attestation that the Software Producer follows secure development practices and tasks as stated in the attestation.

Document your Software Development

The OMB Memo explains that companies may submit to federal agencies artifacts that demonstrate conformance to secure software development practices. Further, the federal agency may require a Software Bill of Materials (“SBOM”) in solicitation requirements, based on the criticality of the software. According to OMB, artifacts other than the SBOM (e.g., from the use of automated tools and processes which validate the integrity of the source code and check for known or potential vulnerabilities) may also be required. Companies should be prepared to provide these documents with solicitation responses and ensure that the sales team is equipped to answer questions regarding secure software development process.

Key Takeaways

Companies providing software or code to the government should:

• Anticipate the government requirement: Because of the cascading impact, companies should examine the NIST Guidance now to ensure that it follows the secure software development principles. Start implementing any changes necessary today.

• Prepare a draft self-attestation: While the FAR Council finalizes rulemaking, develop a self-attestation with the type of information that the OMB Memo requires.

• Pull your Software Bill of Materials: Because federal contractors, including commercial-off-the-shelf (“COTS”) companies, will likely see these requirements built into solicitations and contract terms, develop your SBOM now so you have it ready to respond to the solicitations.

• Consider proactively publishing your self-attestation and SBOM: If possible, determine whether you can provide your self-attestation and SBOM securely on your website. (However, DO NOT publicly post your gap analysis, risk mitigation plan, or POA&M.)

• Evaluate how this requirement intersects more broadly with other software supply chain considerations: Your company may also have to contend with export controls applicable to your product and technology, the foreign ownership, control or influence (“FOCI”) factors in maintaining a security clearance or selling to customers in the defense/intelligence sector, and other federal procurement restrictions on sourcing software components or allowing its inspection in certain countries such as China or Russia. We can advise you on how to strategically navigate all of those factors together and implement internal controls that can satisfy all requirements at once.