ezesecops/rmf-ato-core huggingface dataset:
Secure Software Development Framework (SSDF) Version 1.1
3. Produce Well-Secured Software (PW): Organizations should produce well-secured

3. Produce Well-Secured Software (PW): Organizations should produce well-secured

software with minimal security vulnerabilities in its releases.
4. Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities
in their software releases and respond appropriately to address those vulnerabilities and
prevent similar ones from occurring in the future.
Secure Software Development Framework (SSDF) Version 1.1
Abstract

Abstract

Few software development life cycle (SDLC) models explicitly address software security in
detail, so secure software development practices usually need to be added to each SDLC model
to ensure that the software being developed is well-secured. This document recommends the
Secure Software Development Framework (SSDF) - a core set of high-level secure software
development practices that can be integrated into each SDLC implementation. Following such
practices should help software producers reduce the number of vulnerabilities in released
software, reduce the potential impact of the exploitation of undetected or unaddressed
vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences.
Because the framework provides a common vocabulary for secure software development,
software acquirers can also use it to foster communications with suppliers in acquisition
processes and other management activities.
Secure Software Development Framework (SSDF) Version 1.1
Acknowledgments

Trademark Information

All registered trademarks or trademarks belong to their respective organizations.

Acknowledgments

The authors thank all of the organizations and individuals who provided input for this update to
the SSDF. In response to Section 4 of Executive Order (EO) 14028 on "Improving the Nation's
Cybersecurity," NIST held a June 2021 workshop and received over 150 position papers, many
of which suggested secure software development practices, tasks, examples of implementations,
and references for consideration for this SSDF update. The authors appreciate all of those
suggestions, as well as the input from those who spoke at or attended the workshop and shared
their thoughts during or after the workshop.
Additionally, the authors appreciate the public comments submitted by dozens of organizations
and individuals and wish to acknowledge the particularly helpful feedback from Amazon Web
Services, Apiiro, Blackberry, BSA | The Software Alliance, the Enterprise Cloud Coalition, the
General Services Administration (GSA), Google, IBM, Medical Imaging & Technology Alliance
(MITA), Microsoft, Oracle, the Software Assurance Forum for Excellence in Code (SAFECode),
Synopsis, the U.S. Navy, Xoomworks, and Robert Grupe. Representatives of Siemens Energy
and Synopsis contributed mappings to new references.
The authors thank all of their NIST colleagues for their support throughout the SSDF update,
especially Curt Barker, Paul Black, Jon Boyens, Jim Foti, Barbara Guttman, Mat Heyman,
Nicole Keller, Matt Scholl, Adam Sedgewick, Kevin Stine, and Isabel Van Wyk.
The authors also wish to thank all of the individuals and organizations who provided comments
on drafts of the original version of the SSDF, including the Administrative Offices of the U.S.
Courts, The Aerospace Corporation, BSA | The Software Alliance, Capitis Solutions, the
Consortium for Information & Software Quality (CISQ), HackerOne, Honeycomb Secure
Systems, iNovex, Ishpi Information Technologies, the Information Security and Privacy
Advisory Board (ISPAB), Juniper Networks, Microsoft, MITA, Naval Sea Systems Command
(NAVSEA), NIST, Northrop Grumman, the Office of the Undersecretary of Defense for
Research and Engineering, Red Hat, SAFECode, and the Software Engineering Institute (SEI).
Secure Software Development Framework (SSDF) Version 1.1
Audience

Audience

There are two primary audiences for this document. The first is software producers (e.g.,
commercial-off-the-shelf [COTS] product vendors, government-off-the-shelf [GOTS] software
developers, custom software developers, internal development teams) regardless of size, sector,
or level of maturity. The second is software acquirers - both federal agencies and other
organizations. Readers of this document are not expected to be experts in secure software
development in order to understand it, but such expertise is required to implement its
recommended practices.
Personnel within the following Workforce Categories and Specialty Areas from the National
Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework [SP800181]
Secure Software Development Framework (SSDF) Version 1.1
Authority

