Secure software development is often interpreted as secure coding practices, such as using code that properly validates input and handles errors. While those are important, there are many other secure software development practices to also follow.
NIST’s Secure Software Development Framework (SSDF) version 1.1 is a technology-neutral set of secure software development practices based on existing standards and guidelines — essentially, a greatest hits of secure software development. Adhering to these practices during the software development lifecycle (SDLC) can reduce vulnerabilities in software and mitigate attacks.
Let’s take a look at four of the most important practices from the SSDF to incorporate into every SDLC. Every organization should use these practices, no matter their software development model, language, environment or tools. These practices are critical to the foundation of all software development, including the support and maintenance of existing software.
1. Prepare your organization
Ensure your organization is sufficiently prepared for secure software development. This starts with identifying security requirements for the software you’ll be developing and for the people, processes and tools doing the software development.
Next, prepare people using training activities and management buy-in. Other aspects of preparation include implementing tools and toolchains to automate processes and safeguarding the environments and endpoints used for development.
2. Produce well-secured software
Producing well-secured software includes performing practices throughout the SDLC. These include the following:
- designing software to comply with security requirements;
- building libraries of secure software modules and then reusing existing modules in new software instead of re-implementing the same functions again;
- ensuring source code complies with secure coding practices;
- using compiler, interpreter and build tool features that help prevent vulnerabilities;
- reviewing, analyzing and testing code for vulnerabilities and deciding how to address those vulnerabilities before releasing the software;
- choosing software configurations that are secure by default; and
- evaluating third-party software components to ensure they’re not introducing their own vulnerabilities into your software.
3. Protect your software
Organizations need to protect software source code, configuration as code and other forms of code. The approach for doing this, however, varies depending on the situation. For example, open source code might only need its integrity protected, so as to avoid attackers adding malicious code. Other code may need its confidentiality protected to prevent intellectual property theft, in addition to protecting its integrity.
4.Respond to vulnerabilities
Vulnerabilities will inevitably be discovered in released software — whether by your own organization, your customers or security researchers. The public is increasingly expecting organizations to respond swiftly when a vulnerability is discovered in their software. Concealing knowledge of vulnerabilities for weeks or months can be highly damaging to a software-developing organization’s reputation.
Be prepared to respond to vulnerabilities by having a vulnerability disclosure program and related policy, analyzing new vulnerabilities and quickly deciding how to address them, implementing and testing software changes, and finding and addressing the root causes of vulnerabilities in released software.