When it comes to ShiftLeft, the most valuable feature is definitely its ease of use and cost-effectiveness. Previously, security professionals had to spend a lot of time and effort running around, asking people to fix issues in their products, architectures, code, and even networks.
With ShiftLeft, everything becomes robust and secure from within. Instead of relying on external measures like Web Application Firewalls (WAF) that are applied from the outside in, ShiftLeft takes a proactive approach. It helps prevent issues from arising in the first place, making it much easier for both security teams and developers. It's also cost-effective because you don't have to constantly go back, make changes to the code, and then push it again. Writing secure code from the start ensures that there are no vulnerabilities when it goes live. So, I would say the main features of ShiftLeft are its cost-effectiveness and ease of adaptability or use.
When it comes to areas of improvement for ShiftLeft, I believe it could benefit from greater support from senior management. It's important to have their involvement when it comes to architectural trainings and ensuring that teams submit their documents and architectures for review. This can be challenging in an agile environment where time constraints are often a factor. Therefore, having support from senior management is crucial in making it mandatory for teams to collaborate with the security team throughout the development process.
I have experience with ShiftLeft for almost eight years. It's a methodology that I introduced in one of the e-commerce companies in India. We started by asking developers to undergo security training, which was the first step in ShiftLeft. Then we implemented tools in the CI/CD pipeline, such as SAST and testing tools, to scan the code base or website while it is being developed and before it goes into production. So, it's been around eight years since I first implemented this concept in the context I was working in back then.
We are currently using ShiftLeft as part of our development process.
It is a stable solution. Once everything is properly set up with all the necessary components, ShiftLeft runs smoothly on autopilot mode. You don't have to worry about things going missing or not working at all. After the initial effort, ShiftLeft operates seamlessly.
Scaling ShiftLeft is quite straightforward. The only challenge lies in getting started with it.
It is not time-consuming to scale. You can consider training the developers, for example. If you have a large number of developers, you can record the training sessions and provide them digitally or conduct online classroom sessions. Alternatively, you can write scripts to scan your code for vulnerabilities. Once everything is in place, scalability is not an issue with ShiftLeft.
All the development teams, consisting of approximately 400 developers across different pods, currently use ShiftLeft. So I would say around 400 people in total.
ShiftLeft is not a product we have purchased from an external provider. It is an internally developed solution.
There is no need for a separate support team because the security team handles support. If anything breaks, people come to us and request assistance in fixing the pipeline. So we, the security team, always provide support.
The initial setup was very difficult. Implementing ShiftLeft into the existing pipeline or framework is a challenge, especially when there is no support from the management. It's tough to get anyone to listen or make changes to their development pipeline. So the initial steps are quite difficult.
However, once it is implemented, it greatly simplifies everyone's job. But it requires a one-time effort from you, other team members, including the DevOps and developers, as well as upper management. This is where the resistance usually comes from.
ShiftLeft is not a product; it's a methodology. It represents a way of approaching security. Let me give you an example. In a company, there are typically two ways to deal with security. The first approach is to treat it as an afterthought, meaning it is applied retrospectively once the software is already built. In this case, you would test the software, identify any bugs, and as a developer, fix them. This is one approach.
The second approach is called "shifting left," where security is integrated early on in the entire product development lifecycle. This involves tasks such as providing security training to developers, scanning the code base, conducting system testing in the CI/CD pipeline, and using tools like penetration testing tools or SaaS tools. This approach makes introducing security easier and more cost-effective compared to the first approach, where security is treated as icing on the caking (not to be taken literally but as an analogy).
In the first approach, security is an afterthought, while in the second approach, it is ingrained into the development process. It becomes an integral part of the process, leading to improved code security awareness among developers. This is what ShiftLeft represents.
I would highly recommend ShiftLeft. It greatly simplifies the job for both security professionals and developers. By identifying and fixing bugs earlier in the development lifecycle, it significantly reduces costs.
Personally, I would rate it a ten. In fact, I promote the ShiftLeft methodology to agile organizations because it saves them a lot of time.
