NIST Delivers Two Key Publications to Enhance Software Supply Chain Security Called for by Executive Order

SolarWinds is a large IT company providing software and services for infrastructure management to 499 of the Fortune 500 companies as well as government agencies around the world. In December 2020, it was revealed that the company had suffered a cyberattack. The United States government was quick to recognize the growing threat that cybersecurity poses to the country.

Executive Order 14028

Spurred by attacks such as that on SolarWinds, President Biden signed Executive Order 14028, which is a lengthy document designed to strengthen the nation’s cybersecurity preparedness. The EO directed NIST to deliver research and deliver two documents. On July 9th, 2021, they announced the release of those publications.

Requirements of the Order

To understand the requirements asked of NIST, we need to take a look at Executive Order 14028 as a whole. The order is broken down into four main requirements, outlined below:

  1. Require that any IT or IT security providers that receive federal contracts report any cybersecurity incidents and share any intel they may obtain regarding cybersecurity threats. This is codified by updates to the FAR and DFAR.
  2. Requires federal civilian agencies to bring their cybersecurity standards to match those of the Fortune 1000. This includes cloud adoption, two-factor authentication, additional logging requirements, and mandated endpoint detection and response.
  3. Requires the creation of a Cyber Safety Review Board. This new board will investigate cybersecurity threats in much the same way the NTSB investigations accidents in the transportation sector.
  4. Requires standards to be developed that improve the security of software in use by the federal government. NIST was put in charge of creating these standards. They are detailed in the two documents just released.

Security Measures for EO-Critical Software

The first publication is directly related to the software itself. The EO did not provide a definition of critical software, and instead tasked NIST with defining it. After determining what would qualify as critical software, NIST developed a list of recommended security measures to help thwart cyberattacks. The security measures outlined in this document are applicable to software operation only. Recommended measures for the development of software are in the second publication.

Critical Software Definition

To come up with their definition of critical software, NIST solicited feedback from the community, hosted a virtual workshop, and held discussions with various government agencies. In the resulting white paper, critical software is defined as any piece of software that has one or more of the following characteristics:

  • Is designed to run with elevated privilege or manage privileges;
  • Has direct or privileged access to networking or computing resources;
  • Is designed to control access to data or operational technology;
  • Performs a function critical to trust; or,
  • Operates outside of normal trust boundaries with privileged access.

Recommended Security Measures

Over its 13 pages, the publication outlines security measures federal agencies should put into place when using any EO-critical software. The agency stresses that the list should not be considered exhaustive and should not replace other security measures that are in place. The document breaks its guidance down into five objectives:

  1. Protect EO-critical software and EO-critical software platforms from unauthorized access and usage. For the cases of this objective, EO-critical software platforms are defined as those on which EO-critical software runs. This may include endpoints, servers, and cloud resources.
  2. Protect the confidentiality, integrity, and availability of data used by EO-critical software and EO-critical software platforms. Agencies are granted some autonomy on which of those protections are necessary. For example, information that is available to the public doesn’t need its confidentiality protected.
  3. Identify all EO-critical software or EO-critical software platforms so that they can be maintained and protected from exploitation.
  4. Quickly detect any threats or incidents involved EO-critical software or software platforms and rapidly take steps to respond to, and recover from those threats.
  5. Strengthen the understanding of human actions that foster the security of EO-critical software or software platforms and work to improve the performance of personnel in security measures.

Minimum Standards for Vendor or Developer Verification

The second publication by NIST is aimed at developers and vendors of software. The main focus of the document is on the testing of the product during its development life cycle. Like the previous publication, NIST is careful to warn that the document cannot possibly cover every type of software and every procedure that may be necessary. Instead, the document should be viewed as a set of minimum standards from which vendors and developers can build upon.

Recommended Standards

The full white paper is 30 pages long and has been broken down into a list of categories in the same way the first publication was. For each category, there is a brief description of best practices. The document also include a general list of good software development practices and other useful information. The twelve categories covered by the paper are listed below:

  1. Use threat modeling to look for security issues at the design level and focus verification efforts on those.
  2. Use automated testing to improve accuracy and consistency, and reduce the amount of manual work required.
  3. Look for bugs, security vulnerabilities, or violations of the organization’s coding standards through the use of static code scanning.
  4. Use heuristic tools to ensure there are no hard-coded passwords or private encryption keys that may become a liability.
  5. Use any applicable checks and protections that are built into the software used for development.
  6. Create “black box” test cases to address functional specifications or requirements, test for resiliency to denial of service or overload attempts, and confirm input boundaries.
  7. Based on the specifics of the code, structural testing should be put into place to perform tests that cannot be performed through automation alone.
  8. Repeat test cases used to catch previous bugs. These tests can help ensure the bug doesn’t return and also help catch other issues.
  9. Use a buzzer to provide invalid, random, and unexpected input to the system and monitor for any crashes, exceptions, assertions, or other issues.
  10. Run a web app scanner on any software that might be connected to the internet to ensure there are no vulnerabilities.
  11. Check any libraries, packages, and services that are included in the software to guarantee they are no less secure than your own code.
  12. Fix critical bugs as soon as possible and make improvements to your processes to help prevent such bugs in the future.


Are you working on software that might be potentially impacted by these new standards? If so, Teamspring has a staff full of reliable cybersecurity experts that can help you make sure your processes are complying with the new requirements. Contact us today to find out more.