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 Development
PO.2: Implement Roles and Responsibilities
PO.3: Implement Supporting Toolchains
PO.4: Define and Use Criteria for Software Security Checks
PO.5: Implement and Maintain Secure Environments for Software Development
Protect the Software (PS)
PS.1: Protect All Forms of Code from Unauthorized Access and Tampering
PS.2: Provide a Mechanism for Verifying Software Release Integrity
PS.3: Archive and Protect Each Software Release
Produce Well-Secured Software (PW)
PW.1: Design Software to Meet Security Requirements and Mitigate Security Risks
PW.2: Review the Software Design to Verify Compliance with Security Requirements and Risk Information
PW.4: Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality
PW.5: Create Source Code by Adhering to Secure Coding Practices
PW.6: Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security
PW.7: Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements
PW.8: Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements
PW.9: Configure Software to Have Secure Settings by Default
Respond to Vulnerabilities (RV)
RV.1: Identify and Confirm Vulnerabilities on an Ongoing Basis
RV.2: Assess, Prioritize, and Remediate Vulnerabilities
RV.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.