Donna Dodson*

* Former NIST employee; all work for this publication was done while at NIST.

Gina M. Raimondo, Secretary

James K. Olthoff, Performing the Non-Exclusive Functions and Duties of the Under Secretary of Commerce

Authority

This publication has been developed by NIST in accordance with its statutory responsibilities under the
Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law
(P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including
minimum requirements for federal information systems, but such standards and guidelines shall not apply
to national security systems without the express approval of appropriate federal officials exercising policy
authority over such systems. This guideline is consistent with the requirements of the Office of Management
and Budget (OMB) Circular A-130.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and
binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these
guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other federal official. This publication may be used by nongovernmental
organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
however, be appreciated by NIST.
Secure Software Development Framework (SSDF) Version 1.1
Boyens J, Smith A, Bartol N, Winkler K, Holbrook A, Fallon M (2021)

Boyens J, Smith A, Bartol N, Winkler K, Holbrook A, Fallon M (2021)

Cybersecurity Supply Chain Risk Management Practices for Systems and
Gaithersburg, MD), Second Draft NIST Special Publication (SP) 800-161,
Secure Software Development Framework (SSDF) Version 1.1
CODEN: NSPUE2

Natl. Inst. Stand. Technol. Spec. Publ. 800-218, 36 pages (February 2022)

CODEN: NSPUE2

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.
There may be references in this publication to other publications currently under development by NIST in accordance
with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies,
may be used by federal agencies even before the completion of such companion publications. Thus, until each
publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For
planning and transition purposes, federal agencies may wish to closely follow the development of these new
publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide feedback to
NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at
https://csrc.nist.gov/publications.
Secure Software Development Framework (SSDF) Version 1.1
Executive Summary

Executive Summary

This document describes a set of fundamental, sound practices for secure software development
called the Secure Software Development Framework (SSDF). Organizations should integrate the
SSDF throughout their existing software development practices, express their secure software
development requirements to third-party suppliers using SSDF conventions, and acquire
software that meets the practices described in the SSDF. Using the SSDF helps organizations to
Secure Software Development Framework (SSDF) Version 1.1
explanation of what the practice is and why it is beneficial

Each practice definition includes the following elements:

• Practice: The name of the practice and a unique identifier, followed by a brief

explanation of what the practice is and why it is beneficial

• Tasks: One or more actions that may be needed to perform a practice
• Notional Implementation Examples: One or more notional examples of types of tools,
processes, or other methods that could be used to help implement a task. No examples or
combination of examples are required, and the stated examples are not the only feasible
options. Some examples may not be applicable to certain organizations and situations.
• References: Pointers to one or more established secure development practice documents
and their mappings to a particular task. Not all references will apply to all instances of
software development.
Table 1 defines the practices. They are only a subset of what an organization may need to do.
The information in the table is space constrained; much more information on each practice can
be found in the references. Note that the order of the practices, tasks, and notional
implementation examples in the table is not intended to imply the sequence of implementation or
the relative importance of any practice, task, or example.
The table uses terms like "sensitive data," "qualified person," and "well-secured," which are not
defined in this publication. Organizations adopting the SSDF should define these terms in the
context of their own environments and use cases. The same is true for the names of
environments, like "development," "build," "staging," "integration," "test," "production," and
"distribution," which vary widely among organizations and projects. Enumerating your
environments is necessary in order to secure them properly, and especially to prevent lateral
movement of attackers from environment to environment.
Secure Software Development Framework (SSDF) Version 1.1
Introduction

Table of Contents

Executive Summary ..................................................................................................... vi

Introduction

