Executive Order 14028: NIST SSDF Explained

Last updated: December 17, 2025 | 9 MIN

Developer Advocate

The President’s Executive Order (EO) on “Improving the Nation’s Cybersecurity (14028),” issued on May 12, 2021, charges multiple agencies, including NIST, with enhancing cybersecurity through a variety of initiatives related to the security and integrity of the software supply chain. NIST has created the Secure Software Development Framework (SSDF) to help improve federal agencies’ cybersecurity in line with this EO.

Section 4 of Executive Order 14028 directs NIST to solicit input from the private sector, academia, government agencies, and others and identify existing or develop new standards, tools, best practices, and other guidelines to enhance software supply chain security. Those guidelines are to include:

Criteria to evaluate software security,
Criteria to assess the security practices of the developers and suppliers themselves
Innovative tools or methods to demonstrate conformance with the identified best security practices.

EO Tasks and Timelines

Executive Order 14028’s section 4 also contains a timeline for depicting NIST’s tasks needed to drive this national improvement. This timeline is as follows:

EO timeline for NIST

At the writing of this article, NIST has released preliminary guidance outlining security measures for critical software. This guidance, the NIST SSDF, is based on best development practices from organizations including BSA, OWASP, and SAFECode. The NIST SSDF may be considered a sequel to prior guidelines, with the new guidance serving as an extension of the ideas introduced in the NIST CSF.

NIST SSDF Practices

The NIST SSDF contains four categories of best practices to help promote secure software development practices. These categories are:

Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level and, in some cases, for each project.
Protect the Software (PS): Protect all software components from tampering and unauthorized access.
Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases.
Respond to Vulnerabilities (RV): Identify vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Each category is well documented and consists of the specific practice, the task required, an implementation example, and the respective mapping to an established secure development practice document.

NIST SSDF Baseline Risk Factors

The Federal Acquisition Supply Chain Security Act (FASCA) requires agencies to conduct and prioritize supply chain risk assessments for each dependency added. There is no one-size-fits-all solution, but it is vital to establish and document baseline risk factors. Ensuring this documentation is created and established helps prove the agency performed due diligence. The elements in question include:

Ensuring a level of even treatment of evaluated sources or covered articles
Ensuring minimum necessary information is available to the Federal Acquisition Security Council (FASC) when required
Promoting consistency and comparability across agencies
Aiding the conduct of more sophisticated analyses such as trend analysis or causal or correlation relationships between found indicators of risk and realized risks
Having a base of information sufficient to identify and understand potential mitigation options to inform prioritization or risk response trade-off analysis/decisions, etc.

Organizations should evaluate other factors outside of the scope of just the baseline factors as they deem appropriate.

According to the NIST SSDF, organizations should consider risk in terms of context, vulnerabilities, and threats. Inherent risk or inherited risk may describe these non-exclusive risk factors. Generally speaking, up to three categories of inputs will comprise information pertinent to an assessment:

Purpose and contextual information, such as that specific to the use case, is to understand the risk environment and to inform and establish risk tolerance relative to the use case.
Data and information which are derived from the source.
All source information, which may come from publicly available data, government sources, and/or commercial, fee-based sources. Government sources may also include classified information, though this use case is specific to federal agencies.

Risk Severity Schema

In response to a supply chain risk assessment, organizations need to determine an appropriate risk response from the results of a supply chain risk assessment. NIST introduces a Supply Chain Risk Severity Schema (SCRSS) to assist with this task. This schema helps ensure consistency in the ways that federal agencies view:

The severity of assessed supply chain risk associated with a given source or covered article
The urgency required for risk response
The seniority level necessary for coordinating or making a risk response decision
The information, documentation, and processes required to inform and support risk response efforts

The alignment and consistency created by the SCRSS will help further organizational understanding of supply chain risk inherent to interconnected applications. The SCRSS depicted below is designed to be used as a mapping reference to tie a risk assessment result to the schema level that most closely matches.

Level	Type	Description
1	Agency Low or Moderate Risk	Adversarial or non-adversarial risk is assessed, which falls within the agency’s risk tolerance thresholds. Assessed risk impact does not extend outside of the agency.
2	Agency High Risk	The adversarial or non-adversarial-related risk is associated with a critical supplier, critical system, or critical system component, and is assessed to have a high risk, per agency-established risk level assessment. Assessed risk impact does not extend outside of the agency.
3	Significant Risk	Adversarial-related significant risk assessed, with potential or known multi-agency/ mission(s) or Government-wide impact.
4	National Security Interest Risk	The adversarial-related significant risk with the potential to impact National Security Interest.
5	Urgent National Security Interest Risk	The adversarial-related significant risk with imminent or present impact to National Security Interest.

