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]:

  1. The software producer’s name;
  2. A description of which product or products the statement refers;
  3. 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.

Print:
Email this postTweet this postLike this postShare this post on LinkedIn
Photo of Susan B. Cassidy Susan B. Cassidy

Ms. Cassidy represents clients in the defense, intelligence, and information technologies sectors.  She works with clients to navigate the complex rules and regulations that govern federal procurement and her practice includes both counseling and litigation components.  Ms. Cassidy conducts internal investigations for government…

Ms. Cassidy represents clients in the defense, intelligence, and information technologies sectors.  She works with clients to navigate the complex rules and regulations that govern federal procurement and her practice includes both counseling and litigation components.  Ms. Cassidy conducts internal investigations for government contractors and represents her clients before the Defense Contract Audit Agency (DCAA), Inspectors General (IG), and the Department of Justice with regard to those investigations.  From 2008 to 2012, Ms. Cassidy served as in-house counsel at Northrop Grumman Corporation, one of the world’s largest defense contractors, supporting both defense and intelligence programs. Previously, Ms. Cassidy held an in-house position with Motorola Inc., leading a team of lawyers supporting sales of commercial communications products and services to US government defense and civilian agencies. Prior to going in-house, Ms. Cassidy was a litigation and government contracts partner in an international law firm headquartered in Washington, DC.

Photo of Ashden Fein Ashden Fein

Ashden Fein advises clients on cybersecurity and national security matters, including crisis management and incident response, risk management and governance, government and internal investigations, and regulatory compliance.

For cybersecurity matters, Mr. Fein counsels clients on preparing for and responding to cyber-based attacks, assessing…

Ashden Fein advises clients on cybersecurity and national security matters, including crisis management and incident response, risk management and governance, government and internal investigations, and regulatory compliance.

For cybersecurity matters, Mr. Fein counsels clients on preparing for and responding to cyber-based attacks, assessing security controls and practices for the protection of data and systems, developing and implementing cybersecurity risk management and governance programs, and complying with federal and state regulatory requirements. Mr. Fein frequently supports clients as the lead investigator and crisis manager for global cyber and data security incidents, including data breaches involving personal data, advanced persistent threats targeting intellectual property across industries, state-sponsored theft of sensitive U.S. government information, and destructive attacks.

Additionally, Mr. Fein assists clients from across industries with leading internal investigations and responding to government inquiries related to the U.S. national security. He also advises aerospace, defense, and intelligence contractors on security compliance under U.S. national security laws and regulations including, among others, the National Industrial Security Program (NISPOM), U.S. government cybersecurity regulations, and requirements related to supply chain security.

Before joining Covington, Mr. Fein served on active duty in the U.S. Army as a Military Intelligence officer and prosecutor specializing in cybercrime and national security investigations and prosecutions — to include serving as the lead trial lawyer in the prosecution of Private Chelsea (Bradley) Manning for the unlawful disclosure of classified information to Wikileaks.

Mr. Fein currently serves as a Judge Advocate in the U.S. Army Reserve.

Photo of Robert Huffman Robert Huffman

Bob Huffman represents defense, health care, and other companies in contract matters and in disputes with the federal government and other contractors. He focuses his practice on False Claims Act qui tam investigations and litigation, cybersecurity and supply chain security counseling and compliance…

Bob Huffman represents defense, health care, and other companies in contract matters and in disputes with the federal government and other contractors. He focuses his practice on False Claims Act qui tam investigations and litigation, cybersecurity and supply chain security counseling and compliance, contract claims and disputes, and intellectual property (IP) matters related to U.S. government contracts.

Bob has leading expertise advising companies that are defending against investigations, prosecutions, and civil suits alleging procurement fraud and false claims. He has represented clients in more than a dozen False Claims Act qui tam suits. He also represents clients in connection with parallel criminal proceedings and suspension and debarment.

Bob also regularly counsels clients on government contracting supply chain compliance issues, including cybersecurity, the Buy American Act/Trade Agreements Act (BAA/TAA), and counterfeit parts requirements. He also has extensive experience litigating contract and related issues before the Court of Federal Claims, the Armed Services Board of Contract Appeals, federal district courts, the Federal Circuit, and other federal appellate courts.

In addition, Bob advises government contractors on rules relating to IP, including government patent rights, technical data rights, rights in computer software, and the rules applicable to IP in the acquisition of commercial items and services. He handles IP matters involving government contracts, grants, Cooperative Research and Development Agreements (CRADAs), and Other Transaction Agreements (OTAs).

Photo of Ryan Burnette Ryan Burnette

Ryan Burnette advises defense and civilian contractors on federal contracting compliance and on civil and internal investigations that stem from these obligations. Ryan has particular experience with clients that hold defense and intelligence community contracts and subcontracts, and has recognized expertise in national…

Ryan Burnette advises defense and civilian contractors on federal contracting compliance and on civil and internal investigations that stem from these obligations. Ryan has particular experience with clients that hold defense and intelligence community contracts and subcontracts, and has recognized expertise in national security related matters, including those matters that relate to federal cybersecurity and federal supply chain security. Ryan also advises on government cost accounting, FAR and DFARS compliance, public policy matters, and agency disputes. He speaks and writes regularly on government contracts and cybersecurity topics, drawing significantly on his prior experience in government to provide insight on the practical implications of regulations.

Emma Merrill

Emma Merrill is an associate in the firm’s Washington, DC office. She advises clients on a broad range of issues related to government contracting, including both regulatory and transactional matters. She maintains an active pro bono practice.