A software development life cycle (SDLC)1 is a formal or informal methodology for designing,
creating, and maintaining software (including code built into hardware). There are many models
for SDLCs, including waterfall, spiral, agile, and - in particular - agile combined with software
development and IT operations (DevOps) practices. Few SDLC models explicitly address
software security in detail, so secure software development practices usually need to be added to
and integrated into each SDLC model. Regardless of which SDLC model is used, secure
software development practices should be integrated throughout it for three reasons: to reduce
the number of vulnerabilities in released software, to reduce the potential impact of the
exploitation of undetected or unaddressed vulnerabilities, and to address the root causes of
vulnerabilities to prevent recurrences. Vulnerabilities include not just bugs caused by coding
flaws, but also weaknesses caused by security configuration settings, incorrect trust assumptions,
Secure Software Development Framework (SSDF) Version 1.1
Keywords

Keywords

secure software development; Secure Software Development Framework (SSDF); secure
software development practices; software acquisition; software development; software
development life cycle (SDLC); software security.
Secure Software Development Framework (SSDF) Version 1.1
Patent Disclosure Notice

Patent Disclosure Notice

NOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent claims
whose use may be required for compliance with the guidance or requirements of this publication
disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL
calls for patents and ITL has not undertaken a patent search in order to identify which, if any,
patents may apply to this publication.
As of the date of publication and following call(s) for the identification of patent claims whose use
may be required for compliance with the guidance or requirements of this publication, no such
patent claims have been identified to ITL.
No representation is made or implied by ITL that licenses are not required to avoid patent
infringement in the use of this publication.
Secure Software Development Framework (SSDF) Version 1.1
Section 4e of the EO to SSDF practices and tasks that can help address each subsection as part of > PS.2.1, PS.3.1, PS.3.2, PW.4.1, PW.4.4

Section 4e of the EO to SSDF practices and tasks that can help address each subsection as part of

a risk-based approach.

Table 2: SSDF Practices Corresponding to EO 14028 Subsections

PO.3.1, PO.3.2, PO.5.1, PO.5.2, PS.1.1, PS.2.1, PS.3.1, PW.4.1, PW.4.4

4e(iv)
PO.4.1, PO.4.2, PS.1.1, PW.2.1, PW.4.4, PW.5.1, PW.6.1, PW.6.2, PW.7.1, PW.7.2, PW.8.2,

PW.9.1, PW.9.2, RV.1.1, RV.1.2, RV.2.1, RV.2.2, RV.3.3

4e(v)
PO.3.2, PO.3.3, PO.4.1, PO.4.2, PO.5.1, PO.5.2, PW.1.2, PW.2.1, PW.7.2, PW.8.2, RV.2.2
4e(vi)

PO.1.3, PO.3.2, PO.5.1, PO.5.2, PS.3.1, PS.3.2, PW.4.1, PW.4.4, RV.1.1, RV.1.2

4e(vii)

RV.1.1, RV.1.2, RV.1.3, RV.2.1, RV.2.2, RV.3.3

4e(ix)
All practices and tasks consistent with a risk-based approach
4e(x)

PS.2.1, PS.3.1, PS.3.2, PW.4.1, PW.4.4

To coincide with the release of this document, NIST has also published guidance on how
software producers and acquirers can communicate with each other regarding attestation of
conformance with EO 14028 Section 4e.
Secure Software Development Framework (SSDF) Version 1.1
Reports on Computer Systems Technology

Submit comments on this publication to: ssdf@nist.gov

Attn: Computer Security Division, Information Technology Laboratory

100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

All comments are subject to release under the Freedom of Information Act (FOIA).

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and
Technology (NIST) promotes the U.S. economy and public welfare by providing technical
leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advance
the development and productive use of information technology. ITL's responsibilities include the
development of management, administrative, technical, and physical standards and guidelines for
the cost-effective security and privacy of other than national security-related information in
federal information systems. The Special Publication 800-series reports on ITL's research,
guidelines, and outreach efforts in information system security, and its collaborative activities
with industry, government, and academic organizations.
Secure Software Development Framework (SSDF) Version 1.1
Ross R, McEvilley M, Oren J (2016) Systems Security Engineering:

Ross R, McEvilley M, Oren J (2016) Systems Security Engineering:

