Shift Left Security in SDLC

Today, I am going to talk about application security, so if you are not a software engineer, this blog may not be for you. I won’t be talking about code but it has a significant amount of technical jargon.

In the past few decades, the world has evolved into a digital age. This has significantly increased the threat against your identity, data and privacy . The guys carrying out these activities are commonly known as hackers and they use common forms like virus, ransomware, malware, etc. to execute. Similarly, these attacks can be on your Facebook profile, your Instagram or Twitter handle or your emails or laptops. I don’t want to scare you. All of these companies use state of the art technologies to help protect your data and identity. As an end users if you don’t understand how to use these tools the threat increases. For example, on a public computer, never save your password, delete your browsing history.

What I’m going to talk about today is how as a software engineer you should focus on security and not ignore it. Let’s look at three scenarios of a SDLC life cycle.

Why Shift Left?

Let’s imagine, a developer deploys a change in production within few hours, from the time code has been checked in the source control with no security checks in place. Later, in next few days there’s an attack and its revealed that that the code change introduced security vulnerability. Wow!! One security breach can make or break the reputation of the company/product which takes years to build.

After that, in second scenario, imagine, a developer executes all the steps as above and at the end there’s a manual step of running these security scans. It takes 4-5 days to get all scans done, analyzed and vulnerabilities remediated. Moreover, the cycle time which was few hours, became a week at a minimum, assuming remediation of vulnerabilities is quick. In conclusion, a team that fixed the bugs or rolled out new features in a matter of days now takes weeks if not months. Company reputation again tarnished.

Finally, imagine all security scans are running automatically as the developer is coding and giving insights into all vulnerabilities. They can remediate all the issues and check in the code at will with a confidence that their code is secure. Now, this code runs in production in next few hours like scenario #1. Hence, the cycle time remained comparable to scenario #1. Likewise, there was no impact on client experience as in scenario #2 and less rework for developers. Above all, we rolled out secure code. Company reputation is intact and trust increases. Loyalty increases. Revenue increases!

Which one out of the three scenarios would you like to see? Third one, right! This is what mature organizations call as DevSecOps model. Shifting left means getting feedback on your code as you are coding. The quicker it is, better it is for all stakeholders.

How to solve for this?

The faster feedback you can get as you code, better your code will be; better quality, more secure. There are multiple types of scans that can be ran to help improve security posture of the code, namely, SAST, DAST, Penetration Tests, etc. All of these scans look at different aspects of the code to give you a comprehensive insights into the security of your application. (I have included hyperlinks for you all to read about these scans if you need more information). There are various tools available for free in marketplace that allow you to implement these security scans. If you guys would like to know more about it please write in comments and I can write another blog about these tools or answer your questions.

In summary, I would like to highly encourage all the software engineers to take course on application security development, implement the tools to scan for your code or write your own tools. Let’s work together to make this world a better and safer place to live in!