Mitigating software supply chain security risks often involves implementing multiple layers of security and different strategies. But one of the most efficient approaches to keeping your software secure is addressing possible security vulnerabilities during the development stage of your software application. This is often a challenge since only a few software development life cycle models explicitly address the issues of software security. To keep your software secure, you will need to adopt secure software development practices for whatever software development lifecycle model you choose to use.
The Secure Software Development Framework (SSDF) outlines some of the fundamental practices you should follow to ensure the security of the software you’re building. The SSDF is based on standard software development security practices established by the National Institute of Standards and Technology (NIST) and explicitly addresses security issues in software development. The SSDF version 1.1 is defined in NIST SP 800-218 publication. The framework was initially published in September of 2021 as a draft version. On March 22, 2021, NIST released the final version of the SSDF 1.1. All the high-level practices and tasks remained the same with a lot of the differences centered around the various examples provided. In deciding which practices to implement, NIST recommends balancing risk against cost, feasibility, and applicability. Automating as many checks and processes promoting software security as possible is a key feature to consider.
As an organization working with a software development life cycle model, you should implement the guidelines of the SSDF as part of the overall efforts to secure your software from software supply chain vulnerabilities. Following this framework will aid in the detection of unaddressed vulnerabilities before the software is released. This reduces the risk and impacts of possible security exploitations due to these undetected vulnerabilities. This article is a comprehensive guide that details what the SSDF framework is and how it contributes to software supply chain security.
The 4 Practices of Secure Software Development Framework
The SSDF practices are grouped into four categories. In the SSDF framework, each practice is identified by a unique identifier and a brief explanation on what it is, why it is beneficial, and the tasks that need to be performed to implement it. The framework also includes examples of tools, processes, and methods for implementing the practices with references to established secure development practice documents. The following are the four pillar practices of Secure Software Development Framework (SSDF) Version 1.1:
Prepare the Organization (PO)
Secure software development is highly people-dependent. Therefore, the first step when implementing the SSDF is to ensure everyone in your organization is sufficiently prepared for the changes the framework will require. To start, you must identify the specific security requirements of the software you’re developing based on the tools they’ll be using for software development. This way you can start preparing the people, processes, and technology they use, both at organizational and individual levels.
Preparing the organization usually comes in the form of getting buy-ins from top management and implementing necessary training for employees. Part of your preparation efforts may also include implementing tools that help automate processes and create a secure environment for development.
Protect the Software (PS)
The Secure Software Development Framework outlines practices for protecting all components of your software from unauthorized access and tampering. This is an important step to help prevent unauthorized changes to code, both inadvertent and intentional, and to protect your software source code and software configuration. Protecting your software can involve different approaches depending on the specific situation. When code is not intended to be publicly accessible, this can prevent theft of the software and make it harder or more time-consuming for attackers to find vulnerabilities.
By following the practices outlined in this section of the SSDF, software consumers ensure that the software they acquire is legitimate and has not been tampered with. Additionally, it helps identify, analyze, and eliminate vulnerabilities in software after release by preserving software releases.
Produce Well-Secured Software (PW)
To produce well-secured software with minimal security vulnerabilities, there are basic steps to follow throughout the software development lifecycle. These include:
- Choosing secure software configurations
- Evaluating any third-party component of your software to ensure its integrity
- Ensuring your software source code is compliant with secure coding practices
- Reviewing, analyzing, and testing your code for vulnerabilities and addressing any issues identified before the code is released
- Preventing vulnerabilities using build tool features like compilers and interpreters
Respond to Vulnerabilities (RV)
Even after your software is released, there’s still a chance that you’ll discover vulnerabilities in it. Testers within your organization, external security researchers, or even customers may discover these vulnerabilities. An important part of securing your software is responding swiftly to these vulnerabilities as soon as they’re discovered. The longer you conceal a security loophole, the greater the damage it can do. Every organization needs a vulnerability disclosure program, as well as other policies, to analyze new vulnerabilities and decide how they should be addressed.
What Are the Main Points to Consider?
The main purpose of the SSDF is to help organizations to align and prioritize security in their software development activities. The SSDF takes the business requirements, risk tolerances, and resources into consideration when implementing security in the software development lifecycle. Some of the key considerations of this framework include:
-
Integrate security into the SDLC
The first step in building secure software is to integrate security into the different steps and stages of your software development lifecycle. Essentially, your development team must have a security-focused culture and this must begin even in the earliest phase of the development process.
In most cases, many of the standard coding practices introduce numerous vulnerabilities that can be exploited by malicious parties later when the software is released. This is why developers must think of security from the onset, and must be well-educated on the strategies that help reduce these potential attack routes.
In addition to thinking about the human aspects of securing your software, you should also consider automating the process of testing and monitoring your software for potential vulnerabilities right from the onset.
-
Secure software development policy
A secure software development policy is a formal set of guidelines that details the practices and procedures that your organization follows for secure software development. This policy document contains detailed instructions for the people, technology, and processes you follow for every phase of the development lifecycle.
A secure software development policy is more than just a recommendation to increase the integrity of your software. It is even mandatory in some instances. For example, if your software must meet security standards such as the ISO 27001 or the SOC Type 2 standards, then you’ll need secure development policy documentation. Fortunately, there are template guides you can adopt for this purpose. Your software security team can also build the policy documentation from scratch and adapt it to your specific needs.
-
Third-party vendors
It’s not enough to write secure code and follow security requirements internally. Most software still takes components from third-party vendors who may not follow the same security standards as you do. These third-party code components are common pathways through which software supply chain attacks are carried out.
As part of the efforts to ensure security compliance throughout your software development lifecycle, you should monitor all third-party components you use and make sure the vendors are fully aware of your security requirements and are fully compliant with the same security standards as you.
-
Code integrity protection
Your software code and all its components are potential points of attack that malicious actors can exploit to inject vulnerabilities into your software. To prevent this, all codes should be kept in secured repositories when they’re safe from any form of tampering.
Part of efforts to maintain code integrity include ensuring that only authorized developers have access to the source code. Your choice of code repository should have features to ensure this, as well as additional features to secure the sign-in process and monitor any changes that may be made to your code. You can further improve code integrity by employing automation to monitor access data and carry out periodic code analysis.
-
Pre-installed malware
One common pathway for software supply chain attacks is to hide security vulnerabilities in pre-installed malware. This could be a virus, ransomware, trojan horse, or spyware that can wreak havoc on your software. The malware may be preinstalled on devices or trusted software you use in your software build process or even on a third-party vendor’s system. This malware may stay hidden for a long time until a legitimate, digitally signed process allows it to spread through your system. Securing your software development involves watching out for this pre-installed malware and putting measures in place to identify and remove them.
-
Code testing, review, and checklists
The traditional approach to software development usually leaves code testing to the end of the software development lifecycle. However, this reactive approach to catching software vulnerabilities is not very effective. A more efficient approach is to set up automated testing to continually catch flaws in the code as you build. Developers should also review and check their code manually to prevent frustration when flaws are discovered later.
Since there are numerous parts and components to track, it makes sense to make checklists as you build. This helps your software development and monitoring team ensure all the actions set out in the SSDF policies are duly adhered to.
-
Vulnerabilities mitigation
Despite compliance with the SSDF and other security standards, vulnerabilities are practically unavoidable in software development. The most important thing is to be ready to mitigate these vulnerabilities when they do occur. This would mean having a team in place with clearly laid-out plans and strategies to address security incidents as soon as they occur.
How quickly your organization can respond to security vulnerabilities will make a world of difference in reducing the adverse impacts of such attacks. When software flaws are caught and fixed quickly, malicious actors will have a shorter window to exploit them. Thus, vulnerability mitigation is an important aspect of secure software development that every organization must pay attention to.
-
Secure default settings
Your new software should have default security settings that help protect users from software vulnerabilities even without advanced knowledge. You can also implement measures that educate users about these default settings to keep them protected even in the early stages of adopting your software.
Conclusion
The Secure Software Development Framework (SSDF) is a set of advanced practices that should be integrated into every organization’s software development lifecycle. By following the practices set out in this framework early in the development process, you can reduce the security flaws in the version of your software you eventually release. The SSDF also helps you detect security risks and reduces the potential impact of undetected vulnerabilities that make it into the final release. This framework is key to preventing such security issues from recurring in the future.