Secure Software Development Attestation: A(nother) Government Requirement

By: Zohra Tejani, Joyce Tong Oelrich, Melissa Duffy, Mercedes Morno

TL:DR

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.


Login

Don’t have an account yet?

Register