Producing a perfect (if there is such a thing) software package is dependent on getting every phase of the SDLC absolutely right. It follows then that to produce a secure software package it is critical to incorporate security in each phase of the SDLC.
SDLC Phase | Security incorporation | Consequence of NOT incorporating security |
Requirements Planning and Analysis | · Security and Privacy Requirements
· Setting up Quality Gates · Risk Assessment |
· No knowledge of privacy and security risks
· Leads to development of a highly vulnerable software |
Design and Architecture | · Attack Surface Analysis/Reduction
· Use Threat Modeling |
· Leads to development of software which has a larger area open for attack
· No knowledge of potential threats |
Development and Coding | · Use Approved tools and software frameworks
· Deprecate Unsafe Functions · Perform Static Analysis, Dynamic Analysis, and Code Review · Implement safe coding guidelines |
· Leads to critical coding errors like buffer overflow, stack overflow, software exceptions, unsafe type-casting, unsafe inheritance modeling etc. |
Testing | · Penetration testing
· White-hat hacking |
· No knowledge of potential attacks
· Software is a sitting duck for (malicious) hackers |
Deployment and Maintenance | · Create an incident response plan
· Encrypted licensing · Documentation |
· Will not be capable of handling security incidents
· Will be open to being victims of piracy · Will not allow further secure development (if through documentation is missing) |
It can be seen that the consequences of going through the SDLC without weaving in security can prove fatal to the health and longevity of the software. Each phase of the cycle has a huge influence on determining the strengths, and particularly the flaws, on the phases that follow. Hence, it is vital for security to be incorporated in every phase of the SDLC.