On February 4, 2022, the National Institute for Standards and Technology (“NIST”) published its Recommended Criteria for Cybersecurity Labeling of Consumer Software (“Software Labeling Criteria”).  NIST also published guidance to federal agencies regarding practices for enhancing software supply chain security when they acquire software (“Supply Chain Security Guidance”).  Both the Software Labeling Criteria and the Supply Chain Security Guidance were issued by NIST pursuant to Section 4 of Executive Order 14028, “Improving the Nation’s Cybersecurity” (the “Cyber EO”), which was issued by President Biden on May 12, 2021.  The Cyber EO and its implementation are the subject of several previous Covington blogs that are available here.

These documents have relevancy to U.S. government contractors and technology companies alike.  The Software Labeling Criteria may serve as a model for labeling requirements on software products purchased by consumers, and therefore should be reviewed closely by all software developers and resellers.  The Supply Chain Security Guidance will likely have more immediate impacts, as the Cyber EO requires (1) that the Office of Management and Budget (“OMB”) take “appropriate steps” to require that agencies comply with the Guidance with respect to software purchased after the date of the EO, and (2) that the FAR to be amended to require all agencies to procure software (defined to include firmware, operating systems, applications, and cloud-based services) in accordance with the Guidance.

The Software Labeling Criteria

The Software Labeling Criteria identify the key elements for a potential consumer software cybersecurity labeling program that would be established by an organization other than NIST.  The purposes of such a program would be to “aid consumers in their software selection decisions by enabling comparisons among products and educating them about software security considerations,” and potentially also “encourage [software] providers to consider cybersecurity aspects of their software and ways to achieve greater trust and confidence in the software, and, ultimately, to improve the management of related cybersecurity risks.”  The Software Labeling Criteria recommend considerations for three key aspects of a potential consumer software cybersecurity labeling program.  These key aspects are: (1) Baseline Product Criteria, (2) Labeling, and (3) Conformity Assessments.

These are the same three aspects that NIST identified as key aspects in its Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things Products (“IoT Criteria”), which NIST issued on the same date that it issued the Software Labeling Criteria.  Readers should therefore review the IoT Criteria and the Software Labeling Criteria together.  A blog that overviews the IoT Criteria is available here.

Baseline Product Criteria

The Software Labeling Criteria provides technical baselines for a series of labeling “claims” about the software.  These claims fall into two categories: (1) “Descriptive Claims,” and (2) “Secure Software Development Claims.”  Descriptive claims encompass both claims about the organization making the claims on the label and what the label is describing.  Secure Software Development Claims describe how the software provider claims to adhere to accepted secure software development practices throughout the software development lifecycle.  Several of these claims reference the Secure Software Development Framework that NIST published on February 4, 2022.

The Software Labeling Criteria identify the following Descriptive Claims: Claimant, Label Scope, Software Identifiers, Claim Date, Security Update Status, Minimum Duration of Security Update Support, and Security Update Method.  The Criteria identify the following Secure Software Development Claims: Implements a Secure Software Development Process, Practices Secure Design and Vulnerability Remediation, Practices Responsible Vulnerability Reporting Disclosure, Uses Multifactor Authentication (if applicable), Free From Hard Coded Secrets, Uses Strong Cryptography (if applicable), and User Data Is Identified and Secured.  For each of these claims, the Software Labeling Criteria provides a statement about what information the claim should capture (“Description”), the outcome and/or reasoning for including the claim in the label, focusing on how this benefits the user of the label (“Desired Outcome”), and factual statements made by the claimant that are conveyed with the claim (“Assertions”).  Thus, when referenced by the label, the consumer is informed about these outcome-based assertions and associated information.

Labeling

