Cooking and software development have a lot in common. With cooking, you bring together different ingredients, looking at how the flavors blend and textures combine. With software development, you combine different components, including open-source libraries and your code. With cooking, you might decide to take something from a recipe, change it a bit, and create your unique take on the dish. Similarly, with coding, you may start with a framework, build your own processes, and create a software development lifecycle (SDLC) that responds to your organization’s unique business objectives.

You can use the NIST Secure Software Development Framework (SSDF) as a customizable “recipe” to help build security into your application from start to finish. 

Introduction to the NIST Secure Software Development Framework (SSDF)

Your SDLC is either a formal or informal approach for designing, creating, and maintaining software, like using waterfall or agile practices. However, the NIST SSDF is a flexible framework that provides development practices you can implement to build security into your SDLC. As a method-agnostic framework, the SSDF outlines practices that development teams can use to integrate security objectives and priorities into their daily activities based on the company’s risk posture. 

The SSDF organizes the practices into the following four categories:

• Prepare the Organization (PO): having the right people, processes, and technologies ready for securing software development
• Protect the Software (PS): protecting components from tampering and unauthorized access
• Produce Well-Secured Software (PW): producing software with minimal security vulnerabilities in releases
• Respond to Vulnerabilities (RV): identifying and remediation any vulnerabilities in software releases or protecting similar ones from happening in the future 

Within each practice, NIST outlines:

• Tasks: actions you can take to fulfill the practice objectives
• Examples: tools, processes, or other methods that show you what implementing a task might look like
• References: other secure development practice documents that map to tasks

Prepare the Organization (PO)

Under the PO practices, you’ll find the typical planning tasks that you’re used to seeing, including:

• Defining security requirements: Identifying, documenting, and communicating requirements for internal and external software development, including maintaining them over time. 
• Implementing roles and responsibilities: Creating new or altering existing roles and responsibilities, supplying the appropriate role-based training, and ensuring upper management is committed to secure development
• Implementing supporting toolchains: specifying, deploying, operating, maintaining tools or tool types that generate artifacts to support risk mitigation capabilities
• Defining and using criteria for software security checks: Defining criteria for software security checks, implementing processes and mechanisms to gather an safeguard data supporting the criteria
• Implementing and maintaining secure environments for software development: separating and protecting each environment, securing and hardening development endpoints

Some implementation examples that NIST provides include:

• Defining a core set of security requirements for software components
• Identifying security tools to integrate into the developer toolchain
• Using existing tooling (e.g., workflow tracking, issue tracking, value stream mapping) to create an audit trail

Protect Software (PS)

Under the PS practices, you’ll find the tasks that help you prevent unauthorized access to the software while its in development:

• Protecting all forms of code from unauthorized access and tampering: storing all forms of code based on the principle of least privilege
• Providing a mechanism for verifying software release integrity: making integrity verification information available to acquirers
• Archiving and protecting each software release: securely archiving necessary files and data, providing provenance data for all components, like a Software Bill of Materials (SBOM)

Some implementation examples that NIST provides include:

• Periodically reviewing the code signing processes, including certificate renewal, rotation, revocation, and protection
• Make the provenance data available to the organization’s operations and response teams to aid them in mitigating software vulnerabilities
• Update the provenance data every time any of the software’s components are updated

Produce Well-Secure Software (PW)

Under the PW practices, you’ll find a lot of the tasks associated with your daily activities as developer:

• Designing well-software to meet security requirements and mitigate security risks: using risk modeling – like threat modeling – to assess security risks, tracking and maintaining secure requirements, risks, and design decisions, supporting standardized security features and services rather than building proprietary implementations
• Reviewing the software design to verify compliance with security requirements and risk information: Having either an independent, qualified person review or use automated processes in the toolchain to review the software
• Reusing existing, well-secured software when feasible instead of duplicating functionality: Acquiring, and maintain well-secured open-source, commercial, and third-party component, creating and maintaining well-secure component in-house, verifying that acquire component comply with organization-defined security requirements throughout their life cycles
• Create source code by adhering to secure coding practices: Following secure coding practices appropriate to development language and environment
• Configure the compilation, interpreter, and build processes to improve executable security: Determining the appropriate compiler, interpreter, and build tools, features, and configurations
• Review and/or analyze human-readable code to identify vulnerabilities and verify compliance with security requirements: Determining whether to engage in manual code review and/or automated code analysis, performing the review or analysis, recording and triaging all discovered issues and remediations
• Test executable code to identify vulnerabilities and verify compliance with security requirements: Determining whether to perform executable code testing, scoping testing, designing the tests, performing the tests, documenting the test results
• Configuring software to have secure settings by default: Designing default configurations based on a defined secure baseline, implementing default settings and documenting these setting for software administrators

Some implementation examples that NIST provides include:

• Review the risk models created during software design to determine whether they adequately identify the risks
• Record the design review’s findings to serve as artifacts
• Review and evaluate third-party software components in the context of intended use
• Obtain provenance information for each software component, like by using an SBOM, source composition analysis, or binary software composition analysis
• Implement processes to update deployed software components to newer versions
• Regularly check software module and vendor services for unpatched publicly known vulnerabilities
• Build into the toolchain automatic detection of known vulnerabilities in software components
• Ensure that each software component is still actively maintained and has not reached end of life, including remediation of new vulnerabilities
• Test to ensure that the features are working as expected and not causing unintended security or operational issues
• Use a static analysis tool to automatically check code for vulnerabilities and compliance with your secure coding standards with person who reviews and remediates the issues as necessary
• Use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios.

Respond to Vulnerabilities (RV)

Under the RV practices, you’ll find practices for maintaining the software and communicating with customers:

• Identifying and confirming vulnerabilities on an ongoing basis: Gathering information from customers, users, and public sources about vulnerabilities in source code or third-party components then reviewing, analyzing, or testing code to identify or confirm a vulnerability’s presence, having a policy to address vulnerability disclosure and remediation
• Assessing, prioritizing, and remediating vulnerabilities: Analyzing each vulnerability to determine risk impact and plan remediation or other response
• Analyzing vulnerabilities to identify their root causes: Analyzing identified vulnerabilities and their root causes, reviewing for similar vulnerabilities, reviewing the SDLC process 

Qwiet AI: An AppSec Platform Built for Any Security Chef

Like a chef needs the right knife set, you need security application testing solutions that help you ship software faster and more securely. Qwiet AI’s preZero platform enables you to rapidly scan your code to identify vulnerabilities in source code and business logic. To help you prioritize your activities, you can focus on those vulnerabilities that attackers can actively use within the context of your application. Further, our Blacklight is the first threat intelligence feed designed to help developers prioritize fixes by focusing on the exploits, threat actors, ransomware, and botnets actively exploiting vulnerabilities in the wild.

We provide more than just tools – we can deliver a fully managed application security service tailored specifically to your organization’s unique needs. Our deep expertise in application security combined with seamless CI/CD integration ensures you’re not just deploying a solution but establishing a robust partnership. 

Take our preZero platform for a spin for free to see for yourself how Qwiet AI integrates into your CI/CD pipelines to help you secure applications.