NIST CYBERSECURITY WHITE PAPER CSRC.NIST.

GOV

Mitigating the Risk of Software

Vulnerabilities by Adopting a Secure
Software Development Framework (SSDF)

Donna Dodson
Applied Cybersecurity Division
Information Technology Laboratory

Murugiah Souppaya
Computer Security Division
Information Technology Laboratory

Karen Scarfone
Scarfone Cybersecurity
Clifton, VA

April 23, 2020

This publication is available free of charge from:

https://doi.org/10.6028/NIST.CSWP.04232020
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

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
the software being developed is well secured. This white paper recommends a core set of high-
level secure software development practices called a secure software development framework
(SSDF) to be integrated within each SDLC implementation. The paper facilitates communications
about secure software development practices among business owners, software developers, project
managers and leads, and cybersecurity professionals within an organization. Following these
practices should help software producers reduce the number of vulnerabilities in released software,
mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and
address the root causes of vulnerabilities to prevent future recurrences. Also, because the
framework provides a common vocabulary for secure software development, software consumers
can use it to foster communications with suppliers in acquisition processes and other management
activities.

Keywords

secure software development; secure software development framework (SSDF); secure software
development practices; software acquisition; software development; software development life
cycle (SDLC); software security.

Disclaimer

Any mention of commercial products or reference to commercial organizations is for information

only; it does not imply recommendation or endorsement by NIST, nor does it imply that the
products mentioned are necessarily the best available for the purpose.

Additional Information

For additional information on NIST’s Cybersecurity programs, projects and publications, visit the
Computer Security Resource Center. Information on other efforts at NIST and in the Information
Technology Laboratory (ITL) is also available.

Comments on this publication may be submitted to:

National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Email: [email protected]

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

ii
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Acknowledgments

The authors wish to thank all of the individuals and organizations who provided comments on the
preliminary ideas and drafts, particularly BSA | The Software Alliance, the Information Security
and Privacy Advisory Board (ISPAB), and the members of the Software Assurance Forum for
Excellence in Code (SAFECode).

The authors also greatly appreciate the thoughtful public comments submitted by many
organizations and individuals, 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, Juniper Networks, Medical Imaging & Technology Alliance (MITA),
Microsoft, Naval Sea Systems Command (NAVSEA), the National Institute of Standards and
Technology (NIST), Northrop Grumman, Office of the Undersecretary of Defense for Research
and Engineering, RedHat, SAFECode, and the Software Engineering Institute (SEI).

Audience

There are two primary audiences for this white paper. The first is software producers (e.g.,
commercial-off-the-shelf [COTS] product vendors, government-off-the-shelf [GOTS] software
developers, custom software developers) regardless of size, sector, or level of maturity. The second
is software consumers, both federal government 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 [1] are most
likely to find this publication of interest:

• Securely Provision (SP): Risk Management (RSK), Software Development (DEV),

Systems Requirements Planning (SRP), Test and Evaluation (TST), Systems Development
(SYS)
• Operate and Maintain (OM): Systems Analysis (ANA)
• Oversee and Govern (OV): Training, Education, and Awareness (TEA); Cybersecurity
Management (MGT); Executive Cyber Leadership (EXL); Program/Project Management
(PMA) and Acquisition
• Protect and Defend (PR): Incident Response (CIR), Vulnerability Assessment and
Management (VAM)
• Analyze (AN): Threat Analysis (TWA), Exploitation Analysis (EXP)

Trademark Information

All registered trademarks or trademarks belong to their respective organizations.

iii
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

1 Introduction

A software development life cycle (SDLC) 1 is a formal or informal methodology for designing,
creating, and maintaining software (which includes code built into hardware). There are many
models for SDLCs, including waterfall, spiral, agile, and development and operations (DevOps).
Few SDLC models explicitly address software security in detail, so secure software development
practices usually need to be added to and integrated within each SDLC model. Regardless of which
SDLC model is used to develop software, secure software development practices should be
integrated throughout it for three reasons: to reduce the number of vulnerabilities in released
software, to mitigate the potential impact of the exploitation of undetected or unaddressed
vulnerabilities, and to address the root causes of vulnerabilities to prevent future recurrences. Most
aspects of security can be addressed at multiple places within an SDLC, but in general, the earlier
in the SDLC that security is addressed, the less effort and cost is ultimately required to achieve the
same level of security. This principle, also known as shifting left, is critically important regardless
of the SDLC model.

There are many existing documents on secure software development practices, including those
listed in the References section. This white paper does not introduce new practices or define new
terminology; instead, it describes a subset of high-level practices based on established standards,
guidance, and secure software development practice documents. These practices, collectively
called a secure software development framework (SSDF), should be particularly helpful for the
target audiences to achieve secure software development objectives. Note that these practices are
limited to those that bear directly on secure software development (e.g., securing the development
infrastructure or pipeline itself is out of scope).

This white paper is intended to be a starting point for discussing the concept of an SSDF and
therefore does not provide a comprehensive view of SSDFs. Future work may expand on the
material in this white paper, potentially covering topics such as how an SSDF may apply to and
vary for different software development methodologies and how an organization can transition
from using just their current software development practices to also incorporating the practices
specified by the SSDF. It is likely that future work will primarily take the form of use cases so that
the insights will be more readily applicable to certain types of development environments.

This white paper expresses secure software development practices but does not prescribe exactly
how to implement them. The focus is on implementing the practices rather than on the tools,
techniques, and mechanisms used to do so. For example, one organization might automate a
particular step, while another might use manual processes instead. Advantages of specifying the
practices at a high level include the following:

• Can be used by organizations in any sector or community, regardless of size or

cybersecurity sophistication
• Can be applied to software developed to support information technology (IT), industrial
control systems (ICS), cyber-physical systems (CPS), or the Internet of Things (IoT)

1 Note that SDLC is also widely used for “system development life cycle.” All usage of “SDLC” in this white paper is
referencing software, not systems.

1
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

• Can be integrated into any existing software development workflow and automated
toolchain; should not negatively affect organizations that already have robust secure
software development practices in place
• Makes the practices broadly applicable, not specific to particular technologies, platforms,
programming languages, SDLC models, development environments, operating
environments, tools, etc.
• Can help an organization document its secure software development practices today and
define its future target practices as part of its continuous improvement process
• Can assist an organization currently using a classic software development model in
transitioning its secure software development practices for use with a modern software
development model (e.g., agile, DevOps)
• Can assist organizations that are procuring and using software to understand secure
software development practices employed by their suppliers

