INTRODUCTION TO SSDLC
WHAT IS SECURE SOFTWARE DEVELOPMENT LIFE CYCLE
INTRODUCTION TO SOFTWARE DEVELOPMENT LIFE CYCLE MODELS
• Planning & requirements • Architecture and design • Test planning • Coding • Testing & results • Release & maintenance
In addition to this, there are several traditional software development models that engineers utilize for developing software, such as the Waterfall, Agile, Scrum, and DevOps. Each of the aforementioned development models has its pros and cons. The Waterfall model can be described as a linear, step-by-step, sequential development strategy with a top-down approach and specific goals for each phase, allowing for easier management and departmentalization. In contrast, Agile is a more collaborative model that has teams build modules in increments after a basic initial design is determined, which is followed by evaluations and more module development.
Scrum is a part of the Agile development model, and describes a particular approach in utilizing the Agile development model. DevOps seeks to create collaboration among IT silos so that QA teams, software developers and operations admins/engineers work together throughout the SDLC. It is important to note that traditional SDLC models do not include security testing or secure coding into their methodologies or phases. Because of this, security is often an afterthought among businesses, and even worse, a majority of executives believe that the application security level of their corporation is satisfactory, while only a fraction of developers believe the same. In addition to this, only 11 percent of developers believe that their organization has a fully-deployed security training program for their personnel. This results in security flaws in many software applications - flaws that are only identified near the end of the software development lifecycle (usually the testing or release phase), if at all, and consequentially are very difficult and expensive to remediate.
As many IT firms do not have a large budget for security, IT security is thus not a top priority, and even worse, many corporations take the approach of simply reacting to security vulnerabilities (as opposed to proactively testing for them) after the application has been developed and flaws have been found - either by personnel, researchers, end-users, or by hackers. For the former (personnel) - since testing usually occurs near the end of the SDLC - costs and timelines often do not allow businesses to go back and remediate the developed software. Often security flaws that are found late in the SDLC are allowed to stay, since quickly-developed, functional applications are often top priority for the sake of revenue and sales. The alternative is a security ``quick fix,`` which often results in the accumulation of technical debt being added at the end of the development process to partly mitigate security flaws. The result is an insecure product being deployed and sent to end-users.
A perfect analogy can be seen with the car manufacturing industry. At the assembly line, quality assurance checks, performance checks, and safety checks are conducted at every checkpoint in the process.DevOps seeks to create collaboration among IT silos so that QA teams, software developers and operations admins/engineers work together throughout the SDLC. It is important to note that traditional SDLC models do not include security testing or secure coding into their methodologies or phases. Deploying software without consistently checking for security flaws at every phase in the SDLC is like sending a new car out to a car dealer for sale without having run any safety checks on it.
THE SECURE SOFTWARE DEVELOPMENT LIFE CYCLE
IS AN IMPROVEMENT ON THE TRADITIONAL LIFE CYCLE MODEL
THE SECURE SDLC
Password authentication and high risk areas of an application exemplify SSDLC approaches versus traditional approaches. While a traditional approach may wait until the end of the DLC to find that a flaw in the application that can allow for a breach, using threat modeling would discover the flaw early in the DLC to allow engineers to harden the application in certain areas. Another example is determining password complexity requirements during the requirements gathering phase, as opposed to never considering such security-based necessities until after the application is developed.