On September 14, 2022, the Director of the Office of Management and Budget (“OMB”) issued a memorandum to the heads of executive branch departments and agencies addressing the enhancement of security of the federal software supply chain. The memorandum applies to all software (other than agency-developed software) developed or experiencing major version changes to be operated “on the agency’s information systems or otherwise affecting the agency’s information,” and requires new self-attestations from software vendors before that software can be used by agencies.
The memorandum is one among many deliverables stemming from Executive Order 14028, “Improving the Nation’s Cybersecurity,” issued by President Biden on May 12, 2021 (the “Cyber EO”). We have covered developments under this Executive Order as part of a series of monthly posts, with the first blog summarized the Cyber EO’s key provisions and timelines, and the subsequent blogs described the actions taken by various Government agencies to implement the Cyber EO from June 2021 through August 2022. Key requirements of the memorandum are discussed in more detail below.
Self-Attestation of Secure Development Practices and Third Party Assessments
The memorandum represents a significant step in implementation of the Cyber EO. It mandates that to use software, agencies must first obtain a self-attestation from software providers that the software developer follows the secure development processes described by NIST Secure Software Development Framework (SP 800-218) and the NIST Software Supply Chain Security Guidance (discussed here) (collectively, “NIST Guidance”). The Federal Acquisition Regulatory Council (“FAR Council”) will propose rulemaking on a standard self-attestation form, although the memorandum requires each agency to begin to obtain self-attestations from vendors regardless of whether the FAR is amended to provide a standard self-attestation form. The memorandum indicates that a self-attestation would contain at least the following elements[1]:
- The software producer’s name;
- A description of which product or products the statement refers;
- A statement attesting that the software producer follows secure development practices and tasks that are itemized in the standard self-attestation form.
Given the lack of a FAR rule, contractors may be faced with differing, and potentially conflicting, requirements for attestation and should scrutinize the requests until a common attestation is developed.
Where a software provider cannot attest to all required security practices, then the software provider may document those practices that are in place, and describe the plan for implementing the remaining practices in a Plan of Action and Milestones (“POA&M”). The determination as to whether the implemented controls and the POA&M are satisfactory will rest with the agency.
The memorandum also notes that “[s]elf-attestation is the minimum level required,” and that in some cases the criticality of the service or product may warrant a third party assessment in addition to the self-assessment. The criticality of the software will be determined either based on the factors of a memorandum issued by OMB on August 10, 2021 (which we discussed here) or will otherwise be based on the agency’s determination. Where these third party assessments are conducted by a certified FedRAMP Third Party Assessor Organization (“3PAO”) or one approved by the agency, and where the NIST Guidance is used as assessment baseline, then a self-attestation may not be required. There is no additional guidance on how these third party assessments should be implemented.
Importantly, the term “software” for purposes of the vendor self-attestation required by the memorandum is quite broad. It expressly includes (in addition to conventional software) “firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.”
Software Bill of Materials
In addition to requiring agencies to collect self-attestations for any software used, the memorandum also provides that a Software Bill of Materials (“SBOM”) or other artifact may be required by the agency in solicitation requirements. If required, SBOMs must either be retained by the agency or posted on the website of the software producer. SBOMs must be generated in the format set forth in a report issued by the National Telecommunications and Information Administration or successor guidance by the Cybersecurity and Infrastructure Security Agency (“CISA”).
Acquisitions and Timing of Implementation
The memorandum indicates that agencies can ensure compliance either through specification of the requirements in the Request for Proposal or in other solicitation documents. The requirements are expected to be implemented by agencies at a fairly rapid pace:
- Within 120 days of publication of the memorandum (January 12, 2023), agencies are required to develop a consistent process to communicate relevant requirements in this memorandum to vendors.
- Within 270 days of publication of the memorandum (June 11, 2023),[2] agencies are required to collect self-attestation letters from “critical software” providers.
- Within 365 days of publication of the memorandum (September 14, 2023), agencies are required to collect self-attestation letters from all software providers.
It is also anticipated that concurrent with these implementation steps, CISA will work to develop a federal interagency software artifact repository, although full operational capability of the repository appears to be contemplated to occur much later. Extensions and waivers may be granted to agencies in certain cases.
Implications for Contractors
There is uncertainty in exactly how contractors will be impacted by the implementation of these requirements. Some initial questions are as follows:
- Scope and Nature of Third Party Assessments. The requirement for third party assessments of compliance with secure software development practices represents a potentially significant risk for developers that sell “critical” software to the Government. Along these lines, the memorandum does not establish guidance on how these assessments would occur or whether and how any deficiencies identified during an assessment may be remediated by the software developer. Moreover, the guidance does not indicate what the scope of these assessments might be. Along these lines, the memorandum indicates a preference for self-attestations to be broad, “preferably focused at the company or product line level and inclusive of all unclassified products sold to Federal agencies.” Thus, it is not clear whether an entire company would be assessed, or only the individualized product or service, or even whether such a distinction would be possible to draw given the scope of the supply chain security requirements.
- Impacts to Hardware and IT Service Providers. The memorandum is clear that these self-attestations must be obtained directly from the software producer. However, in many cases software producers are not in direct privity with the Government, and either may sell through a third party retailer, or sell to hardware or IT service providers for integration into an end-product or service. Moreover, in some cases the sales of these end-products to integrators or resellers may only represent a small amount of revenue for the software developer. Where this is the case, then obtaining a self-attestation from the software developer may be challenging. Although the memorandum contemplates that agencies may obtain an extension or a waiver, the guidance notes that waivers will be granted “only in the case of exceptional circumstances and for a limited duration.”
- Timing of Implementation. As noted, self-attestations will be required from “critical software” providers by June 11, 2023 and by all software providers by September 14, 2023. This only allows for a limited time window for those software developers to implement the supply chain security practices contemplated by the memorandum and to achieve sufficient confidence in that implementation in order to issue certifications to the Government. Even where the use of POA&Ms is possible, it is not clear what agencies will be willing to accept, which could create uncertainty for many software providers that are making determinations about where to locate software development resources and other investments that may need to be made to continue sales to the Government as an end-customer.
- Existing Software. The memorandum only requires self-attestation for new software releases and for major version changes of software. To that end, these certifications could potentially represent another hurdle to agencies facing complex software updates and mitigations. Where the marketplace has few options for alternatives, this may encourage some agencies to choose to keep old software running for longer than would otherwise be the case, and even delay planned upgrades where a obtaining a self-certification is not possible. Accordingly, some contractors could see extensions of support contracts and requests for continued patches where they are unable to attest to the new requirements.
- Artifacts. In a number of areas, contractors may be required to submit artifacts or information to agencies that address the composition of their software and the software development practices used in creating their products. The NIST Guidance recognizes that certain artifacts – “low level” artifacts generated during software development – are likely to contain intellectual property and proprietary information. As such it recommends agencies avoid seeking such information. Nonetheless, contractors will want to consider addressing how the government will secure the artifacts and information it provides and ensure that appropriate markings are included on any submission to protect intellectual property rights.
- Competitive Evaluations. The memorandum also states that agencies must “integrate the NIST Guidance into their software evaluation process…” The memorandum envisions this occurring in a number of ways including as requirements in a solicitation. They also could show up as evaluation factors. No matter how imposed, these requirements may become the focus of future bid protests.
[1] The memorandum describes these as “minimum requirements.”
[2] The 270 day mark falls on a Sunday, so the implementation deadline could occur a couple of days earlier.