This white paper also provides a common language to describe fundamental secure software
development practices. This is similar to the approach of the Framework for Improving Critical
Infrastructure Cybersecurity, also known as the NIST Cybersecurity Framework [2]. 2 Expertise
in secure software development is not required to understand the practices. This helps facilitate
communications about secure software practices among both internal and external organizational
stakeholders, such as the following:

• Business owners, software developers, project managers and leads, and cybersecurity
professionals within an organization
• Software consumers, including both federal government agencies and other organizations,
that want to define required or desired characteristics for software in their acquisition
processes in order to have higher-quality software (particularly with fewer security
vulnerabilities) 3
• Software producers (e.g., commercial-off-the-shelf [COTS] product vendors, government-
off-the-shelf [GOTS] software developers, software developers working within or on
behalf of software consumer organizations, software testers/quality assurance personnel)
that want to integrate secure software development practices throughout their SDLCs,
express their secure software practices to their customers, or define requirements for their
suppliers

This white paper’s practices are not based on the assumption that all organizations have the same
security objectives and priorities; rather, the recommendations reflect that each software producer
may have unique security assumptions, and each software consumer may have unique security
needs and requirements. While the desire is for each software producer to follow all applicable
practices, the expectation is that the degree to which each practice is implemented and the formality
of the implementation will vary based on the producer’s security assumptions. The practices

2 The SSDF practices may help support the NIST Cybersecurity Framework Functions, Categories, and Subcategories, but the
SSDF practices do not map to them and are typically the responsibility of different parties. Developers can adopt SSDF
practices, and the outcomes of their work could help organizations with their operational security in support of the
Cybersecurity Framework.
3 Future work may provide more practical guidance for software consumers on how they can leverage the SSDF in specific use
cases.

2
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

provide flexibility for implementers, but they are also clear to avoid leaving too much open to
interpretation.

3
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

2 Secure Software Development Framework (SSDF)

This white paper introduces a software development framework (SSDF) of fundamental, sound,
and secure software development practices based on established secure software development
practice documents. For the purposes of this white paper, the practices are organized into four
groups:

• 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 individual project.
• Protect the Software (PS): Protect all components of the software from tampering and
unauthorized access.
• Produce Well-Secured Software (PW): Produce well-secured software that has 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 practice is defined with the following elements:

• Practice: A brief statement of the practice, along with a unique identifier and an
explanation of what the practice is and why it is beneficial.
• Task: An individual action (or actions) needed to accomplish a practice.
• Implementation Example: An example of a type of tool, process, or other method that
could be used to implement this practice; not intended to imply that any example or
combination of examples is required or that only the stated examples are feasible options.
• Reference: An established secure development practice document and its mappings to a
particular task.

Although most practices are relevant for any software development effort, some practices are not
always applicable. For example, if developing a particular piece of software does not involve using
a compiler, there would be no need to follow a practice on configuring the compiler to improve
executable security. Some practices are more fundamental, while others are more advanced and
may depend on certain fundamental practices already being in place. Also, practices are not all
equally important in any particular case. Risk should be considered when deciding which practices
to use and how much time and resources to devote to each practice. 4 Finally, the frequency for
performing recurring practices is not specified because the frequency appropriate for any particular
situation depends on risk and other factors.

The table that defines the practices is below. Remember that these practices are only a subset of
what an organization may need to do, with the practices focused on helping organizations achieve
secure software development objectives. The practices are not listed sequentially or in order of

