Shift Left Vs. Shift Right | DevOps Connect: DevSecOps 2023

Okay. Um, good day everyone. My name is Angela.

I am a DevOps engineer at Academy at L L C. I'm from Nigeria, and I am so excited to be here today, um, speaking at a stage. And, um, sometime, uh, in September I attended my first ever text drunk event, and it was really, really awesome and fast forward.

So now I am here in this stage, uh, talking about, uh, one of my most favorite topics in security shifts left. And, uh, I think I, I feel really honored and privileged to be here today with you or some people talking about software applications, talking about security, talking about, uh, uh, trendy issues. And that means a whole lot to me.

So for everyone out there, especially, uh, to people who are starting out with implementing security in their development process, this is me cheering you guys up and then asking us and encouraging us to take security seriously as much as we can. So together we are looking at building, um, a more secure application, a better software for our users out there and for ourselves too, and for our organizations. So, um, talking about the, uh, topic for today, so shift left and shift rights and what they are, what we gain or what we aim to achieve at the end of the day, uh, uh, while implementing this software development process.

So, um, security is an integral part of every application. So the quality of security implemented in your application is as good as the quality of the application itself. So I know organizations can't risk security breaches.

There are a lot of issues that come when an application is vulnerable. You are talking about, um, loss or theft of data. You're talking about issues with money, uh, judicial litigations.

You are, you are talking about, um, uh, you are talking about system shutdown. You are talking about a lot of, uh, issues that would come. The process of disaster recovery and all those stuff can actually hamper the application and hamper the organization and their development process.

And I don't, I know that no organization would want to risk that. So, uh, uh, uh, security is, is as important. And then the way this, uh, security is implemented, it's actually the topic I am here to discuss today, and that is shift left.

So, um, shift left is a software development process, uh, uh, on approach that seek to identify, uh, vulnerabilities and address these vulnerabilities only on, uh, the software development process. So, uh, by, uh, uh, when you talk about shift left, you're actually talking about shifting security testing left. And by left you mean at the earlie stage of the software development lifecycle.

So, uh, if you have nine stages in your software development lifecycle, you have seven stages. You have only one stage, you have two stages. There should be security testing at each of these stages in the software development lifecycle.

So there is security testing at the planning stage. There is security testing at the coding stage. There is security testing at the build stage.

There is security testing at the staging area. Perhaps there is security testing, not the deployment, even post deployments in production. So each of these stages, there should be security implementation within each stages.

So against the, uh, uh, traditional software development process that's, uh, leaves security perhaps during the overall testing stage, when you run your unique test, you run your integration test, you run security. So shift left is actually an opposite of that kind of software development process. So, um, uh, uh, the issue is not just about shift left.

So why, what is the benefits? There are a lot of software development processes out there. So why embrace shift left?

And now? The first reason why the first benefits or the most important reason why shift security left is important is early identification and mitigation of security vulner vulnerabilities. So when, uh, uh, this security issues, perhaps there is no proper implementation of access control or whatever in the, uh, uh, uh, in any stage, then you spot, uh, through security testing at that stage, you can identify this vulner and fix it immediately before moving to the next stage in the software development life cycle.

So, um, another reason or another important key important of shift clubs is, uh, enhances collaboration between development and security teams. So in most robust organizations where they have, uh, robust teams of developers and teams of security doing their different things and running their different, uh, uh, uh, uh, processes within the organization. So most likely, uh, these security teams and the development teams are different teams.

And one of the things that would bring them together to work as one team is shift lift. So let's take for instance, you are implementing a new feature in an application or developing a whole new application. So, uh, uh, developers, uh, are done with their codes.

And then these codes passe through security testing from the security team, and security team gives their, um, their recommendation and suggests possible ways this security vulnerabilities found within the code base. Code base can, can be, uh, mitigated. So this brings this two team by shift net, these two teams can come in sync to become one, to achieve a better purpose for the organization.

So number three is that it helps to improve the overall quality of the software being developed. So, uh, uh, uh, an application that is less vulnerable to attackers or that has less security loopholes can actually be called a quality organization and a quality application. Because, because the users can, can have, uh, uh, when an application is, is secure, the quality and the market value increases, people can actually trust these products.

They can buy it, they can use it, and they can be confident that they have, uh, a better or a quality application with that particular application. So, uh, number, uh, uh, for is that it helps organization comply with industry and government regulations. So, uh, uh, um, uh, security regulations like the, uh, missed framework, the P C I dss, the, uh, ISO 27,001, and a lot of other, uh, uh, security regulations out there for organizations to follow through shift left, uh, uh, organization can actually show that their serious suite implementing security in their software or in their, in their software development lifecycle or in the organization itself.

So also lastly, it's increases customer confidence. Personally, I would always patronize applications that, that are secure or unknown to be secure. So no one, no one would go after an application that is vulnerable or has a lot of security loopholes.

They're considering their data, their information and everything about them. So customers are always very confident and very, very particular about applications that are, uh, uh, that are secure apart from the user interface, the awesome beauty of this application, security is as important as that user interface, as and as whatever, uh, feature the application has. So, um, the next, uh, thing, uh, about shift left is the implementation.

So shift left is, is awesome, it's beautiful, but how can people implement, uh, uh, shift left in their organizations? And what are the best practices? So, uh, you're talking about, uh, uh, first is conducting trade modeling.

So there applications, or each application or each vulnerabilities have the potentials to come to an application. And then when conducting TRE modeling, you need to, uh, uh, know the potential vulnerabilities that can come to any application and, uh, how to mitigate them. So, after you've conducted TRE modeling is also good to define security requirements.

