Why Should Companies Migrate from SDLC to Secure SDLC

Security has always been considered a luxury by most enterprises, the majority being SMBs. But looking at the recent sophisticated attacks like PandaBuys’s data hack that almost put 1.3 million users at risk, we have learned that hackers have complex attack strategies under their sleeves. This makes it really difficult for firewalls and so-called AI threat intelligence tools to stop these attacks. Most companies give more importance to quality assurance testing than security testing, even when one can simply combine DAST tools with their QA process and eliminate most of the low-hanging fruits.

According to Cybersecurity Insiders, the United States stands as the top country that was hit by notorious traffic related to web applications. The percentage is 66%, followed by Brazil & Germany at 5% and the United Kingdom at 3%.

Traditionally, many companies are accustomed to a Secure Software Development Life Cycle (SDLC), which is a series of steps followed to provide a framework backed by proper analysis, design, implementation, and maintenance. After developing and just before deploying the application live into the market, many companies realize the security loopholes and opt for a vulnerability assessment and penetration testing, traditionally known as VAPT, to find the security vulnerabilities present in the software.

Then there are the static analysis security testing (SAST) tools that companies use to find the patterns of pre-defined vulnerabilities in the source code and eliminate them. Dynamic Analysis Security Testing (DAST) tools are used to find vulnerabilities in applications using methods of crawling and fuzzing. Most companies do not know the architecture of applications that they own and this gives hackers the advantage of finding loopholes in applications that are unknown to them. There is also Interactive Application Security Testing (IAST) which is also called the Glass Box Testing. In this approach, IAST runs as an agent that is allowed to collect and analyze event data from running applications. This data will help you detect software flaws that SAST and DAST scanners miss out on.

According to a recent survey, the cost of fixing a security bug is only 10$ when it is identified at the analysis and requirement stage, whereas if it is identified in the deployment stage, then there are instances of changing the complete architecture of the application which results in higher costs of 2000$ or more. It’s high time we turn the tables and introduce security in the initial stages of secure SDLC and continue to induce in every phase.

So How does the Secure SDLC Work?

Start telling your developers to write secure code

Even though you have the best SOC systems in place to defend against hackers, they’ll be of no use if your developers choose to write a mechanism that stores passwords in plain text instead of Hash codes.  SDLC begins with the training of your developers about basic security coding practices such as restricting the access of the user for a payment application after 5 unsuccessful attempts, validating the input from suspicious data sources etc. It is advisable to have a minimum of 3–4 training sessions in a year on security awareness for your employees, along with a special training on secure coding practices for the developers.

Define security requirements at the planning stage

Identify and document the security requirements right at the initial stage of the development lifecycle. Once the technology, framework and, languages have been decided, train your developers to identify vulnerabilities that the particular technology is susceptible to and eliminate them right away.

Design and Architecture review

In this stage, once your architects and designers confirm the hardware and systems that were going to be used in the development process, perform a threat modeling to understand how each component talk to each other and identify the vulnerabilities at that stage. It will help you to apply a structured approach to threat scenarios to the design and lower the risks.

Coding and Development phase

During the coding and development phase of a Secure Software Development Life Cycle (Secure SDLC), developers integrate security through practices such as adhering to secure coding standards, performing peer reviews, and utilizing automated static and dynamic analysis tools to identify vulnerabilities. Threat modeling and defining security requirements guide the secure design of the software, while continuous integration (CI) pipelines incorporate automated security testing. Secure configuration management ensures the development environment is protected, and ongoing training keeps developers updated on the latest security practices. This holistic approach ensures that security is embedded throughout the development process, reducing risks and enhancing the software’s security posture.

Testing Phase

This is the most favorite phase of every development cycle; the functional testers work for smoke test cases and help find functionality bugs and report them to developers. They first argue that it’s not a bug but a functionality error and then close it. In this phase, it’s better to think like a hacker and add abuse test cases that attackers use to get the data or systems that they try to get into. Once you understand the situation from a hacker’s perspective, you will be able to put proper mitigation in place. It’s a boon for testers that various abuse test cases can be scripted and integrated along with QA testing save a lot of time and man-hours. One of the best practices is to perform the penetration testing manually to find the business logic vulnerabilities present in a system. Combining this practice with DAST tools will help you find the exploitable vulnerabilities such as SQL Injection, Cross-site scripting, remote code execution, session management issues, URL redirections etc. Once the vulnerabilities have been identified it will be easier to fix them as the application would still be in the pre-production stage.

Deployment review

You might be using the best cloud service provider in the market such as Amazon AWS cloud, Microsoft Azure or Google Cloud but you have to read between the lines. These private cloud service providers take care of the perimeter security of their cloud network but the security of the applications inside the cloud is the responsibility of the application owner. If the deployment of the application is not secured and has incorrect configurations, it will result in sensitive data leakages and open vulnerabilities despite security testing from the Big 4. Performing a configuration review for that particular cloud and doing an external pen-testing on all the cloud instances will help you sanitize the cloud.

All the activities mentioned above are ways to instill a security mindset in the employees and induce the security into every phase of application development so that the company can come up with more robust products with minimal vulnerabilities. “Prevention is better than cure” and Secure SDLC is the best way to go about it.

About the author:

Sairaj Mahesh is working as a Cyber Security Evolutionist in WeSecureApp, a New Age Cyber Security Company. He understands the pain points of information security of their clients and designs specific solutions ranging from Penetration testing of the Web & Mobile Applications, Cloud, Infrastructure & Networks to perform a full-fledged Red team Assessment vs Blue team assessment activity in any organization. He works with their technical team who are a combination of experienced, certified ethical hackers and Bug Bounty hunters. His solutions include companies migrating from SDLC to Secure SDLC and adding automation to reduce the cost of security testing over a period of time.

Schedule a demo with WeSecureApp : Talk to Our Delivery Head