NIST SP 800-218 SSDF VERSION 1.1
5
Table 1: The Secure Software Development Framework (SSDF) Version 1.1
Practices Tasks Notional Implementation Examples References
Prepare the Organization (PO)
Define Security Requirements for Software
Development (PO.1): Ensure that security
requirements for software development are
known at all times so that they can be taken into
account throughout the SDLC and duplication of
effort can be minimized because the
requirements information can be collected once
and shared. This includes requirements from
internal sources (e.g., the organization’s policies,
business objectives, and risk management
strategy) and external sources (e.g., applicable
laws and regulations).
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
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
PO.1.3: Communicate requirements to all third parties
who will provide commercial software components to
the organization for reuse by the organization’s own
software. [Formerly PW.3.1]
Example 1: Define a core set of security requirements for software components,
and include it in acquisition documents, software contracts, and other agreements
with third parties.
Example 2: Define security-related criteria for selecting software; the criteria can
include the third party’s vulnerability disclosure program and product security
incident response capabilities or the third party’s adherence to organization-
defined practices.
Example 3: Require third parties to attest that their software complies with the
organization’s security requirements.
BSAFSS: SM.1, SM.2, SM.2-1, SM.2-4
BSIMM: CP2.4, CP3.2, SR2.5, SR3.2
EO14028: 4e(vi), 4e(ix)
IDASOAR: 19, 21
IEC62443: SM-9, SM-10
MSSDL: 7
NISTCSF: ID.SC-3
OWASPSAMM: SR3-A