Agencies should also have, and follow, a defined assessment and risk scoring methodology. Documentation requirements should be incorporated into existing, relevant supply chain risk assessment policies, processes, and procedures. Risk characterized as level 3 and above is considered “substantial risk” per the FASC rule, thus requiring mandatory information sharing. For a risk determined to be at an SCRSS substantial level, it is necessary to escalate the risk assessment information to applicable senior-level officials within the agency, including legal counsel. Agencies may choose to voluntarily share supply chain information regarding identified risks with the FASC even if the risk level falls beneath the threshold of being considered substantial.

Recommended Minimum Standards for Vendor or Developer Verification of Software Under Executive Order (EO) 14028

There are techniques used within the software development industry that help verify the security of the tested software. The NIST SSDF standardizes these techniques as part of its answer to EO 14028. NIST’s recommended minimum standards for software verification should not be considered all-encompassing or even complete; however, the outlined techniques serve as broadly applicable guidelines illustrating the minimum requirements.

The recommended techniques primarily focus on testing, but several standards focus on higher-level planning. Performing early threat modeling helps identify design-level security issues and potentially-overlooked testing targets. The software needs should drive the particular threat modeling methods used, and it is essential to perform threat modeling multiple times during development to capture new threats as they emerge.

Automated testing is a vital part of effective testing according to multiple frameworks, including build requirements for SLSA. Implementing automated testing helps ensure tests run consistently, checks the results accurately, and helps ensure that weaknesses are captured reliably. As testing is automated, it can be repeated often; testing can be performed, for instance, upon every commit or before an issue is retired. It is recommended to perform automated testing for static and dynamic analysis.

Static analysis is helpful for both detecting vulnerabilities and ensuring code conforms to an organization’s coding standards. Static analysis can be performed by:

Using a code scanner to search for top bugs
Reviewing for hard-coded secrets
Linting code to ensure adherence to the organization’s coding paradigms

Dynamic analysis executes the software on many test cases and produces examinable outputs. Examples of dynamic analysis recommended by NIST include:

Running the program with built-in checks and protections
Creating “black box” test cases, or implementation agnostic functional tests
Creating code-based structural test cases
Using historical test cases designed to catch previous bugs
Running a fuzzer to produce enormous quantities of test cases
Running a web application scanner if the agency might connect the software to the internet

One of the main benefits of dynamic analysis is that it produces very few false positives.

Recursively checking dependencies such as libraries, packages, and services to assure equivocal security to the application is a major key to mitigating risk related to the software supply chain. Correcting the uncovered bugs and learning from the found vulnerabilities is important to improving the security of the software. Fixing the bugs allows the development team to improve the process to uncover found bugs sooner, and also makes it less likely for bugs to escape in the first place.

How Cycode can help

Ensuring the security of software is difficult and time-consuming without the proper tools. Cycode’s platform can support requirements of the NIST SSDF. Cycode can help improve the security of your software supply chain by providing complete visibility into enterprise DevOps tools and infrastructure. Cycode’s Infrastructure as Code capabilities include comprehensive security scanning and preventing escaped secrets, environmental drift, code leaks, and other common issues, all within flexible developer-friendly workflows. Once integrated into developer workflows, each commit and PR is scanned for issues, including hard-coded secrets or potential misconfiguration, directly helping organizations fulfill the recommendations provided by the NIST SSDF. Remediation is available both through a GUI and within the PR.

Cycode helps establish strong governance over every point of the SDLC by providing a cross-SCM inventory of all your organization’s users, contributors, teams, organizations, and repositories; this governance extends into providing more oversight into changes made to code as a means of further protecting key code. Required functionality of the NIST Cybersecurity Framework such as cybersecurity event and anomaly detection is made significantly easier through the use of tools such as Cycode’s custom policy builder. Cycode also helps you automatically audit access privileges to identify and reduce unused privileges and implement separation of duties; this helps mitigate the risk of code tampering and insider threat. Furthermore, Cycode helps ensure that strong authentication and secure development practices are in place. This platform helps apply security best practices for IaC code when using Terraform, Kubernetes, YAML, ARM, and CloudFormation.