NIST SSDF: 4 core practices for secure software development

What is the NIST Secure Software Development Framework (SSDF)?

The NIST Secure Software Development Framework (SSDF) is a set of fundamental, outcome-based practices that integrate security throughout the software development lifecycle (SDLC). Documented in NIST SP 800-218, it helps organizations reduce vulnerabilities, prevent recurrences, and establish a common language for secure development.

The SSDF outlines dozens of tasks grouped into four high-level categories:

• Prepare the organization (PO): Define security requirements, roles, responsibilities, and processes so the organization is equipped to develop secure software.
• Protect the software (PS): Safeguard all software artifacts (source code, build artifacts, etc.) against unauthorized access and tampering to protect integrity.
• Produce well-secured software (PW): Build software with minimal vulnerabilities, using secure coding practices, automated testing, and supply chain component management.
• Respond to vulnerabilities (RV): Identify, analyze, and remediate vulnerabilities in deployed software, and address their root causes.

This is part of a series of articles about AI governance.

Why is the NIST SSDF important?

The NIST SSDF helps organizations make software security consistent, measurable, and repeatable. Instead of treating security as a final testing step, it embeds secure practices throughout development and maintenance:

• Reduces software vulnerabilities: Security activities are performed early and throughout the software development lifecycle, helping teams identify and fix weaknesses before release.
• Lowers remediation costs: Defects found during design or development are usually easier and less expensive to correct than vulnerabilities discovered in production.
• Creates consistent development practices: The framework gives teams a common set of security tasks, responsibilities, and expected outcomes across projects.
• Supports supply chain security: Organizations can use the SSDF to assess internal development processes and define security requirements for third-party software suppliers.
• Improves risk management: Practices such as threat modeling, code review, and vulnerability testing help teams understand and reduce software-related risks.
• Supports regulatory and contractual requirements: The SSDF can help organizations demonstrate that secure development controls are documented and followed.
• Strengthens incident response: Maintaining software inventories, vulnerability records, and response procedures helps teams react more quickly when security issues are discovered.

Who should use the NIST SSDF?

The NIST SSDF is intended for stakeholders involved in software development and procurement. This includes software vendors, in-house development teams, DevOps engineers, product managers, security professionals, and organizations that acquire software from third parties. Because the SSDF adapts to different development methodologies and organizational structures, it applies to any entity responsible for producing or managing software.

The SSDF also supports organizations that want to improve supply chain security or meet contractual and regulatory obligations. Government agencies and contractors may be required to align with the SSDF or similar frameworks as part of compliance efforts. Its flexibility allows large enterprises and small businesses to adopt practices appropriate for their scale, resources, and risk tolerance.

The four core NIST SSDF practice groups

1. Prepare the organization (PO)

The Prepare the Organization (PO) practice group establishes the capabilities needed to support secure software development. Rather than focusing on a single project, it defines the policies, governance, and infrastructure that allow security practices to be applied consistently across development efforts. Without this foundation, secure development activities often become inconsistent and depend on individual teams or developers.

Key activities include:

• Secure software development policies and procedures: Organizations should establish clear security objectives, development standards, and minimum security requirements that every project must follow. These policies should align with business objectives, legal obligations, and the organization’s risk management strategy.
• Roles and responsibilities: Developers, architects, security engineers, DevOps teams, QA teams, and management should understand their responsibilities. Clearly defined ownership helps confirm that security tasks such as code reviews, vulnerability remediation, and release approvals are completed consistently.
• Training: Developers should receive regular education on secure coding techniques, common software vulnerabilities such as those described in the OWASP Top 10 and CWE, and secure use of development frameworks and libraries. Security awareness should extend to architects, testers, and operations teams because software security depends on collaboration across the development lifecycle.
• Approved development tools and environments: This includes selecting source code management systems, CI/CD platforms, static and dynamic analysis tools, dependency scanners, secret management solutions, and artifact repositories that support secure development practices. Standardizing tools makes it easier to automate security checks and enforce consistent controls.

2. Protect the software (PS)

The Protect the Software (PS) practice group focuses on protecting software, development environments, and supporting infrastructure from unauthorized access, modification, or disclosure. Modern software development relies on systems including source code repositories, build servers, package registries, and cloud environments that must be secured to protect software integrity.