The Software Labeling Criteria identifies two recommended approaches to cybersecurity labeling.  The first is a “Binary label.”  Under this approach, “the product has a single, consumer-tested label indicating that the software has met the criteria required to receive the label.”  The second is “Layered Approach.”  Under this approach, the label “provides a means for consumers to access additional information about the labeling program as well as declaration of conformity information for the software.”  The Criteria recommends that the binary label be coupled with a layered approach in which one of the following is included on the label to lead consumers to additional details online:

  • a URL (e.g., as included in Singapore’s cybersecurity label [SINGAPORE], not a shortened URL, which is not easily attributable to the source domain; or
  • a scannable code (e.g., a QR code).

The Software Labeling Criteria also recommends that labels be available to consumers before and at the time and place of software selection (in-store or on-line) as well as after selection, that digital labels (e-labels) be available for all products, and that a robust consumer education program be developed to establish and increase consumer label recognition.

Conformity Assessment

The Software Labeling Criteria defines “conformity assessment” as a “term that describes the formalized process for demonstrating that specified requirements are fulfilled.”  A conformity assessment scheme consists of a set of rules and procedures that –

  • describes the objects of conformity assessment (e.g., a consumer software);
  • identifies the specified requirements (e.g., the recommended technical baseline criteria);
  • identifies the activity for performing conformity assessment (e.g., testing, inspection, certification, self-declaration of conformity, etc.); and
  • defines roles and the types of organizations performing each role (e.g., first, second, or third parties).

The Software Labeling Criteria notes that, given the range of consumer software and associated risks, “no single assessment approach is appropriate,” and that NIST therefore was not recommending a particular set of conformity assessment requirements.  Rather, NIST suggests that the labeling scheme owner “tailor the recommended criteria, define conformity assessment requirements, develop the label and associated information, and conduct related consumer outreach and education.”  However, NIST notes that “there are several conformity assessment activities that could be leveraged in consumer software scheme to demonstrate conformity to the recommended criteria,” including –

  • Supplier’s declaration of conformity (self-attestation) where the declaration of conformity is performed by the organization that provides the software;
  • Third-party testing or inspection where there is determination or examination of the consumer software based on defined criteria; or
  • Third-party certification of the consumer software.

The Supply Chain Security Guidance

Section 4(e) of the Cyber EO requires NIST to publish guidelines on practices for software supply security for use by U.S. government acquisition and procurement officials.  Section 4(k) of the EO requires the Office of Management and Budget, within 30 days of the publication of this guidance (or March 4, 2022),  to “take appropriate steps to require that agencies comply with such guidelines with respect to software procured after the date of” the EO.  Section 4(n) of the EO states that within one year of the date of the EO (or May 12, 2023), the Secretary of Homeland Security…shall recommend to the FAR Council contract language requiring suppliers of software available for purchase by agencies to comply with, and attest to complying with, any requirements issued pursuant to subsections (g) through (k) of this section.”

The Supply Chain Security Guidance issued by NIST on February 4, 2022 constitutes the guidelines called for by Section 4(e) of the EO.   The Supply Chain Security Guidance states that it “provides recommendations to federal agencies on ensuring that the producers of software they procure have been following a risk-based approach for secure software development throughout the software life cycle”, and that “[t]hese recommendations are intended to help federal agencies gather the information they need from software producers in a form they can use to make risk-based decisions about procuring software.” The scope of the Supply Chain Security Guidance is expressly limited to “federal agency procurement of software, which includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.”  The Guidance further provides that “the location of the implemented software, such as on-premises or cloud-hosted, is irrelevant,” and also excludes open source software and software developed by federal agencies.  However, open-source software that is bundled, integrated, or otherwise used by software purchased by a federal agency is within the scope of the Guidance.

The Supply Chaim Security Guidance defines minimum recommendations for federal agencies as they acquire software or a product containing software:

  1. Use the Secure Software Development Framework (SSDF) terminology and structure to organize communications about secure software development requirements.
  2. Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle.
  3. Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required.
  4. When requesting artifacts of conformance, request high-level artifacts.

The Guidance makes clear that these minimum recommendations apply to all within-scope software procured by federal agencies, including “commercial off-the-shelf (COTS) software product vendors, government off-the-shelf (GOTS) software developers, and contractors and other custom software developers.”  However, the Guidance notes that these recommendations are not intended to replace more stringent requirements for secure software development that agencies may have, and that these minimum practices “may not be sufficient in some cases.”  For example, the Guidance states that an agency “may need greater visibility into the practices for a particular product so that it can better understand how the product would affect the agency’s cybersecurity risk.”  The Guidance acknowledges that agencies requiring greater visibility into practices “may increase costs for software producers, and thus may increase product prices.”

Finally, the Guidance includes several FAQs that provide additional information on the Guidance that are instructive to its intended application.  For example, FAQs 5 and 6 state that agencies can choose to implement the Guidance with respect to software developed by federal agencies and/or open-source software that they freely and directly obtain.  In the same vein, FAQ 9 states that software producers may choose to exceed the Guidance requirements and provides a template that producers may use to identify their greater-than-required secure software development activities or processes.

Print:
Email this postTweet this postLike this postShare this post on LinkedIn
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.

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.