On May 12, 2021 the Biden Administration issued an “Executive Order on Improving the Nation’s Cybersecurity” (EO).  Among other things, the EO sets out a list of deliverables from a variety of government entities.  A number of these deliverables were due in June, including a definition of “critical software,” the minimum requirements for a software bill of materials, and certain internal actions imposed on various federal agencies.

Developments Affecting Enhancement of Software Supply Chain Security

Definition of Critical Software.  Section 4 of the EO stated that the “development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.”  The EO cites a “pressing need” for mechanisms to ensure the “security and integrity” of “critical software.”  The EO broadly defines critical software as “software that performs functions critical to trust” and tasks the Secretary of Commerce, through the National Institute of Standards and Technology (NIST) to develop a definition of critical software that could be used in forthcoming regulations and guidance – including guidance required by the EO on identifying practices that enhance the security of the software supply chain.

On June 25, 2021, NIST issued a white paper providing a definition of critical software.  The white paper followed a workshop that NIST held on June 2-3, 2021 with over 1400 participants and 150 position papers submitted for NIST’s consideration.  In addition to private industry, NIST solicited input from the public as well as reportedly from several government agencies – including the Cybersecurity and Infrastructure Security Agency, the Office of Management and Budget (OMB), the Office of the Director of National Intelligence (ODNI) and the National Security Agency – to help define what critical software means.

NIST’s definition is broad and defines critical software as

any software that has or has direct software dependencies upon, one or more components with at least one of these attributes:

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

According to NIST, this definition preliminarily includes operating systems, web browsers, hypervisors, endpoint security tools, identity and access management applications, network monitoring tools, backup, recovery, and remote storage tools, and other categories of software.

In explaining the definition, NIST expressed its view that the EO’s implementation “must take into consideration how the software industry functions, including product development, procurement, and deployment.”  Further, NIST explained that the term “critical” as used in the EO is not based not on the context of use, “but instead focuses on critical functions that address underlying infrastructure for cyber operations and security.”  Some limited use cases – such as software solely used for research or testing that is not deployed in production systems – are outside of the scope of this definition.

Finally, although the definition applies to all forms of software, NIST recommends that the initial EO implementation phase focus on standalone, on-premises software that has security-critical functions or poses similar significant potential for harm if compromised.  NIST indicated that later implementation of the EO could expand to other forms of software such as software that controls access to data, cloud-based and firmware to name a few.

Other Developments

Software Bill of Materials Minimum Requirements. Section 4(f) of the EO requires the National Telecommunications and Information Administration (NTIA) to publish the minimum elements of a Software Bill of Materials (SBOM), which the EO defines as “a formal record containing the details and supply chain relationships of various components used in building [the] software.”  In preparing to meet the July 11, 2021 deadline for publishing the minimum elements for SBOMs, NTIA issued a request for public comment on the minimum elements for SBOMs and the factors that should be considered in requesting, producing, distributing, and consuming such items.

NTIA’s request notes that an SBOM is similar to a “list of ingredients” and thereby promotes transparency in the software supply chain.  NTIA proposed a definition of the minimum elements of an SBOM that encompasses three broad, inter-related features: (1) required data fields; (2) operational considerations; and (3) support for automation.  Data fields suggested include “supplier name,” “component name,” and “cryptograph hash of the component,” among others.  Operational considerations include a set of operational and business decisions and actions that establish the practice of requesting, generating, sharing, and consuming SBOMs, including “frequency,” “depth,” and “delivery.”  Automation support relates to whether the SBOM can be automatically generated and is machine-readable, which is “[a] key element for SBOM to scale across the software ecosystem.”

Over 86 written comments were submitted in response to NTIA’s request by the June 17, 2021 deadline for such comments.

Other Upcoming EO Deadlines.  The EO imposes other deadlines in June 2021 that may have been met, but for which there is no public access to the results.  These include –

  • Section 2(g)(i) of the EO requires the Department of Homeland Security (DHS), in consultation with the Department of Defense (DoD), the Attorney General, and OMB, to recommend to the FAR Council contract language regarding the reporting of cyber incidents. The EO requires such contract language to identify (1) the nature of the cyber incidents that require reporting; (2) the types of information that must be reported; (3) appropriate and effective protections for privacy and civil liberties; (4) the time periods within which contractors must report cyber incidents based on a graduated scale of severity (with reporting of the most severe cyber incidents not to exceed 3 days from initial detection); (5) National Security Systems (NSS) reporting requirements; and (6) the types of contractors and associated service providers to be covered by the proposed contract language.  We have not yet been able to confirm whether DHS submitted any recommended contract language to the FAR Council or whether, if it did, what such language says.
  • Section 7(c) of the EO requires DHS to provide OMB with recommendations on options for implementing an Endpoint Detection Response initiative to support proactive detection of cyber incidents. A senior Biden Administration official publicly confirmed that DHS had provided such recommendations to OMB, but declined to state what those recommendations are.
  • Section 7(g) of the EO requires NSA to recommend to DOD, ODNI, and the Committee on NSS by June 26, 2021, appropriate actions for improving detection of cyber incidents affecting NSS. Whether those recommendations have been issued has not been publicly disclosed.
Print:
EmailTweetLikeLinkedIn
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.

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 clients on a range of issues related to government contracting. Mr. Burnette has particular experience with helping companies navigate mergers and acquisitions, FAR and DFARS compliance issues, public policy matters, government investigations, and issues involving government cost accounting and the…

Ryan Burnette advises clients on a range of issues related to government contracting. Mr. Burnette has particular experience with helping companies navigate mergers and acquisitions, FAR and DFARS compliance issues, public policy matters, government investigations, and issues involving government cost accounting and the Cost Accounting Standards.  Prior to joining Covington, Mr. Burnette served in the Office of Federal Procurement Policy in the Executive Office of the President, where he worked on government-wide contracting regulations and administrative actions affecting more than $400 billion dollars’ worth of goods and services each year.