This group includes:

• Code protection: Source code repositories should be protected using strong authentication, role-based access controls, and audit logging. Organizations should follow the principle of least privilege, granting developers only the permissions necessary for their work. Multi-factor authentication and branch protection rules can reduce the risk of unauthorized code changes.
• Build environments: Compromised build servers can introduce malicious code into legitimate software. Organizations should secure build infrastructure, restrict administrative access, monitor build activities, verify build integrity, and isolate build systems from unnecessary network access. Reproducible and automated builds improve confidence that released software matches the reviewed source code.
• Sensitive information protection: Secrets such as API keys, passwords, encryption keys, certificates, and access tokens should not be stored in source code repositories. Organizations should use dedicated secret management solutions and implement regular credential rotation.

The SSDF also emphasizes protecting software artifacts after they are built. Executables, container images, installation packages, and software updates should be stored securely, digitally signed when appropriate, and distributed through trusted channels. Code signing helps customers verify that software has not been altered after release.

3. Produce well-secured software (PW)

The Produce Well-Secured Software (PW) practice group contains the engineering practices used to develop secure software. It integrates security into every phase of development, from requirements gathering through coding, testing, and release.

Key activities include:

• Development: This begins by identifying software security requirements alongside business and functional requirements. These requirements may include authentication, authorization, encryption, input validation, logging, availability, privacy, and compliance obligations. Addressing these requirements during design reduces the need for architectural changes later.
• Threat modeling: Teams analyze the application’s architecture, identify valuable assets, determine possible attack paths, and evaluate potential threats before implementation begins. This process helps developers prioritize security controls where they reduce the most risk.
• Secure coding: During implementation, developers should follow secure coding practices that reduce common software vulnerabilities. Examples include validating user input, avoiding unsafe functions, using parameterized database queries, implementing proper authentication and authorization checks, handling errors securely, and protecting sensitive data in transit and at rest. Using established security libraries and frameworks instead of custom security code reduces risk.

4. Respond to vulnerabilities (RV)

The Respond to Vulnerabilities (RV) practice group addresses activities required after software has been deployed. No software is free of vulnerabilities, so organizations need defined processes for detecting, evaluating, and responding to newly discovered security issues throughout the product lifecycle.

Key activities include:

• Communication: Organizations should establish clear channels for receiving vulnerability reports from customers, security researchers, internal teams, and automated monitoring systems. Many organizations publish vulnerability disclosure policies or operate coordinated vulnerability disclosure (CVD) programs that encourage responsible reporting.
• Vulnerability triage: Each reported vulnerability should be validated, analyzed, and prioritized based on exploitability, affected systems, business impact, and severity. Standard scoring systems such as the Common Vulnerability Scoring System (CVSS) help organizations prioritize remediation efforts.
• Investigation: Once a vulnerability is confirmed, development teams should investigate the root cause, develop a fix, test the remediation, and prepare software updates. Emergency patch processes may be necessary for vulnerabilities that are actively exploited or affect critical systems.
• Notification: Organizations should notify affected customers, partners, and stakeholders about serious vulnerabilities, provide mitigation guidance when patches are unavailable, and publish security advisories that explain affected versions, risks, and available fixes. When appropriate, vulnerabilities may be assigned Common Vulnerabilities and Exposures (CVE) identifiers to improve industry-wide tracking.

The SSDF also encourages maintaining accurate records of vulnerabilities, remediation activities, and response timelines. These records support audits, regulatory compliance, and internal performance measurement and help organizations identify recurring security weaknesses.

NIST SSDF implementation best practices

Here are six ways to implement the NIST SSDF more effectively.

1. Create a complete inventory of applications and components

Maintaining an inventory of all applications and software components is the foundation of software security. This inventory should include:

• Internally developed software
• Open source libraries
• Third-party components
• All dependencies used throughout the development lifecycle

An up-to-date inventory enables organizations to track what software is in use, identify outdated or vulnerable components, and respond to new security threats. Automated asset discovery tools can help maintain the accuracy and completeness of this inventory. Regular audits and updates support compliance efforts and make it easier to manage software updates, vulnerability assessments, and patch management.

