NIST SP 800-218: Secure Software Development Framework
A gist of the NIST SP 800-218 publication on Secure Software Development Framework.
NIST Special Publication 800-218 on Secure Software Development Framework (SSDF) v1.1 offers recommendations for mitigating the risk of software vulnerabilities. Here's the 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.
Software development life cycle (SDLC) models rarely address software security, leading to downstream vulnerabilities and exploitable weaknesses. Addressing security early, i.e. shifting left, reduces the cost and effort of maintaining the software, leading to a more resilient security posture.
According to NIST, to maximize the benefits of SSDF, organizations should integrate SSDF throughout the SDLC, express secure software development requirements using SSDF, and acquire software that meets SSDF practices. SSDF focuses on outcomes of the practices, rather than the tools, techniques and mechanisms used, making it widely useable.
SSDF practices are organized into four groups, with each practice including the practice title, a brief description, tasks that need to be performed, notional implementation examples, and external references. Here's a summary of the practices and sub-practices for reference.
Prepare the Organization (PO)
PO.1
: Define Security Requirements for Software DevelopmentPO.2
: Implement Roles and ResponsibilitiesPO.3
: Implement Supporting ToolchainsPO.4
: Define and Use Criteria for Software Security ChecksPO.5
: Implement and Maintain Secure Environments for Software Development
Protect the Software (PS)
PS.1
: Protect All Forms of Code from Unauthorized Access and TamperingPS.2
: Provide a Mechanism for Verifying Software Release IntegrityPS.3
: Archive and Protect Each Software Release
Produce Well-Secured Software (PW)
PW.1
: Design Software to Meet Security Requirements and Mitigate Security RisksPW.2
: Review the Software Design to Verify Compliance with Security Requirements and Risk InformationPW.4
: Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating FunctionalityPW.5
: Create Source Code by Adhering to Secure Coding PracticesPW.6
: Configure the Compilation, Interpreter, and Build Processes to Improve Executable SecurityPW.7
: Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security RequirementsPW.8
: Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security RequirementsPW.9
: Configure Software to Have Secure Settings by Default
Respond to Vulnerabilities (RV)
RV.1
: Identify and Confirm Vulnerabilities on an Ongoing BasisRV.2
: Assess, Prioritize, and Remediate VulnerabilitiesRV.3
: Analyze Vulnerabilities to Identify Their Root Causes
A gist offers an "escalator preview" of the white paper being reviewed. It is not intended to be exhaustive or to offer an opinion, and readers are encouraged to read the white paper in its entirety for full benefit.