Considerations for a Multidisciplinary Approach in the Engineering of
Trustworthy Secure Systems. (National Institute of Standards and
Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-160,
Volume 1. Includes updates as of March 21, 2018.
Secure Software Development Framework (SSDF) Version 1.1
Section 4 of the EO directed NIST to solicit input from the private sector, academia, government

Section 4 of the EO directed NIST to solicit input from the private sector, academia, government

agencies, and others and to identify existing or develop new standards, tools, best practices, and
other guidelines to enhance software supply chain security. Table 2 maps the subsections from
Secure Software Development Framework (SSDF) Version 1.1
The Secure Software Development Framework

The Secure Software Development Framework

This document defines version 1.1 of the Secure Software Development Framework (SSDF)
with fundamental, sound, and secure recommended practices based on established secure
software development practice documents. The practices are organized into four groups:
1. Prepare the Organization (PO): Organizations should ensure that their people,
processes, and technology are prepared to perform secure software development at the
organization level. Many organizations will find some PO practices to also be applicable
to subsets of their software development, like individual development groups or projects.
2. Protect the Software (PS): Organizations should protect all components of their
software from tampering and unauthorized access.
Secure Software Development Framework (SSDF) Version 1.1
The SSDF and Executive Order 14028

Rev. 1. https://doi.org/10.6028/NIST.SP.800-161r1-draft2

[SP800181]

Newhouse W, Keith S, Scribner B, Witte G (2017) National Initiative for
Cybersecurity Education (NICE) Cybersecurity Workforce Framework.

Special Publication (SP) 800-181. https://doi.org/10.6028/NIST.SP.800-

Schaffer K, Mell P, Trinh H (2021) Recommendations for Federal

Vulnerability Disclosure Guidelines. (National Institute of Standards and

Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) 800-

216. https://doi.org/10.6028/NIST.SP.800-216-draft

The SSDF and Executive Order 14028

The President's Executive Order (EO) on "Improving the Nation's Cybersecurity (14028)"
issued on May 12, 2021 [EO14028], charged multiple agencies - including NIST - with
enhancing cybersecurity through a variety of initiatives related to the security and integrity of the
software supply chain.
Secure Software Development Framework (SSDF) Version 1.1
Waltermire DA, Scarfone KA, Casipe M (2011) Specification for the Open

PCISSLC: 2.6, 4.2

SCFPSSD: Secure Development Lifecycle Feedback

[BSAFSS]

BSA (2020) The BSA Framework for Secure Software: A New Approach to

Securing the Software Lifecycle, Version 1.1. Available at

https://www.bsa.org/files/reports/bsa_framework_secure_software_update

Migues S, Erlikhman E, Ewers J, Nassery K (2021) BSIMM12 2021

https://www.bsimm.com/content/dam/bsimm/reports/bsimm12-

Cloud Native Computing Foundation (2021) Software Supply Chain Best

Practices. Available at https://github.com/cncf/tag-

security/tree/main/supply-chain-security/supply-chain-security-paper

Executive Order 14028 (2021) Improving the Nation's Cybersecurity. (The

White House, Washington, DC), DCPD-202100401, May 12, 2021.

https://www.govinfo.gov/app/details/DCPD-202100401

Hong Fong EK, Wheeler D, Henninger A (2016) State-of-the-Art

Resources (SOAR) for Software Vulnerability Detection, Test, and
Evaluation 2016. (Institute for Defense Analyses [IDA], Alexandria, VA),

IDA Paper P-8005. Available at https://www.ida.org/research-and-

publications/publications/all/s/st/stateoftheart-resources-soar-for-software-

vulnerability-detection-test-and-evaluation-2016

International Electrotechnical Commission (IEC), Security for industrial

automation and control systems - Part 4-1: Secure product development

lifecycle requirements, IEC 62443-4-1, 2018. Available at

https://webstore.iec.ch/publication/33615

Waltermire DA, Scarfone KA, Casipe M (2011) Specification for the Open

Checklist Interactive Language (OCIL) Version 2.0. (National Institute of
Standards and Technology, Gaithersburg, MD), NIST Interagency or
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > PO > PO.1 > PO.1.1

