Roadmap for Improving U.S. Software Supply Chain Security
Multiple front-page cyberattacks in recent months have enhanced focus on U.S. infrastructure and supply chain security. Three nearly sequential events – the SolarWinds hack, the Microsoft Exchange exploit, and the Colonial Pipeline ransomware incident – have rendered in stark relief national cybersecurity vulnerabilities to both advanced persistent threats and cybercriminals. In response to these and other incidents, President Biden issued an Executive Order (EO) on May 12, which broadly addressed several key areas for improvement in cybersecurity. This EO is sweeping in its vision and reach and is likely just the beginning of this administration’s initiatives to enhance national cybersecurity.
The EO itself is wide-ranging in its applicability to both the U.S. federal government and private companies that supply critical software products to the U.S. government. Of special note for private companies (especially those that supply IT/OT products or are parts of the Defense Industrial Base) is Section 4, which requires the Secretary of Commerce, in consultation with others, to define “critical software”, the development of new guidance for its protection, and new public/private initiatives to ensure the security of the software supply chain for both the government and consumer markets. This article examines Section 4 (Software Supply Chain security) in greater detail, highlighting critical initiatives and timelines that software vendors should closely monitor.
Mandate for Increased Transparency and Security in Software Development
At the highest level, Section 4 seeks to improve the security of software supplied to the U.S. government and consumers by establishing baseline security standards for the development of such software, including requiring developers to maintain and provide greater visibility into different components that are used within their software, and requiring vendors to make such security data publicly available. By directing federal purchasing power, this EO makes full use of executive authority to enact standards and coordinate agency procurement to drive the market to build security into all software from the ground up.
Section 4 initiates over the next year, with the issue date of the EO as Day 0, multiple workstreams led by the National Institute of Standards and Technology (NIST) and other federal government organizations. The section seeks to engage leading private sector, non-federal organizations, and agencies to establish guidance on software supply chain security. As described below, the timelines for the publication of various guidelines and compliance mandates seek a fast-paced enhancement of the nation’s software supply chain security posture.
The workstreams identified in Section 4 of the EO are:
- Publishing of guidelines and best practices for software supply chain security
- Identification and protection of Critical Software used by government agencies
- Update of FAR requirements for the purchase of new software by government agencies, and remediation of previously purchased software, to ensure NIST guidelines are followed by vendors
- Initiation of pilot programs for security labeling for IOT devices and consumer software
Establish New Guidelines and Best Practices for Security of the U.S. Government’s Software Supply Chain
The EO directs NIST to publish Preliminary Software Supply Chain Security Guidelines, followed by best practices guidance, and requires that the Office of Management and Budget (OMB) subsequently mandate agency implementation of the Software Supply Chain Security Practices when procuring software. The Software Supply Chain Security Practices must address the following topic areas:
- Secure software development environments
- Generating and providing artifacts that demonstrate conformance to secure software development processes
- Employing automated tools, or comparable processes, to maintain trusted source code supply chains
- Employing automated tools, or comparable processes, that identify and remediate known and potential vulnerabilities
- Providing, when requested by a purchaser, artifacts of the execution of the tools and processes described above and making publicly available summary information on completion of these actions
- Maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes
- Performing audits and enforcement of above provenance controls on a recurring basis
- Maintaining and providing a purchaser a Software Bill of Materials (SBOM) for each product
- Participating in a vulnerability disclosure program that includes a reporting and disclosure process
- Attesting to conformity with secure software development practices
- Ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.
The EO also requires that NIST, after consulting with the National Security Agency, publish testing guidelines for vendors of software to the U.S. Government, which must include identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).
| Date | Action |
| June 2-3, 2021 | NIST solicits input to identify existing or develop new standards, tools, and best practices for complying with the standards, procedures, or criteria for practices that enhance the security of the software supply chain. (Sec.4(b)). On June 2nd & 3rd NIST hosted a workshop with more than 1400 participants who submitted more than 150 papers providing input regarding software supply chain security |
| ~ July 11, 2021 (by Day 60) | The Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM. (Sec.4(f)) |
| ~ July 11, 2021 (by Day 60) | Director of NIST shall publish guidelines recommending minimum standards for vendors’ testing of their software source code. (Sec. 4(r)) |
| ~ Nov. 8, 2021 (by Day 180) | NIST publishes preliminary guidelines for enhancing software supply chain security (Preliminary Software Supply Chain Security Guidelines). (Sec.4(c)) |
| ~ Feb. 6, 2022 (by day 270) | Within 90 days of publication of the Preliminary Software Supply ChainSecurity Guidelines NIST shall issue guidance identifying practices that enhance the security of the software supply chain (Software Supply Chain Security Practices). (Sec.4(e)) |
| ~ March 6, 2022 (by Day 300) | Within 30 days of issuance of Software Supply Chain Security Practices, Director of OMB acting through the Administrator of the Office of Electronic Government within OMB shall take appropriate steps to require that agencies comply with Software Supply Chain Security Practices identified by NIST with respect to software procured after the date of this order. (Sec.4(k)) |
| ~ May 8, 2022 (by Day 360) | NIST shall publish additional guidelines that include procedures for periodic review and updating of the Preliminary Software Supply Chain Security Guidelines. (Sec.4(d)) |
Identification and Protection of Critical Software Used by Federal Agencies
The EO calls for NIST to consult with the NSA, OMB, Cybersecurity and Infrastructure Security Agency (CISA) and Director of National Intelligence (DNI) to define “Critical Software” and publish “Critical Software Security Guidance” outlining security measures to be applied to federal government use of critical software, including the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.
| Date | Action |
| June 26, 2021(by Day 45) | NIST shall publish a definition of the term “critical software” for inclusion in the guidelines for enhancing software supply chain security. (Sec.4(g)). On June 24th, NIST published a definition for critical software. In addition, NIST provided a prelim list of software categories noting that CISA, will provide the authoritative list |
| ~ July 11, 2021(by Day 60) | Director of NIST shall publish guidance outlining security measures for critical software (Critical Software Security Guidance). (Sec.4(i)) |
| ~ July 26, 2021(by day 75) | Within 30 days of the publication of the definition of critical software (within 75 days of EO) Director of CISA shall identify and make available to agencies a list of categories of software and software products in use or in the acquisition process meeting the definition of critical software. (Sec.4(h)) |
| Aug. 11, 2021(by Day 90) | Within 30 days of NIST publication of Critical Software Security Guidance, Director of OMB shall take appropriate steps to require that agencies comply with such guidance (Sec.4(i)) |
Update of FAR Requirements for the Purchase of New (and Remediation of Already Purchased) Software by Government Agencies
Following the publication and establishment of security guidelines and best practices, the EO directs that the Federal Acquisition Regulations be updated to require contract language requiring suppliers of all new software purchased by the U.S. federal to comply with published guidelines and best practices.
| ~May 12, 2022(within 1 year) | 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 Critical Software Security Guidance. (Sec.4(n)) |
| After May 12, 2022(after 1 year) | After receiving recommendations described in subsection (n) of this section, the FAR Council shall review the recommendations and, as appropriate and consistent with applicable law, amend the FAR. (Sec.4(o)) |
| After May 12, 2022(after 1 year) | Following the issuance of any final rule amending the FAR as described in subsection (o) of this section, agencies shall remove software products that do not meet the requirements of the amended FAR from all indefinite delivery indefinite quantity contracts; Federal Supply Schedules; Federal Government-wide Acquisition Contracts; Blanket Purchase Agreements; and Multiple Award Contracts. (Sec.4(p)) |
| After May 12, 2022(after 1 year – though timing unclear in EO) | The Director of OMB shall require agencies employing software developed and procured prior to the date of this order (legacy software) either to comply with Software Supply Chain Security Practices or to provide a plan outlining actions to remediate or meet those requirements. The Director of OMB shall further require agencies seeking renewals of software contracts, including legacy software, to comply with Software Supply Chain Security Practices, unless an extension or waiver is granted. (Sec.4(q)) (Sec.4(q)) |
Security Labelling for IoT Devices and Consumer Software
The EO also requires the establishment of pilot programs to create an “energy star” type of label for software so the federal government – and the public at large – can quickly determine whether software was developed securely. A similar pilot will address the security capabilities of Internet of Things (IoT) devices.
| ~ Feb.6, 2022 (by Day 270) | The Director of NIST shall identify IoT cybersecurity criteria for a consumer labeling program and shall consider whether such a consumer labeling program may be operated in conjunction with or modeled after any similar existing government programs consistent with applicable law. The criteria shall reflect increasingly comprehensive levels of testing and assessment that a product may have undergone and shall use or be compatible with existing labeling schemes that manufacturers use to inform consumers about the security of their products. (Sec.4(t)) |
| ~ Feb. 6, 2022 (by Day 270) | The Director of NIST shall identify secure software development practices or criteria for a consumer software labeling program, and shall consider whether such a consumer software labeling program may be operated in conjunction with or modeled after any similar existing government programs, consistent with applicable law. The criteria shall reflect a baseline level of secure practices, and if practicable, shall reflect increasingly comprehensive levels of testing and assessment that a product may have undergone. (Sec.4(u)) |
| May 13, 2022 | Within 1 year of the date of this order, the Director of NIST shall conduct a review of the pilot programs, consult with the private sector and relevant agencies to assess the effectiveness of the programs, determine what improvements can be made going forward, and submit a summary report to the APNSA. (Sec.4(w)) |
Impact to Companies
It is imperative for companies that supply software to U.S. federal government customers to stay vigilant of when NIST standards are released and become requisite for software, critical and otherwise, procured by government agencies. As major software companies act in accordance, these security guidelines, transparency measures, and resistance-to-attack practices will become essential best practices in the commercial sector as well, setting the tone for commercial software providers.
For organizations that supply to the federal government, particularly in the Defense Industrial Base, it is important to read the relevant sections of the Executive Order in light of current cybersecurity obligations like DFARS 252-7012 and NIST SP 800-171 and the Department of Defense’s Cybersecurity Maturity Model Certification (CMMC) initiative, with special focus on controls around software development security. Software vendors should also begin planning and preparing for an overhaul of their current supply chain security programs in anticipation of the new guidelines. A useful starting point to understand where NIST may be heading with the new guidelines will be to review existing NIST publications such as SP 800-161 “Supply Chain Risk Management Practices for Federal Information Systems and Organizations.”
How Ankura Can Help
Software Supply Chain Risk Management (SCRM): Downstream software supply chain compliance starts with a calibrated approach to monitor, understand, and document software supply chain risk. Ankura helps companies:
- Conduct supply chain compliance program mapping assessments as part of an overall SCRM program;
- Identify applicable regulatory requirements based on the sector, service/product, and other relevant factors;
- Conduct supply chain security audits and testing to identify latent supply chain security risks; and
- Perform product integrity and security testing to identify potential security and supply chain issues and risks.
We also work with clients and their counsel to develop and implement mitigation measures that effectively address national security concerns, including policies, procedures, and operational processes for sensitive data protection, cybersecurity protocols, personnel screening, and physical access controls. Our National Security, Trade, and Technology (NSTT) practitioners routinely work with federal contractors of all sizes to implement robust software SCRM practices.
Cybersecurity Program Assessments and Remediation: Our experts help companies and organizations implement policies, processes, and other elements of an internal control framework to comply with impending regulatory changes. Ankura has designed compliance programs and internal controls that implement a range of emerging national security-related regulations. Specific activities include conducting cybersecurity maturity posture and risk assessments, developing and operationalizing policies and processes, development and delivery of security awareness training, strategy around secure software development, and designing and testing of internal controls.
Application Penetration Testing: Ankura assists clients in assessing the risks and threats to information systems and products, and the vulnerabilities present in IT environments, data assets, and industrial operations by performing comprehensive technical tests and remediating identified security exposures. Our technical capabilities enable us to probe systems – as insiders or external ethical hackers – to understand the vulnerabilities and potential attack vectors of client systems, and help clients understand and resolve security gaps.
© Copyright 2021. The views expressed herein are those of the author(s) and not necessarily the views of Ankura Consulting Group, LLC., its management, its subsidiaries, its affiliates, or its other professionals.
Ankura is not a law firm and cannot provide legal advice.
