In May 2021, President Biden issued Executive Order 14028 “Improving the Nation’s Cybersecurity”. This order provided key strategic cybersecurity objectives for Executive Branch agencies as well as their supply chains. The Order included directives for the National Institute of Standards and Technology (NIST) to establish standards and requirements for software security and to include these as contract requirements in the Federal acquisition process beginning in 2022. On February 4, 2022, NIST published Special Publication 800-218 “Secure Software Development Framework (SSDF)” V1.1 (“NIST SP 800-218v1.1”), which seeks to establish “a core set of high-level secure software development practices that can be integrated into [software producers’ software development processes]”. This article summarizes the newly published requirements and the impact on companies that produce software for the U.S. Federal Government.
Background: The Roadmap for Enhancing Software Supply Chain Security
Executive Order 14028 set forth an aggressive timeline for the Federal Government to establish and enforce new software development guidelines to mitigate the risk of future software supply chain attacks such as the SolarWinds breach:
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)).
July 11, 2021
The Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration (“NTIA”), shall publish minimum elements for an SBOM. (Sec. 4(f))
On July 12, 2021, NTIA published The Minimum Elements for a Software Bill of Materials (SBOM).
July 11, 2021
Director of NIST shall publish guidelines recommending minimum standards for vendors’ testing of their software source code. (Sec. 4(r))
On October 6, 2021, NIST published Guidelines on Minimum Standards for Developer Verification of Software.
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))
On October 28, 2021, NIST published 2nd Draft of SP 800-161 Rev.–1 - Cybersecurity Supply Chain Risk Management (C-SCRM) Practices for Systems and Organizations with extended public comment period having closed on December 10, 2021 and final draft to be released Q3 2022.
Feb. 4, 2022
Within 90 days of publication of the Preliminary Software Supply Chain Security Guidelines, NIST shall issue guidance identifying practices that enhance the security of the software supply chain (Software Supply Chain Security Practices). (Sec. 4(e))
On February 4, 2022, NIST published Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e.
March 4, 2022
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))
On March 7, 2022, OMB issued a mandate that agencies are to comply with the guidelines set out in the SSDF effective immediately. A public workshop is scheduled for March 23, 2022 to engage with the private sector on how best to implement mandated vendor attestation of secure software development practices.
May 8, 2022
NIST shall publish additional guidelines that include procedures for periodic review and updating of the Preliminary Software Supply Chain Security Guidelines. (Sec. 4(d))
After May 12, 2022
The Director of OMB shall require agencies employing software developed and procured prior to the date of the 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))
Table 1 – EO 14028 Timeline for Software Development Security
NIST SP 800-218 at-a-Glance
NIST SP 800-218v1.1, The Secure Software Development Framework (SSDF), was written to establish standards for secure development of software through the full Software Development Life Cycle (SDLC). The objective of the SSDF is to “shift security left” in the SDLC, to incorporate security considerations early and often throughout the software suppliers’ internal software development processes.
The SSDF is organized along key Practices, Tasks supporting these Practices, Notional Implementation Examples for such Tasks, and References:
- Practices - 19 high-level organizational outcomes resulting from the implementation of various tasks, which are organized into the following four (4) groups.
- Prepare the Organization (PO) - Practices designed to ensure that people, processes, and technology are prepared to perform secure software development.
- Protect the Software (PS) - Practices designed to protect all components of the software from tampering or unauthorized access.
- Produce Well-Secured Software (PW) - Practices designed to produce well-secured software with minimal security vulnerabilities.
- Respond to Vulnerabilities (RV) - Practices to identify residual vulnerabilities in software releases and to respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.
- Tasks - 42 specific activities to be performed by organization personnel to perform the 19 practices.
- Notional Implementation Examples - Examples of potential tools, processes, or other methods that could be used to implement a task.
- References - References to similar or source controls from other established frameworks such as NIST SP 800-53, ISO/IEC 27001, OWASP, NIST CSF, etc.
As an example, the task below belongs to the Protect the Software (PS) practice and calls for the collection and sharing of provenance data shared across the supply chain through a Software Bill of Materials (SBOM).
Notably, the task also makes reference to the NTIA’s Minimum Elements for a Software Bill of Materials (SBOM) and to the section on “Emerging Software Supply Chain Concepts” in NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations which cover the foundational, sustaining and enhancing capabilities related to this practice.
What’s Next and What Suppliers Should be Doing Now
While the Federal Acquisition Regulation (FAR) has not yet been updated to include any specific clauses relating to NIST SP 800-218, Executive Order 14028 requires:
- Federal agencies to now procure any new software in accordance with the new NIST Framework. In fact, the Office of Management and Budget issued a press release on March 7th advising that “Federal agencies must begin to adopt the SSDF and related guidance effective immediately, tailoring it to the agency’s risk profile and mission.” Although NIST issued guidance to federal agency procurement staff simultaneously with the release of NIST SP 800-218v1.1, OMB’s press release notes that the OMB intends to engage the private sector on how to best implement requirements before directing agencies to require attestations regarding compliance with the new NIST framework.
- That the process to amend FAR to include such clauses and requirements for companies supplying software to the U.S. government begin in Q2 2022.
The bottom line is that the federal government has already started the process to enforce the adoption of the newly-published NIST framework, and future software procurement by the federal government will be contingent on vendors attesting to compliance with the framework. Accordingly, companies that develop software supplied to the U.S. Government should begin engaging with the published NIST requirements and begin documenting and/or re-engineering their software development practices and processes to ensure alignment with the SSDF.
How Ankura Can Help
SSDF / SDLC Program Assessment – Ankura can provide independent and credible third-party assessments of enterprise software development programs and practices to ensure current practices align to the SSDF requirements and industry best-practices.
SDLC Implementation and Enhancement – Ankura has a deep bench of software developers, cybersecurity experts, and former in-house counsel who are focused on helping companies develop comprehensively secure, well-documented, and tested software solutions. Accordingly, Ankura can help clients design and execute concrete security practices from the ground up, ensuring that security is embedded in practice and appropriately documented for compliance.
Secure Environments – Ankura works with companies to implement technical solutions to secure their development environments. From identity and access management to privileged access management, to automated code verification, Ankura’s team can help build the secure development infrastructure required to meet the SSDF.
Software Integrity Testing – Independent static and dynamic testing of software code is key to minimizing risks of critical security flaws. Ankura works with companies to perform both “White Box” and “Black Box” integrity testing to ensure that secure development practices are implemented and effective.
Government Security and Integrity Assurance – Ankura has deep experience working with companies to meet their federal cybersecurity requirements. With deep expertise in NIST cybersecurity and software security frameworks, Ankura works with C-suite, compliance, and technical personnel to effectively meet U.S. Government customer requirements.
Program Sustainment – Ankura has a full suite of services to support a mature cyber and software security program including: (i) managed detection and response (MDR); (ii) incident response; (iii) penetration testing; (iv) V-CISO; and (v) independent audit and assessment.
© Copyright 2022. 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.