PO.1.1: Identify and document all security requirements for the organization's software development infrastructures and processes, and maintain the requirements over time. Example 1: Define policies for securing software development infrastructures and their components, including development endpoints, throughout the SDLC and maintaining that security. Example 2: Define policies for securing software development processes throughout the SDLC and maintaining that security, including for open-source and other third-party software components utilized by software being developed. Example 3: Review and update security requirements at least annually, or sooner if there are new requirements from internal or external sources, or a major security incident targeting software development infrastructure has occurred. Example 4: Educate affected individuals on impending changes to requirements. BSAFSS: SM.3, DE.1, IA.1, IA.2 BSIMM: CP1.1, CP1.3, SR1.1, SR2.2, SE1.2, SE2.6 EO14028: 4e(ix) IEC62443: SM-7, SM-9 NISTCSF: ID.GV-3 OWASPASVS: 1.1.1 OWASPMASVS: 1.10 OWASPSAMM: PC1-A, PC1-B, PC2-A PCISSLC: 2.1, 2.2 SCFPSSD: Planning the Implementation and Deployment of Secure Development Practices SP80053: SA-1, SA-8, SA-15, SR-3 SP800160: 3.1.2, 3.2.1, 3.2.2, 3.3.1, 3.4.2, 3.4.3 SP800161: SA-1, SA-8, SA-15, SR-3 SP800181: T0414; K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524; S0010, S0357, S0368; A0033, A0123, A0151
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > PO > PO.1 > PO.1.2

PO.1.2: Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time. Example 1: Define policies that specify risk-based software architecture and design requirements, such as making code modular to facilitate code reuse and updates; isolating security components from other components during execution; avoiding undocumented commands and settings; and providing features that will aid software acquirers with the secure deployment, operation, and maintenance of the software. Example 2: Define policies that specify the security requirements for the organization's software, and verify compliance at key points in the SDLC (e.g., classes of software flaws verified by gates, responses to vulnerabilities discovered in released software). Example 3: Analyze the risk of applicable technology stacks (e.g., languages, environments, deployment models), and recommend or require the use of stacks that will reduce risk compared to others. Example 4: Define policies that specify what needs to be archived for each software release (e.g., code, package files, third-party libraries, documentation, data inventory) and how long it needs to be retained based on the SDLC model, software end-of-life, and other factors. Example 5: Ensure that policies cover the entire software life cycle, including notifying users of the impending end of software support and the date of software end-of-life. Example 6: Review all security requirements at least annually, or sooner if there are new requirements from internal or external sources, a major vulnerability is discovered in released software, or a major security incident targeting organization-developed software has occurred. Example 7: Establish and follow processes for handling requirement exception requests, including periodic reviews of all approved exceptions. BSAFSS: SC.1-1, SC.2, PD.1-1, PD.1-2, PD.1-3, PD.2-2, SI, PA, CS, AA, LO, EE BSIMM: SM1.1, SM1.4, SM2.2, CP1.1, CP1.2, CP1.3, CP2.1, CP2.3, AM1.2, SFD1.1, SFD2.1, SFD3.2, SR1.1, SR1.3, SR2.2, SR3.3, SR3.4 EO14028: 4e(ix) IEC62443: SR-3, SR-4, SR-5, SD-4 ISO27034: 7.3.2 MSSDL: 2, 5 NISTCSF: ID.GV-3 OWASPMASVS: 1.12 OWASPSAMM: PC1-A, PC1-B, PC2-A, PC3-A, SR1-A, SR1-B, SR2-B, SA1-B, IR1-A PCISSLC: 2.1, 2.2, 2.3, 3.3 SCFPSSD: Establish Coding Standards and Conventions SP80053: SA-8, SA-8(3), SA-15, SR-3 SP800160: 3.1.2, 3.2.1, 3.3.1 SP800161: SA-8, SA-15, SR-3 SP800181: T0414; K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524; S0010, S0357, S0368; A0033, A0123, A0151