So know the security requirements for each of the stages in your software development lifecycle, and then follow it of judici, uh, judiciously. So, uh, uh, integrate security and dev team together. So it's called a DevSecOps approach.

So when this two team can come together, you can ensure that you've already started or, or you on your way to start practicing shift security lift within your organization. So use secure coding practices. Uh, developers can actually, uh, implement secure, uh, coding design in their, uh, uh, uh, coding stage.

And then, uh, other approaches they can implement, um, uh, security approaches like, uh, uh, imput validation, uh, access control, error handling, and other approaches that that can integrate during the coding stage. So with this, you can be sure that the application that is being developed is as secure as the application that, uh, is as secure as you want it to be. So, uh, another one is integr security testing into the development process.

So there should be security testing as it has been mapped out in the security requirements. In each of these, uh, uh, stages, there should be security testing, static, uh, uh, uh, code analysis, dynamic testing, uh, uh, runtime application testing, penetration testing, vulnerability scanning. Each of these, uh, uh, uh, method of application testing have, uh, different, uh, uh, uh, stages where they can be implemented.

So another one is using automation to, so automation to help security testing go faster, and then within it of human errors. So you can be sure that, uh, to a great extent, the results from this, uh, automated tools can help you in mitigating security that has been, uh, founded at any stage of the application. So, conduct sec, uh, regular security audits.

So with security auditing, if there is any security vulnerabilities, uh, vulnerabilities that may have been passed in any of those earlier stages. So with audits, you can actually find it out and mitigate it. So lastly, the, uh, backbone of every application is the, are the developers.

So they're the people who are, uh, going to set up these codes that would, uh, uh, form this, uh, application. So educating, uh, the developers on security is as important as anything. So coding with security in mind would help, uh, uh, shorten the stages of security testing.

So, and this, with this, uh, uh, it'll be easier to implement, uh, and, uh, uh, complete or a, a whole security into an application. So, um, eh, challenges and solution in shift left implementation. So most times, stock is cheap.

It's not always easy to, to implement this. Perhaps, uh, some organizations will be talking, thinking about implementing shift left bots. Other challenges that are inherent in the organization may actually affect this process.

So if, uh, an organization is finding it difficult to, or the developers are finding it difficult to implement security, continuous education of these developers and then implement, uh, collaborating, these, uh, these, uh, developers with the security team can actually help them understand the need for security in the application they are building. So, lack of time and resources is also a challenge when implementing Shift left. So you have to prioritize security and if the resources or whatever, or if the time you feel, yes, checking for security can take a lot of time.

You can just use automated tools, and these tools will help you fish out, uh, uh, security vulnerabilities in real time, and also help you with ideas on how you can, uh, uh, implement, uh, uh, mitigate them. So, lack of tools and resources, uh, security is as important as anything. And the, the, the, um, or the damage or the amount of money that may be lost in a security breach is so enormous.

And just the money or the, uh, uh, the funds that may be needed to implement security is just not less than 5% or even 3% of the amount of money you may lose in a security breach. So it's necessary to invest in security tools. So integration with existing process, some organizations or anyone out there may already have a process that works for them without security, but then it's always very good to, uh, uh, uh, embrace flexibility in our workflows and integrate security early on.

So now the, uh, uh, uh, opposites of shift left is shift rights. So there are two diff, uh, there are two, uh, software development approaches, but shift rights is talking about shifting, uh, shifting testing, perhaps not security testing, and the rights usually at the end of the development life cycle when applica an application must have been deployed. So it's very important, uh, the necessity of shift rights is improved performance, mostly testing for application, uh, performance, and then use.

So, uh, if you're, uh, seeking to implement shift rights, uh, you'll gain, uh, a better, uh, reliability for your software. Because of testing. This application in a live environment would help you to know how the users feel when they interact with this application.

So to give them, which is the number two of why shift rights a better user experience. And then when you are shifting rights, you, you can ensure that your application would get to the market faster. So whatever testing you are going to do would come when the application is already being used.

So from there, you can keep, you can continuously monitor the application and continuously improve in the, uh, uh, improve the quality of this application. So when you're talking about, when you're comparing Shift left and shift rights, you are talking about two approaches because Shift Left is talking more about security testing and the only stage and of the software development, why, um, shift rights is not focusing on, uh, a security testing per se, is just talking about the testing of this application for whatever, especially for user experience or the performance of this application in real time. So now with shift left, uh, you don't, uh, there is nothing or there is no connection between the behavior of this application.

And then, but then we shift rights. Security is not a priority. Most organizations will use shift rights to share the, uh, uh, security responsibilities between the, uh, uh, uh, the providers of the application and their customers.

So these approaches, these two approaches are good, but when you are talk, when you want to implement security, um, um, from the, a security point of view and from a diverse point of view, uh, shift left is the most important. But when you, you're talking about a customer experience or quality or user experience of the software shift, right, is way to go. So, um, this is the end of my slide anyway, and I've come to the end of my talk about shift left and shift ride, and I know people out there would be wanting to implement, uh, uh, shift left and shift ride security.

And then, uh, uh, it's, it's my advice and I'm chairing on everyone to take security seriously, especially as it has to do with the application. So, um, uh, thank you for giving me the opportunity to speak on this stage today, 1st of June, and, uh, it means a whole lot to me and my career. And that is it.

Uh, thank you. Thank you so much. Thanks.