In the first post of our series – Simple Secure Development Lifecycle for Startups – Sente Security’s Jarred White and Security Engineer Gabriel Marquet provide an overview on why having a Secure Software Development Lifecycle is important, and why – even if you don’t feel you need one – starting to build one now will be advantageous in the future. In subsequent posts, we will explore the core security activities that should be included in any development lifecycle and provide guidance on how to incorporate them into your existing processes.
What’s a Secure SDL, and why do I need one?
Sometimes vulnerabilities are discovered internally by your own organization. Maybe you have a testing procedure that performs some basic vulnerability scanning prior to release (more on that in a subsequent post). More frequently, however, and especially with startups and small businesses, vulnerabilities are discovered by your customers, who will often be much larger, better resourced, and have teams built specifically to test vendor software for vulnerabilities.
We’ve seen firsthand the time and resources organizations put into remediating software vulnerabilities after they have been discovered through a customer’s testing process. Although most non-serious vulnerabilities tend to get ignored, serious vulnerabilities or those reported by customers can receive executive attention and result in phone calls and ultimatums. This is a scenario you want to avoid, especially since resolving a vulnerability may not always be straightforward to implement and test. Design activities around architectural or large functional changes can create a lot of toil which results in direct costs in terms of actual person hours spent and potential opportunity lost.
As you have likely surmised, avoiding these situations is why you need a Secure Software Development Lifecycle (Secure SDL). As your business grows, you will be asked by customers to demonstrate that security is considered as part of the software development process, so by implementing elements of a basic Secure SDL from the very start you can save yourself and your team from headaches down the road.
Makeup of a Secure SDL
The goal of a Secure Software Development Lifecycle is to reduce released vulnerabilities by incorporating security activities throughout the development process as opposed to performing such activities only after the software has been built and deployed. You will hear this described in many ways, such as “baking security in” or making security an “inherent part of the software development process.” You’ll even see different terms and acronyms used to describe these activities. I simply prefer to call it the “Secure SDL (Software Development Lifecycle).”
You will also see many different definitions of the activities that should be part of a Secure SDL. Unfortunately, there is no one-size-fits-all set of activities that work for every organization. In our experience working with software teams from 15 engineers to 1,500, we’ve seen many ways that security activities can be included as part of the development process, and many of them that worked at one company would not have worked at another one. Release cadence, development platforms, team makeup, development methodology, availability of security expertise, and even culture are all important aspects that define how security activities should be integrated into the development process. But there are some core security activities that should be part of every development lifecycle regardless of an organization’s unique characteristics.
Secure SDL Activities
There are three core activities that are the most important to consider when you want to integrate security into your product development lifecycle, and in our following posts we’ll dive into each activity and provide some insights on how to incorporate them into your processes. We’ll cover the following core activities:
- Threat modeling
- Evaluation of third-party libraries and components
- Implementation of security tooling
These activities should be basic enough to be effective and efficient for startups and smaller-sized companies that aren’t able to rely on in-house security experts. Developers and architects with limited experience in security should be able to perform these activities largely on their own, or with a small boost from an outside expert.
You should keep in mind that secure development is more of a way of thinking and behaving that informs how you develop and release software. It is also a system of trust between developers, product managers, security teams (if you are large enough to have them), and customers that requires everyone to share a set of common goals and outcomes. And like any process, the activities that make up your Secure SDL should be periodically reviewed and changed as needed to ensure they are adding value.
In our next post, we will take a deeper look at the first activity – threat modeling – and why it is one of the most important activities you should incorporate into your Secure SDL. Stay tuned!