NIST Publishes Recommended Criteria for Cybersecurity Labeling for Consumer Software and Guidance to Federal Agencies on Practices to Enhance Supply Chain Security When Procuring Software

By Susan B. Cassidy, Ashden Fein, Robert Huffman & Ryan Burnette on February 15, 2022

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:

Use the Secure Software Development Framework (SSDF) terminology and structure to organize communications about secure software development requirements.
Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle.
Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required.
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.