The first step in any project is creating a list of requirements. In enterprise software development, this step may actually one of the most time-consuming parts. It frequently requires coordinating with several departments and stakeholders, each of them providing information about what the product should do, how it should behave, and how it should tie in with existing solutions. This may include diverse groups such as legal, marketing, engineering, and others. The result of the process is a prioritized wish-list, and most likely some sketches that show how the new product may connect to existing products.
From here on, the next steps somewhat depend on the individual organization and their development model. Although there are a variety of models, a large percentage of projects are developed using a variant of the waterfall model or some flavor of agile development models. Interestingly enough, these two models are representing the two extremes with respect to release cycle lengths. There is a lot of fuzz around how different agile is from waterfall, and sometimes people can get quite agitated around which model works better. I will skip this discussion here, and just note that each of these models has similar phases that are relevant for a secure software development process. The main difference is how the phases are executed, and how the results are used in the development process.
As an example, each project shares the initial requirements gathering phase. This phase is so universal because we always have to find out what we want to build, whether the market needs this, and how the development will be funded. In this stage, it does not matter whether the product is commercial or open source or a mix, because even a developer working in their free time will ask the question of whether implementing e.g. yet another web content management system would be worth their time.
Once an investment decision has been made, the next steps differ to a certain extent. For example, a team using a waterfall style development model will now start a very detailed analysis of the high level requirements gathered earlier, and turn them into much more detailed requirements and specifications. A team following an agile approach will start with a more preliminary design, release code early and release often, and continuously refine the product until it fulfills all of the project sponsor’s requirements. Such a release is often called a “Potentially Shippable Increment”, or PSI. And although agile seems to be so much different from the waterfall model, the agile team will perform similar steps in each PSI as waterfall team does. The difference is in the planning horizon: while the waterfall team plans for e.g. two years, an agile team may only plan for a couple of weeks. Still, the agile process requires a longer term vision to keep the project on track.
The Secure Software Development Lifecycle Process, or SSDLC process for short, should tie in seamlessly into the existing development model that a specific team choses. There are several models of SSDLC processes, but none of the better processes requires the teams to actually change how they develop their product.