In this article, we’ll be going over the 1.1 revision of the Secure Software Development Framework that was published by NIST earlier in 2022.
Join the DZone community and get the full member experience.
The Software Development Lifecycle (SDLC) is a methodology for designing, creating, and maintaining software. There are different variations of the SDLC including waterfall, spiral, and agile. Regardless of which of these variations an organization uses it’s important for an organization to have secure software development practices.
There are three primary reasons for this according to the National Institute of Standards and Technology (NIST):
1) To reduce the number of vulnerabilities in your released software
2) To reduce the impact of exploited vulnerabilities
3) To address the root cause of these vulnerabilities occurring in your applications.
In the security field, it’s always ideal to create applications that are secure by design rather than trying to fix those issues later on. To help companies in this area NIST created what’s called the Secure Software Development Framework (SSDF), which describes a set of high-level practices based on established standards, guidance, and secure software development practice documents.
In this article, we’ll be going over the 1.1 revision of The Secure Software Development Framework that was published on February 3rd, 2022. The SSDF is divided into four groups by NIST and we will be discussing each of these groups in the order they are given:
This section is about ensuring that people, processes, and technology are prepared to perform secure software development at the organizational level.
The first goal here is to ensure that the security requirements for software development are known by everyone involved in the SDLC, so they can be taken into account as the software is being developed. To do this you need to identify and document all security requirements for the software. These requirements should be maintained and updated as the software is developed and new features are added. It’s also important that requirements are communicated to all third parties that will provide commercial software components to the organization for reuse in the software. This way third-party vendors can be required to meet the appropriate level of security standards. If you are using open-source software/code then you need to do your own due diligence to ensure that it meets your security requirements.
Next, you must implement roles and responsibilities for the different people involved in the SDLC. This ensures that everyone inside and outside the organization involved in the SDLC will know exactly what is expected of them. To do this effectively you need to create new roles and alter existing roles to ensure that all parts of the SDLC are covered. These need to be reviewed and maintained regularly. You should also provide role-based training for everyone involved in the process to ensure that they can fulfill their role competently. It’s also necessary to obtain upper management’s commitment to secure development and convey that to your team. This will make people take the initiative more seriously and make it more of a focus for the development team.
Third, you want to implement supporting tools for secure development. This allows you to use automation to reduce human effort, minimize errors and increase the reproducibility of your security practices throughout the SDLC. It’s always better to automate security processes than to require a human to perform that action. The first step is to identify what tools you want to include in order to mitigate your identified risks and how these tools will be integrated with each other. Be sure to follow recommended security practices when deploying, operating, and maintaining tools and toolchains in the SDLC. Then configure them to perform optimally in the support of the practices that you defined as an organization.