4 Organizations seeking guidance on how to get started with secure software development can consult many publicly available
references, such as “SDL That Won’t Break the Bank” by Steve Lipner from SAFECode (https://i.blackhat.com/us-18/Thu-
August-9/us-18-Lipner-SDL-For-The-Rest-Of-Us.pdf) and “Simplified Implementation of the Microsoft SDL” by Microsoft
(https://www.microsoft.com/en-us/download/details.aspx?id=12379).

4
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

importance. The information in the table is space constrained, and much more information on each
practice can be found in the references (with the bolded text on each line being the identifier used
for that reference in the table):

• BSIMM10: Building Security in Maturity Model (BSIMM) Version 10 [3]

• BSA: BSA, Framework for Secure Software [4]
• IDASOAR: Institute for Defense Analyses (IDA), State-of-the-Art Resources (SOAR) for
Software Vulnerability Detection, Test, and Evaluation 2016 [5]
• ISO27034: International Organization for Standardization/International Electrotechnical
Commission (ISO/IEC), Information technology – Security techniques – Application
security – Part 1: Overview and concepts, ISO/IEC 27034-1:2011 [6]
• MSSDL: Microsoft, Security Development Lifecycle [7]
• NISTCSF: NIST, Framework for Improving Critical Infrastructure Cybersecurity,
Version 1.1 [2]
• OWASPASVS: OWASP, OWASP Application Security Verification Standard 4.0 [8]
• OWASPTEST: OWASP, OWASP Testing Guide 4.0 [9]
• PCISSLRAP: Payment Card Industry (PCI) Security Standards Council, Secure Software
Lifecycle (Secure SLC) Requirements and Assessment Procedures Version 1.0 [10]
• SAMM15: OWASP, Software Assurance Maturity Model Version 1.5 [11]
• SCAGILE: Software Assurance Forum for Excellence in Code (SAFECode), Practical
Security Stories and Security Tasks for Agile Development Environments [12]
• SCFPSSD: SAFECode, Fundamental Practices for Secure Software Development:
Essential Elements of a Secure Development Lifecycle Program, Third Edition [13]
• SCSIC: SAFECode, Software Integrity Controls: An Assurance-Based Approach to
Minimizing Risks in the Software Supply Chain [14]
• SCTPC: SAFECode, Managing Security Risks Inherent in the Use of Third-Party
Components [15]
• SCTTM: SAFECode, Tactical Threat Modeling [16]
• SP80053: Joint Task Force Transformation Initiative, Security and Privacy Controls for
Federal Information Systems and Organizations, NIST Special Publication (SP) 800-53
Revision 4 [17]
• SP800160: NIST, Systems Security Engineering: Considerations for a Multidisciplinary
Approach in the Engineering of Trustworthy Secure Systems, NIST SP 800-160 Volume 1
[18]
• SP800181: NIST, National Initiative for Cybersecurity Education (NICE) Cybersecurity
Workforce Framework, NIST SP 800-181 [1]

5
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Prepare the Organization (PO)
Define Security Requirements PO.1.1: Identify all applicable • Define policies that specify the security BSIMM10: CP1.1, CP1.3, SR1.1
for Software Development security requirements for the requirements for the organization’s BSA: SC.1-1, SC.2, PD.1-1, PD.1-2,
(PO.1): Ensure that security organization’s general software software to meet, including secure PD.1-3, PD.2-2
requirements for software development, and maintain the coding practices for developers to follow.
requirements over time. ISO27034: 7.3.2
development are known at all • Define policies that specify software MSSDL: Practice 2
times so that they can be taken architecture requirements, such as
into account throughout the NISTCSF: ID.GV-3
making code modular to facilitate code
SDLC and duplication of effort reuse and easier updates as well as OWASPTEST: Phase 2.1
can be minimized because the isolating security functionality from other PCISSLRAP: 2.1
requirements information can be functionality during code execution. SAMM15: PC1-A, PC1-B, PC2-A, SR1-
collected once and shared. This A, SR1-B, SR2-B
• Define policies for securing the
includes requirements from
development infrastructure, such as SCFPSSD: Planning the Implementation
internal sources (e.g., the
developer workstations and code and Deployment of Secure Development
organization’s policies, business
repositories. Practices; Establish Coding Standards
objectives, and risk
• Ensure that policies cover the entire and Conventions
management strategy) and
external sources (e.g., software life cycle, including notifying SP80053: SA-15
applicable laws and regulations). users of the impending end of software SP800160: 3.1.2, 3.3.1, 3.4.2, 3.4.3
support and the date of software end-of- SP800181: T0414; K0003, K0039,
life. K0044, K0157, K0168, K0177, K0211,
• Use a well-known set of security K0260, K0261, K0262, K0524; S0010,
requirements as a structure or lexicon for S0357, S0368; A0033, A0123, A0151
defining the organization’s requirements.
This set can be mapped to other third-
party security requirements to which the
organization is also subject.
• Review and update the requirements
after each response to a vulnerability
incident.
• Conduct a periodic (typically at least
annual) review of all security
requirements.
• Promptly review new external
requirements and updates to existing
external requirements.
• Educate affected individuals on the
impending changes in requirements.

6
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Implement Roles and PO.2.1: Create new roles and • Define SSDF-related roles and BSA: PD.2-1, PD.2-2
Responsibilities (PO.2): alter responsibilities for existing responsibilities for all members of the BSIMM10: CP3.2, SM1.1
Ensure that everyone inside and roles to encompass all parts of software development team. NISTCSF: ID.AM-6, ID.GV-2
outside of the organization the SSDF. Periodically review • Integrate the security roles into the
the defined roles and PCISSLRAP: 1.2
involved in the SDLC is software development team.
prepared to perform their SSDF- responsibilities, and update SCSIC: Vendor Software Development
• Define roles and responsibilities for Integrity Controls
related roles and responsibilities them as needed.
cybersecurity staff, security champions, SP80053: SA-3
throughout the SDLC.
project managers and leads, senior
management, software developers, SP800160: 3.2.1, 3.2.4, 3.3.1
software testers/quality assurance SP800181: K0233
personnel, product owners, and others
involved in the SDLC.
• Conduct an annual review of all roles
and responsibilities.
• Educate affected individuals on the
impending changes in roles and
responsibilities.
PO.2.2: Provide role-specific • Document the desired outcomes of BSA: PD.2-2
training for all personnel with training for each role. BSIMM10: CP2.5, SM1.3, T1.1, T1.5,
responsibilities that contribute to • Create a training plan for each role. T1.7, T2.6, T2.8, T3.2, T3.4
secure development. MSSDL: Practice 1
• Acquire or create training for each role;
Periodically review role-specific
acquired training may need NISTCSF: PR.AT-*
training and update it as
customization for the organization. PCISSLRAP: 1.3
needed.
SAMM15: EG1-A, EG2-A
SCAGILE: Operational Security Tasks
14, 15; Tasks Requiring the Help of
Security Experts 1
SCFPSSD: Planning the Implementation
and Deployment of Secure Development
Practices
SCSIC: Vendor Software Development
Integrity Controls
SP80053: SA-8
SP800160: 3.2.4
SP800181: OV-TEA-001, OV-TEA-002;
T0030, T0073, T0320; K0204, K0208,
K0220, K0226, K0243, K0245, K0252;
S0100, S0101; A0004, A0057

7
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

PO.2.3: Obtain upper • Increase awareness by upper BSIMM10: SM1.2, SM1.3
management commitment to management. PCISSLRAP: 1.1
secure development, and • Assist upper management in SAMM15: SM1.A
convey that commitment to all incorporating secure development
with SSDF-related roles and SP 800-181: T0001, T0004
support into their communications with
responsibilities. personnel with SSDF-related roles and
responsibilities.
• Educate all personnel with SSDF-related
roles and responsibilities on upper
management’s commitment to the SSDF
and the importance of the SSDF to the
organization.
Implement a Supporting PO.3.1: Specify which tools or • Define categories of toolchains, and BSA: TC.1, TC.1-1, TC.1-2
Toolchain (PO.3): Use tool types are to be included in specify the mandatory tools or tool types MSSDL: Practice 8
automation to reduce the human each toolchain and which are to be used for each category. SCAGILE: Tasks Requiring the Help of
effort needed and improve the mandatory, as well as how the • Identify security tools to integrate into the Security Experts 9
accuracy, consistency, and toolchain components are to be developer toolchain.
integrated with each other. SP80053: SA-15
comprehensiveness of security
• Use automated technology for toolchain SP800181: K0013, K0178
practices throughout the SDLC,
management and orchestration.
as well as provide a way to
document and demonstrate use PO.3.2: Following sound • Evaluate, select, and acquire tools, and BSA: TC.1-1, TC.1-6
of these practices. Toolchains security practices, deploy and assess the security of each tool. SCAGILE: Tasks Requiring the Help of
and tools may be used at configure tools, integrate them • Integrate tools with other tools and with Security Experts 9
different levels of the within the toolchain, and existing software development SP80053: SA-15
organization, such as maintain the individual tools and processes and workflows.
the toolchain as a whole. SP800181: K0013, K0178
organization-wide or project-
• Update, upgrade, and replace existing
specific.
tools.
• Monitor tools and tool logs for potential
operational and security issues.
PO.3.3: Configure tools to • Use the organization’s existing workflow BSA: PD.1.6
collect evidence and artifacts of or issue tracking systems to create an MSSDL: Practice 8
their support of the secure audit trail of the secure development- PCISSLRAP: 2.5
software development practices. related actions that are performed.
SCAGILE: Tasks Requiring the Help of
• Determine how often the collected Security Experts 9
information should be audited, and
SP80053: SA-15
implement processes to perform the
auditing. SP800181: K0013

8
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Define Criteria for Software PO.4.1: Define criteria for • Ensure that the criteria adequately BSA: TV.2-1, TV.5-1
Security Checks (PO.4): Help software security checks indicate how effectively security risk is BSIMM10: SM1.4, SM2.2
ensure that the software throughout the SDLC. being managed. ISO27034: 7.3.5
resulting from the SDLC meets • Define key performance indicators MSSDL: Practice 3
the organization’s expectations (KPIs) for software security.
by defining criteria for checking OWASPTEST: Phase 1.3
• Add software security criteria to existing SAMM15: DR3-B, IR3-B, PC3-A, ST3-B
the software’s security during
checks (e.g., the Definition of Done in
development. SP80053: SA-15
agile SDLC methodologies).
SP800160: 3.2.1, 3.2.5, 3.3.1
• Review the artifacts generated as part of
the software development workflow SP800181: K0153, K0165
system to determine if they meet the
criteria purposes.
• Record security check approvals,
rejections, and requests for exception as
part of the workflow and tracking system.
PO.4.2: Implement processes, • Use the toolchain to automatically gather BSA: PD.1-6
mechanisms, etc. to gather the information that informs security BSIMM10: SM1.4, SM2.2
necessary information in support decision-making. SP80053: SA-15
of the criteria. • Deploy additional tools if needed to SP800160: 3.3.7
support the generation and collection of
SP800181: T0349; K0153
information supporting the criteria.
• Automate decision-making processes
utilizing the criteria.

9
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Protect Software (PS)

Protect All Forms of Code PS.1.1: Store all forms of code, • Store all source code in a code BSA: IA.1, IA.2-2, SM.4-1
from Unauthorized Access including source code and repository, and restrict access to it based IDASOAR: Fact Sheet 25
and Tampering (PS.1): Help executable code, based on the on the nature of the code. For example, NISTCSF: PR.AC-4
prevent unauthorized changes principle of least privilege so that some code may be intended for public
to code, both inadvertent and only authorized personnel have OWASPASVS: 1.10, 10.3.2, 14.2
access, in which case its integrity and
intentional, which could the necessary forms of access. availability should be protected; other PCISSLRAP: 6.1
circumvent or negate the code may also need its confidentiality SCSIC: Vendor Software Delivery
intended security characteristics protected. Integrity Controls, Vendor Software
of the software. For code that is • Use version control features of the Development Integrity Controls
not intended to be publicly repository to track all changes made to
accessible, it helps prevent theft the code with accountability to the
of the software and may make it individual developer account.
more difficult or time-consuming
• Review and approve all changes made
for attackers to find
to the code.
vulnerabilities in the software.
• Use code signing to help protect the
integrity and provenance of executables.
• Use cryptography (e.g., cryptographic
hashes) to help protect the integrity of
files.
• Create and maintain a software bill of
materials (SBOM) for each software
package created.
Provide a Mechanism for PS.2.1: Make verification • Post cryptographic hashes for release BSA: SM.4.2, SM.4.3, SM.5.1, SM.6.1
Verifying Software Release information available to software files on a well-secured website. BSIMM10: SE2.4
Integrity (PS.2): Help software consumers. • Use an established certificate authority NISTCSF: PR.DS-6
consumers ensure that the for code signing so consumers can
software they acquire is PCISSLRAP: 6.2
confirm the validity of signatures.
legitimate and has not been SAMM15: OE3-B
• Periodically review the code signing SCSIC: Vendor Software Delivery
tampered with.
processes, including certificate renewal Integrity Controls
and protection.
SP800181: K0178
Archive and Protect Each PS.3.1: Securely archive a copy • Store all release files in a repository, and BSA: PD.1-6
Software Release (PS.3): Help of each release and all of its restrict access to them. IDASOAR: Fact Sheet 25
identify, analyze, and eliminate components (e.g., code, NISTCSF: PR.IP-4
vulnerabilities discovered in the package files, third-party
software after release. libraries, documentation), and PCISSLRAP: 5.2, 6.2
release integrity verification SCSIC: Vendor Software Delivery
information. Integrity Controls
SP80053: SA-15

10
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Produce Well-Secured Software (PW)

Design Software to Meet PW.1.1: Use forms of risk • Train the development team (the security BSA: SC.1-3, SC.1-4
Security Requirements and modeling, such as threat champions in particular) or collaborate BSIMM10: AM1.3, AM1.5, AM2.1,
Mitigate Security Risks modeling, attack modeling, or with a threat modeling expert to create AM2.2, AM2.5, AM2.6, AM2.7
(PW.1): Identify and evaluate attack surface mapping, to help threat models and attack models and to IDASOAR: Fact Sheet 1
the applicable security assess the security risk for the analyze how to use a risk-based
requirements for the software’s software. ISO27034: 7.3.3
approach to address the risks and
design; determine what security implement mitigations. MSSDL: Practice 4
risks the software is likely to • Perform more rigorous assessments for NISTCSF: ID.RA-*
face during production operation high-risk areas, such as protecting OWASPASVS: 1.1.2, 1.2, 1.4, 1.6, 1.8,
and how those risks should be sensitive data and safeguarding 1.9, 1.11, 2, 3, 4, 6, 8, 9, 11, 12, 13
mitigated by the software’s identification, authentication, and access OWASPTEST: Phase 2.4
design; and justify any cases control, including credential PCISSLRAP: 3.2
where risk-based decisions management.
conclude that security SAMM15: DR1-A, TA1-A, TA1-B, TA3-B
• Review vulnerability reports and SCAGILE: Tasks Requiring the Help of
requirements should be relaxed
or waived. Addressing security statistics for previous software. Security Experts 3
requirements and risks during SCFPSSD: Threat Modeling
software design (secure by SCTTM: Entire guide
design) helps to make software
SP80053: SA-8, SA-15, SA-17
development more efficient.
SP800160: 3.3.4, 3.4.5
SP800181: T0038, T0062, T0236;
K0005, K0009, K0038, K0039, K0070,
K0080, K0119, K0147, K0149, K0151,
K0152, K0160, K0161, K0162, K0165,
K0297, K0310, K0344, K0362, K0487,
K0624; S0006, S0009, S0022, S0078,
S0171, S0229, S0248; A0092, A0093,
A107

11
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Review the Software Design PW.2.1: Have a qualified person • Review the software design to confirm BSA: TV.3, TV.3-1, TV.5
to Verify Compliance with who was not involved with the that it addresses all of the security BSIMM10: AA1.2, AA2.1
Security Requirements and software design review it to requirements. ISO27034: 7.3.3
Risk Information (PW.2): Help confirm that it meets all of the • Review the risk models created during
ensure that the software will security requirements and OWASPTEST: Phase 2.2
software design to determine if they
meet the security requirements satisfactorily addresses the SAMM15: DR1-A, DR1-B
appear to adequately identify the risks.
and satisfactorily address the identified risk information. SP800181: T0328; K0038, K0039,
• Review the software design to confirm K0070, K0080, K0119, K0152, K0153,
identified risk information.
that it satisfactorily addresses the risks K0161, K0165, K0172, K0297; S0006,
identified by the risk models. S0009, S0022, S0036, S0141, S0171
• Have the software’s designer correct
failures to meet the requirements.
• Change the design and/or the risk
response strategy if the security
requirements cannot be met.
Verify Third-Party Software PW.3.1: Communicate • Define a core set of security BSA: SM.1, SM.2, SM.2-1, SM.2.4
Complies with Security requirements to third parties requirements, and include them in BSIMM10: CP2.4, SR2.5, SR3.2
Requirements (PW.3): Reduce who may provide software acquisition documents, software IDASOAR: Fact Sheets 19, 21
the risk associated with using modules and services to the contracts, and other agreements with
acquired software modules and organization for reuse by the MSSDL: Practice 7
third parties.
services, which are potential organization’s own software. SAMM15: SR3-A
• Define the security-related criteria for
sources of additional selecting commercial and open-source SCFPSSD: Manage Security Risk
vulnerabilities. software. Inherent in the Use of Third-Party
Components
• Require the providers of commercial
software modules and services to SCSIC: Vendor Sourcing Integrity
provide evidence that their software Controls
complies with the organization’s security SP80053: SA-4, SA-12
requirements. SP800160: 3.1.1, 3.1.2
• Establish and follow procedures to SP800181: T0203, T0415; K0039;
address risk when there are security S0374; A0056, A0161
requirements that third-party software
modules and services do not meet.

12
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

PW.3.2: Use appropriate means • See if there are publicly known BSA: SC.3-1, TV.2
to verify that commercial, open vulnerabilities in the software modules IDASOAR: Fact Sheet 21
source, and all other third-party and services that the vendor has not yet MSSDL: Practice 7
software modules and services fixed.
comply with the requirements. OWASPASVS: 10, 14.2
• Ensure each software module or service
PCISSLRAP: 4.1
is still actively maintained, which should
include new vulnerabilities found in the SCAGILE: Tasks Requiring the Help of
software being remediated. Security Experts 8
• Determine a plan of action for each third- SCFPSSD: Manage Security Risk
party software module or service that is Inherent in the Use of Third-Party
no longer being maintained or available Components
in the future. SCSIC: Vendor Sourcing Integrity
Controls
• Use the results of commercial services
for vetting the software modules and SCTPC: 3.2.2
services. SP80053: SA-12
• [See Review and/or Analyze Human- SP800160: 3.1.2, 3.3.8
Readable Code to Identify SP800181: SP-DEV-002; K0153, K0266
Vulnerabilities and Verify Compliance [See Review and/or Analyze Human-
with Security Requirements (PW.7)] Readable Code to Identify
• [See Test Executable Code to Identify Vulnerabilities and Verify Compliance
Vulnerabilities and Verify Compliance with Security Requirements (PW.7)]
with Security Requirements (PW.8)] [See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
Reuse Existing, Well-Secured PW.4.1: Acquire well-secured • Review and evaluate third-party software BSA: SM.2, SM.2.1
Software When Feasible components (e.g., software components in the context of their IDASOAR: Fact Sheet 19
Instead of Duplicating libraries, modules, middleware, expected use. If a component is to be MSSDL: Practice 6
Functionality (PW.4): Lower frameworks) from third parties used in a substantially different way in
the costs of software for use by the organization’s SAMM15: SA1-A
the future, perform the review and
development, expedite software software. evaluation again with that new context in SCTPC: 3.2.1
development, and decrease the mind. SP80053: SA-12
likelihood of introducing • Establish an organization-wide software SP800181: K0039
additional security vulnerabilities repository to host sanctioned and vetted
into the software. These are open-source components.
particularly true for software that
• Maintain a list of organization-approved
implements security
commercial software components and
functionality, such as
component versions.
cryptographic modules and
protocols. • Designate which components must be
included by software to be developed.

13
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

PW.4.2: Create well-secured • Follow the organization-established BSIMM10: SFD1.1, SFD2.1
software components in-house security practices for secure software IDASOAR: Fact Sheet 19
following SDLC processes to development. OWASPASVS: 10
meet common internal software • Maintain an organization-wide software
development needs that cannot SP800181: SP-DEV-001
repository for these components.
be better met by third-party
• Designate which components must be
software.
included by software to be developed.
PW.4.3: Where appropriate, • Maintain an organization-wide software BSA: SI.2, EN.1-1, LO.1
build in support for using repository of modules for supporting MSSDL: Practice 5
standardized security features standardized security features and OWASPASVS: 1.1.6
and services (e.g., integrating services.
with log management, identity SCFPSSD: Establish Log Requirements
• Designate which security features and and Audit Practices
management, access control, services must be supported by software
and vulnerability management to be developed.
systems) instead of creating
proprietary implementations of
security features and services.
Create Source Code Adhering PW.5.1: Follow all secure • Validate all inputs, and validate and BSA: SC.2, SC.4, SC.3, SC.3-2, EE.1,
to Secure Coding Practices coding practices that are properly encode all output. EE.1.2, EE.2, LO.1,
(PW.5): Decrease the number of appropriate to the development • Avoid using unsafe functions and calls. IDASOAR: Fact Sheet 2
security vulnerabilities in the languages and environment. ISO27034: 7.3.5
software, and reduce costs by • Handle errors gracefully.
eliminating vulnerabilities during • Provide logging and tracing capabilities. MSSDL: Practice 9
source code creation. • Use development environments with OWASPASVS: 1.5, 1.7, 5, 7,
features that encourage or require the SCFPSSD: Establish Log Requirements
use of secure coding practices. and Audit Practices, Handle Data Safely,
• Follow procedures for manually ensuring Handle Errors, Use Safe Functions Only
compliance with secure coding practices. SP800181: SP-DEV-001; T0013, T0077,
• Check for other vulnerabilities that are T0176; K0009, K0016, K0039, K0070,
common to the development languages K0140, K0624; S0019, S0060, S0149,
and environment. S0172, S0266; A0036, A0047

PW.5.2: Have the developer • [See Review and/or Analyze Human- [See Review and/or Analyze Human-
review their own human- Readable Code to Identify Readable Code to Identify
readable code, analyze their Vulnerabilities and Verify Compliance Vulnerabilities and Verify Compliance
own human-readable code, with Security Requirements (PW.7)] with Security Requirements (PW.7)]
and/or test their own executable • [See Test Executable Code to Identify [See Test Executable Code to Identify
code to complement (not Vulnerabilities and Verify Compliance Vulnerabilities and Verify Compliance
replace) code review, analysis, with Security Requirements (PW.8)] with Security Requirements (PW.8)]
and/or testing performed by
others.

14
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Configure the Compilation PW.6.1: Use compiler and build • Use up-to-date versions of compiler and BSA: TC.1-1, TC.1-3, TC.1-4, TC.1-5
and Build Processes to tools that offer features to build tools. MSSDL: Practice 8
Improve Executable Security improve executable security.
• Validate the authenticity and integrity of SCAGILE: Operational Security Task 3
(PW.6): Decrease the number of compiler and build tools.
security vulnerabilities in the SCFPSSD: Use Current Compiler and
software, and reduce costs by Toolchain Versions and Secure Compiler
eliminating vulnerabilities before Options
testing occurs. SCSIC: Vendor Software Development
Integrity Controls

PW.6.2: Determine which • Enable compiler features that produce BSA: TC.1, TC.1-3, TC.1-4, TC.1-5
compiler and build tool features warnings for poorly secured code during OWASPASVS: 1.14.3, 1.14.4, 14.1
should be used and how each the compilation process. SCAGILE: Operational Security Task 8
should be configured, then • Implement the “clean build” concept,
implement the approved SCFPSSD: Use Current Compiler and
where all compiler warnings are treated Toolchain Versions and Secure Compiler
configuration for compilation and as errors and eliminated.
build tools, processes, etc. Options
• Enable compiler features that randomize SCSIC: Vendor Software Development
characteristics, such as memory location Integrity Controls
usage, that would otherwise be easily SP800181: K0039, K0070
predictable and thus exploitable.
• Conduct testing to ensure that the
features are working as expected and
not inadvertently causing any operational
issues or other problems.
• Verify that the approved configuration is
enabled for compilation and build tools,
processes, etc.
• Document information about the
compilation and build tool configuration
in a knowledge base that developers can
access and search.

15
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Review and/or Analyze PW.7.1: Determine whether • Follow the organization’s policies or SCSIC: Peer Reviews and Security
Human-Readable Code to code review (i.e., a person guidelines for when code review should Testing
Identify Vulnerabilities and directly looks at the code to find be performed and how it should be SP80053: SA-11
Verify Compliance with issues) and/or code analysis conducted. This includes third-party SP800181: SP-DEV-002; K0013, K0039,
Security Requirements (i.e., tools are used to find code and reusable code modules written K0070, K0153, K0165; S0174
(PW.7): Help identify issues in code, either in a fully in-house.
vulnerabilities so they can be automated way or in conjunction • Follow the organization’s policies or
corrected before the software is with a person) should be used. guidelines for when code analysis should
released to prevent exploitation. be performed and how it should be
Using automated methods conducted.
lowers the effort and resources
needed to detect vulnerabilities. PW.7.2: Perform the code • Perform peer review of code, and review BSA: PD.1-5, TV.2, TV.3
Human-readable code includes review and/or code analysis any existing code review, analysis, or BSIMM10: CR1.2, CR1.4, CR1.6,
source code and any other form based on the organization’s testing results as part of the peer review. CR2.6, CR2.7
of code an organization deems secure coding standards, and • Use peer reviews to check code for IDASOAR: Fact Sheets 3, 4, 5, 14, 15,
as human readable. document and triage all backdoors and other malicious content. 48
discovered issues and
• Use peer reviewing tools that facilitate ISO27034: 7.3.6
recommended remediations in
the peer review process, and document MSSDL: Practices 9, 10
the development team’s
workflow or issue tracking all discussions and other feedback. OWASPASVS: 1.1.7, 10
system. • Use a static analysis tool to OWASPTEST: Phase 3.2, Phase 4.1
automatically check code for
PCISSLRAP: 4.1
vulnerabilities and for compliance with
the organization’s secure coding SAMM15: IR1-B, IR2-A, IR2-B
standards, with a human reviewing SCAGILE: Operational Security Tasks 4,
issues reported by the tool and 7
remediating them as necessary. SCFPSSD: Use Code Analysis Tools to
• Use review checklists to verify that the Find Security Issues Early, Use Static
code complies with the requirements. Analysis Security Testing Tools, Perform
• Use automated tools to identify and Manual Verification of Security
remediate documented and verified Features/Mitigations
unsafe software practices on a SCSIC: Peer Reviews and Security
continuous basis as human-readable Testing
code is checked into the code repository. SP80053: SA-11, SA-15
• Identify and document the root cause of SP800181: SP-DEV-001, SP-DEV-002;
each discovered issue. T0013, T0111, T0176, T0267, T0516;
• Document lessons learned from code K0009, K0039, K0070, K0140, K0624;
review and analysis in a knowledge base S0019, S0060, S0078, S0137, S0149,
that developers can access and search. S0167, S0174, S0242, S0266; A0007,
A0015, A0036, A0044, A0047

16
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Test Executable Code to PW.8.1: Determine if executable • Follow the organization’s policies or BSA: TV.3
Identify Vulnerabilities and code testing should be guidelines for when code testing should SCSIC: Peer Reviews and Security
Verify Compliance with performed and, if so, which be performed and how it should be Testing
Security Requirements types should be used. conducted. This includes third-party SP80053: SA-11
(PW.8): Help identify executable code and reusable
vulnerabilities so they can be SP800181: SP-DEV-001, SP-DEV-002;
executable code modules written in-
corrected before the software is T0456; K0013, K0039, K0070, K0153,
house.
released in order to prevent K0165, K0342, K0367, K0536, K0624;
exploitation. Using automated S0001, S0015, S0026, S0061, S0083,
methods lowers the effort and S0112, S0135
resources needed to detect PW.8.2: Design the tests, • Perform robust functional testing of BSA: PD.1-5, TV.3, TV.5, TV.5-2
vulnerabilities. Executable code perform the testing, and security features. BSIMM10: PT1.1, PT1.2, PT1.3, ST1.1,
includes binaries, directly document the results. • Integrate dynamic vulnerability testing ST1.3, ST2.1, ST2.4, ST2.5, ST2.6,
executed bytecode, directly into the project’s automated test suite. ST3.3, ST3.4
executed source code, and any IDASOAR: Fact Sheets 7, 8, 10, 11, 38,
other form of code an • Incorporate tests for previously reported
vulnerabilities into the project’s 39, 43, 44, 48, 55, 56, 57
organization deems as
executable. automated test suite to ensure that ISO27034: 7.3.6
errors are not reintroduced. MSSDL: Practice 11
• Use automated fuzz testing tools to find PCISSLRAP: 4.1
issues with input handling. SAMM15: ST1-B, ST2-A, ST2-B
• If resources are available, use SCAGILE: Operational Security Tasks
penetration testing to simulate how an 10, 11; Tasks Requiring the Help of
attacker might attempt to compromise Security Experts 4, 6, 7
the software in high-risk scenarios.
SCFPSSD: Perform Dynamic Analysis
• Identify and document the root cause of Security Testing, Fuzz Parsers, Network
each discovered issue. Vulnerability Scanning, Perform
• Document lessons learned from code Automated Functional Testing of
testing in a knowledge base that Security Features/Mitigations, Perform
developers can access and search. Penetration Testing
SCSIC: Peer Reviews and Security
Testing
SP80053: SA-11, SA-15
SP800181: SP-DEV-001, SP-DEV-002;
T0013, T0028, T0169, T0176, T0253,
T0266, T0456, T0516; K0009, K0039,
K0070, K0272, K0339, K0342, K0362,
K0536, K0624; S0001, S0015, S0046,
S0051, S0078, S0081, S0083, S0135,
S0137, S0167, S0242; A0015

17
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Configure the Software to PW.9.1: Determine how to • Conduct testing to ensure that the BSA: CF.1, TC.1
Have Secure Settings by configure each setting that has settings, including the default settings, IDASOAR: Fact Sheet 23
Default (PW.9): Help improve an effect on security so that the are working as expected and are not ISO27034: 7.3.5
the security of the software at default settings are secure and inadvertently causing any security
the time of installation to reduce do not weaken the security OWASPTEST: Phase 4.2
weaknesses, operational issues, or other
the likelihood of the software functions provided by the problems. SCAGILE: Tasks Requiring the Help of
being deployed with weak platform, network infrastructure, Security Experts 12
security settings that would put it or services. SCSIC: Vendor Software Delivery
at greater risk of compromise. Integrity Controls, Vendor Software
Development Integrity Controls
SP800181: SP-DEV-002; K0009, K0039,
K0073, K0153, K0165, K0275, K0531;
S0167
PW.9.2: Implement the default • Verify that the approved configuration is IDASOAR: Fact Sheet 23
settings (or groups of default in place for the software. OWASPTEST: Phase 4.2
settings, if applicable), and • Document each setting’s purpose, PCISSLRAP: 8.1, 8.2
document each setting for options, default value, security
software administrators. SCAGILE: Tasks Requiring the Help of
relevance, potential operational impact, Security Experts 12
and relationships with other settings.
SCFPSSD: Verify Secure Configurations
• Document how each setting can be and Use of Platform Mitigation
implemented by software administrators. SCSIC: Vendor Software Delivery
Integrity Controls, Vendor Software
Development Integrity Controls
SP800181: SP-DEV-001; K0009, K0039,
K0073, K0153, K0165, K0275, K0531

18
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Respond to Vulnerabilities (RV)
Identify and Confirm RV.1.1: Gather information from • Establish a vulnerability response BSA: VM.1-3, VM.3
Vulnerabilities on an Ongoing consumers and public sources program, and make it easy for security BSIMM10: CMVM1.2, CMVM3.4
Basis (RV.1): Help ensure that on potential vulnerabilities in the researchers to learn about your program PCISSLRAP: 3.4, 4.1, 9.1
vulnerabilities are identified software and any third-party and report possible vulnerabilities.
more quickly so they can be components that the software SAMM15: IM1-A
• Monitor vulnerability databases, security
remediated more quickly, uses, and investigate all credible SCAGILE: Operational Security Task 5
mailing lists, and other sources of
reducing the window of reports. vulnerability reports through manual or SCTPC: 3.2.4
opportunity for attackers. automated means. SP800181: K0009, K0038, K0040,
• Use threat intelligence sources to better K0070, K0161, K0362; S0078
understand how vulnerabilities in general
are being exploited.
RV.1.2: Review, analyze, and/or • Configure the toolchain to perform BSA: VM.1-2
test the software’s code to automated code analysis and testing on ISO27034: 7.3.6
identify or confirm the presence a regular basis. PCISSLRAP: 3.4, 4.1
of previously undetected • [See Review and/or Analyze Human-
vulnerabilities. SP800181: SP-DEV-002; K0009, K0039,
Readable Code to Identify K0153
Vulnerabilities and Verify Compliance
[See Review and/or Analyze Human-
with Security Requirements (PW.7)]
Readable Code to Identify
• [See Test Executable Code to Identify Vulnerabilities and Verify Compliance
Vulnerabilities and Verify Compliance with Security Requirements (PW.7)]
with Security Requirements (PW.8)] [See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
RV.1.3: Have a team and • Have a policy that addresses BSA: VM.1-1, VM.2, VM.2-3
process in place to handle the vulnerability disclosure and remediation, MSSDL: Practice 12
responses to vulnerability and implement the processes needed to SAMM15: IM1-B, IM2-A, IM2-B
reports and incidents. support that policy.
SCFPSSD: Vulnerability Response and
• Have a security response playbook to Disclosure
handle a generic reported vulnerability, a
SP800160: 3.3.8
report of zero-days, a vulnerability being
exploited in the wild, and a major SP800181: K0041, K0042, K0151,
ongoing incident involving multiple K0292, K0317; S0054; A0025
parties.

19
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

Assess, Prioritize, and RV.2.1: Analyze each • Use issue tracking software (existing BSA: VM.2, VM.2-1, VM.2-2
Remediate Vulnerabilities vulnerability to gather sufficient software, if available) to document each PCISSLRAP: 4.2
(RV.2): Help ensure that information to plan its vulnerability. SCAGILE: Tasks Requiring the Help of
vulnerabilities are remediated as remediation. • Estimate how much effort would be Security Experts 10
quickly as necessary, reducing required to remediate the vulnerability.
the window of opportunity for SP80053: SA-10
• Estimate the potential impact of SP800160: 3.3.8
attackers.
vulnerability exploitation. SP800181: K0009, K0039, K0070,
• Estimate the resources needed to K0161, K0165; S0078
weaponize the vulnerability, if that has
not already been done.
• Estimate any other relevant factors
needed to plan the remediation of the
vulnerability.
RV.2.2: Develop and implement • For each vulnerability, make a risk- BSA: VM.1-1, VM.2-3, VM.2-4
a remediation plan for each based decision as to whether it will be PCISSLRAP: 4.1, 4.2
vulnerability. remediated or if the risk will be SCAGILE: Operational Security Task 2
addressed through other means (e.g.,
SCFPSSD: Fix the Vulnerability, Identify
risk acceptance, risk transference).
Mitigating Factors or Workarounds
• For each vulnerability to be remediated,
SP800181: T0163, T0229, T0264;
determine how its remediation should be
K0009, K0070
prioritized.
• If a permanent mitigation for a
vulnerability is not yet available,
determine how the vulnerability can be
temporarily mitigated until the permanent
solution is available, and add that
temporary remediation to the plan.
Analyze Vulnerabilities to RV.3.1: Analyze all identified • Document the root cause of each BSA: VM.2-1
Identify Their Root Causes vulnerabilities to determine the discovered issue. PCISSLRAP: 4.2
(RV.3): Help reduce the root cause of each vulnerability. • Document lessons learned from root SAMM15: IM3-A
frequency of vulnerabilities in cause analysis in a knowledge base that
the future. SP800181: T0047, K0009, K0039,
developers can access and search. K0070, K0343
RV.3.2: Analyze the root causes • Document lessons learned from root BSA: VM.2-1, PD.1-3
over time to identify patterns, cause analysis in a knowledge base that MSSDLPG52: Phase Two: Design
such as when a particular developers can access and search. PCISSLRAP: 4.2
secure coding practice is not • Add mechanisms to the toolchain to
being followed consistently. SP800160: 3.3.8
automatically detect future instances of
SP800181: T0111, K0009, K0039,
the root cause.
K0070, K0343

20
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Practices Tasks Implementation Examples References

RV.3.3: Review the software for • [See Review and/or Analyze Human- BSA: VM.2
other instances of the reported Readable Code to Identify PCISSLRAP: 4.2
problem and proactively fix them Vulnerabilities and Verify Compliance SP800181: SP-DEV-001, SP-DEV-002;
rather than waiting for external with Security Requirements (PW.7)] K0009, K0039, K0070
reports. • [See Create Source Code Adhering to
Secure Coding Practices (PW.5)]
RV.3.4: Review the SDLC • Document lessons learned from root BSA: PD.1-3
process, and update it as cause analysis in a knowledge base that BSIMM10: CMVM3.2
appropriate to prevent (or developers can access and search. MSSDL: Practice 2
reduce the likelihood of) the root • Plan and implement changes to the
cause recurring in updates to PCISSLRAP: 2.6, 4.2
appropriate SSDF practices.
this software or in new software SP800181: K0009, K0039, K0070
that is created.

21
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

References

[1] Newhouse W, Keith S, Scribner B, Witte G (2017) National Initiative for Cybersecurity
Education (NICE) Cybersecurity Workforce Framework. (National Institute of Standards
and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-181.
https://doi.org/10.6028/NIST.SP.800-181

[2] National Institute of Standards and Technology (2018), Framework for Improving
Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standards and
Technology, Gaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.04162018

[3] Migues S, Steven J, Ware M (2019) Building Security in Maturity Model (BSIMM)
Version 10. Available at https://www.bsimm.com/download/

[4] BSA (2019) Framework for Secure Software. Available at

https://www.bsa.org/reports/bsa-framework-for-secure-software

[5] 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

[6] International Organization for Standardization/International Electrotechnical

Commission (ISO/IEC), Information technology – Security techniques – Application
security – Part 1: Overview and concepts, ISO/IEC 27034-1:2011, 2011. Available at
https://www.iso.org/standard/44378.html

[7] Microsoft (2019) Security Development Lifecycle. Available at

https://www.microsoft.com/en-us/sdl

[8] Open Web Application Security Project (2019) OWASP Application Security Verification
Standard 4.0. Available at https://github.com/OWASP/ASVS

[9] Open Web Application Security Project (2014) OWASP Testing Guide 4.0. Available at
https://www.owasp.org/images/1/19/OTGv4.pdf

[10] Payment Card Industry (PCI) Security Standards Council (2019) Secure Software
Lifecycle (Secure SLC) Requirements and Assessment Procedures Version 1.0. Available
at https://www.pcisecuritystandards.org/document_library?category=sware_sec#results

[11] Open Web Application Security Project (2017) Software Assurance Maturity Model
Version 1.5. Available at https://www.owasp.org/index.php/OWASP_SAMM_Project

[12] Software Assurance Forum for Excellence in Code (2012) Practical Security Stories and
Security Tasks for Agile Development Environments. Available at
http://www.safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf

22
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

[13] Software Assurance Forum for Excellence in Code (2018) Fundamental Practices for
Secure Software Development: Essential Elements of a Secure Development Lifecycle
Program, Third Edition. Available at https://safecode.org/wp-
content/uploads/2018/03/SAFECode_Fundamental_Practices_for_Secure_Software_Dev
elopment_March_2018.pdf

[14] Software Assurance Forum for Excellence in Code (2010) Software Integrity Controls:
An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain.
Available at
http://www.safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf

[15] Software Assurance Forum for Excellence in Code (2017) Managing Security Risks
Inherent in the Use of Third-Party Components. Available at
https://www.safecode.org/wp-
content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf

[16] Software Assurance Forum for Excellence in Code (2017) Tactical Threat Modeling.
Available at https://www.safecode.org/wp-
content/uploads/2017/05/SAFECode_TM_Whitepaper.pdf

[17] Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for
Federal Information Systems and Organizations. (National Institute of Standards and
Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Revision 4,
Includes updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4

[18] 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.
https://doi.org/10.6028/NIST.SP.800-160v1

23
NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF

Appendix A—Acronyms

BSIMM Building Security In Maturity Model

CISQ Consortium for Information & Software Quality
COTS Commercial-Off-the-Shelf
CPS Cyber-Physical System
DevOps Development and Operations
GOTS Government-Off-the-Shelf
ICS Industrial Control System
IDA Institute for Defense Analyses
IEC International Electrotechnical Commission
IoT Internet of Things
ISO International Organization for Standardization
ISPAB Information Security and Privacy Advisory Board
IT Information Technology
ITL Information Technology Laboratory
KPI Key Performance Indicator
MITA Medical Imaging & Technology Alliance
NAVSEA Naval Sea Systems Command
NICE National Initiative for Cybersecurity Education
NIST National Institute of Standards and Technology
OWASP Open Web Application Security Project
PCI Payment Card Industry
SAFECode Software Assurance Forum for Excellence in Code
SAMM Software Assurance Maturity Model
SBOM Software Bill of Materials
SDL [Microsoft] Security Development Lifecycle
SDLC Software Development Life Cycle
SEI Software Engineering Institute
SLC Software Lifecyle
SOAR State-of-the-Art Resources
SSDF Secure Software Development Framework

24