2. Define risk-based security requirements

Defining security requirements based on risk assessment allows organizations to prioritize efforts. By evaluating the potential impact and likelihood of security threats, development teams can establish tailored security controls and practices for each application or system:

• High-risk components or vulnerabilities should be prioritized and remediated first
• Low-risk security requirements can be deferred to a later date or accepted

Security requirements should be documented and communicated to stakeholders involved in the development process. Regular reviews and updates are necessary as threats evolve and new risks are identified. Integrating risk-based requirements early in the software lifecycle helps prevent rework and demonstrates a proactive approach to security.

3. Integrate SAST, SCA, secrets, and IaC scanning into CI/CD

Incorporating security scanning tools into the continuous integration and continuous deployment (CI/CD) pipeline enables early detection of vulnerabilities. These may include:

• Static Application Security Testing (SAST)
• Software Composition Analysis (SCA)
• Secrets detection
• Infrastructure as code (IaC) scanning

Automating these scans applies security checks to every code change. By integrating these tools into CI/CD workflows, organizations can remediate issues before code is merged or deployed. This approach shortens feedback loops for developers. Regular automated scans also support compliance and audit requirements by providing traceability and documentation of security activities.

4. Generate an SBOM for every software release

A software bill of materials (SBOM) is a list of everything included in a software release, including all:

• Components
• Libraries
• Dependencies

Generating an SBOM for every release provides transparency into what is shipped and allows organizations to assess exposure to newly disclosed vulnerabilities. SBOMs are increasingly required by regulators and customers as part of supply chain security initiatives. Automating SBOM generation as part of the release process improves accuracy and reduces manual effort. SBOMs also support incident response by helping security teams identify affected components and prioritize remediation.

5. Protect source code, build systems, and signing infrastructure

Securing the development environment helps prevent unauthorized access and tampering. Source code repositories should be protected with:

• Access controls
• Multi-factor authentication
• Audit logging

Build systems and code signing infrastructure must be hardened to prevent attackers from injecting malicious code or compromising the integrity of software releases. Organizations should review access permissions, monitor for unusual activity, and isolate sensitive infrastructure components. They should enforce least privilege principles and segment networks to limit the impact of a compromise.

6. Maintain traceable evidence of security activities

Documenting and retaining evidence of security activities, such as code reviews, testing results, vulnerability scans, and incident responses, supports accountability and compliance. This traceability allows organizations to:

• Demonstrate adherence to security policies
• Support audits
• Respond to incidents or regulatory inquiries

Detailed records help identify gaps in processes and support continuous improvement. Automating evidence collection within development and deployment pipelines reduces the risk of oversight. Secure storage and regular review of these records keep evidence accessible and tamper-resistant. Maintaining traceable documentation also helps organizations respond to security incidents and meet contractual or legal obligations.

Securing your software development lifecycle with Mend.io

The NIST SSDF calls for protecting software artifacts, integrating security into CI/CD, and responding to vulnerabilities across the entire lifecycle, but doing this consistently at scale requires automation. Mend.io’s software supply chain security helps teams keep applications free of malicious software packages throughout the full software development lifecycle, finding and blocking threats across repositories, CI/CD pipelines, and beyond so security keeps pace with development.

Key capabilities of Mend.io:

• Scan and block malicious packages: Built-in tools automatically find and block malicious packages such as protestware, data stealers, and crypto miners before they introduce vulnerabilities into your dependencies, reducing enterprise risk.
• Map all open source dependencies: Mend SCA maps the open source dependencies used across your projects, giving teams the visibility needed to understand what is in their software and where risk originates.
• Centralize visibility and control: Broad coverage of repositories, CI/CD pipelines, and beyond centralizes visibility and control, stopping malicious packages and vulnerabilities from slipping into the build.
• Risk-based prioritization: Findings are supported with rich context and risk-based prioritization, so teams focus remediation effort on the issues that matter most rather than triaging noise.
• Automated dependency updates: Because staying ahead of malicious packages and exploitable vulnerabilities depends on current dependencies, Mend Renovate automatically keeps dependencies up to date across the pipeline.