DevSecOps: The Next Wave in DevOps | DevOps Connect: DevSecOps 2023

Hello everyone. Thanks for joining today. Today I'll be talking on the DevSecOps, the inevitable view in the DevOps world.

Before we start talking about the DevSecOps, um, I'd like to talk about the modern software development. The way it has evolved. The waterfall model has lately been, uh, developed into the agile methodology.

Uh, the modern software development has lots of moving parts. The monthly yearly release cycle of a software have now reduced of 10 times in a day, getting released 10 times. The code is getting pushed into the build and the workflow triggers that pushes the code into your docker images and later gets deployed into the platform.

Like I said, uh, this dev, this modern software development, has accelerated the delivery of the software lifecycle, um, reaching to the market as quickly as possible, uh, gaining the trust among the customer. Uh, but as well as, uh, it has added the risk, uh, the security is capped as a second priority, and that's where we are seeing the rise in the ransomware attack and the breaches happening lately because security is not the first thing comes while developing the software. So, whose problem is the security?

Well, security is just not the problem. Limited to the security team. They are not the owner who are responsible for them.

Every engineer who are touching the code, who are uh, indirectly, um, part of the software development lifecycle should be accountable for the security, should develop the security mindset and should always go with the security as a first approach, uh, when you are thinking of any software development. So what are the advantages of, uh, shifting towards the left? Uh, while the graph clearly shows us that fixing the vulnerability and identify detecting as early as possible in the early development lifecycle is really helpful and very cost effective.

Rather, uh, getting re remediated at a later stages, uh, following this approach, this gonna save the one round of full regression testing that, uh, the QA have to go through for just testing the security bug. If the QA develop the security mindset, if they start detecting those security bug while they are testing the software, you can, um, mitigate most of the vulnerability as early as possible in their development lifecycle. Now, let me talk about what's the DevOps is.

Well, the DevOps, it is the union of the development operation. Um, as the name says, uh, the union of the people process and the tools that help us in continuously delivering the, the valuable software to our end user. It is not just a tool, but it is the concept of the faces that has like, like a plan code, build, test, release, deploy, operate, and monitor phases.

And when we talk about the dev socks, you had to just add the security layer within the DevOps, um, making sure, uh, the development operation security are uniformly working together in your development lifecycle, uh, with the DevOps and devs. Uh, the next terminology, which, uh, you might be hearing a lot is the C I C D. So what is the C I C D?

Uh, well, CI stands for continuous integration where, uh, continuously, uh, turns of the software code are getting produced by various contributors sitting across the globe, uh, just to build one single feature of a software. Uh, and the continuous delivery is taking all those codes, getting produced from a various environment and like building together and pushing to the testing and then later to the deployment stage. That's what the C I C D stands.

So if you see how the C I C D, the automation workflow looks like, um, this is how it's gonna look like, where in the CI you are constantly design, coding, building and testing your product, your features, and then sending for approval, and then it gets, uh, planned for release getting deployed. Then you do the maintenance on the production code. Um, and then again, the planning starts.

This is how the workflow in the DevOps C I C D, uh, looks like. Now, why we need the DevSecOps, uh, in this DevOps world. Well, the threat landscape, uh, changes as the technology evolves.

Um, modern software development have started, uh, using, developing more microservices. Uh, the on-prem solution now have moved to the SaaS solution where the organization are leveraging the various cloud provider like a W s Google Cloud Azures, uh, more use of the containers are happening, and for that reason, uh, this are all the threat tech vectors that adds up, open up that phase and, uh, give opportunity for, uh, hacker to exploit any vulnerabilities out there. For that reason, there is a need to have or start practicing the DevSecOps in the organization for, uh, addressing all the pressing challenges.

What lately, uh, we are seeing in the software development. So, like I said, uh, these are the few, uh, critical things, uh, that, um, emphasize on why DevSecOps is very important. Um, lately the engineering team has started leveraging the third party components library so that it saves the time and effort, resources in, and even the release cycle in producing the code.

There are tons of the open source library components out there. You can easily integrate and release, uh, your product in the market quickly. Uh, but that also comes with a risk of like, you know, what if there is some back door, some vulnerable, uh, libraries you are leveraging in your product, um, even accidentally, many times the junior developer or even the seasoned developer, uh, just, um, accidentally, they expose some secrets in the repo, and that's where it opens up, uh, an ex surface, uh, for outsider to exploit.

So there can be a, a, a sensitive data leakage happening from your, uh, source code repository. Um, lately the license issue is very common. Many if you are very unknown about what are the license risk lies.

Um, also if your base image of a docker is, uh, vulnerable, if the other microservices is leveraging that base image, the vulnerable, uh, automatically, the, the likelihood and the impact, um, radius will increase of using the vulnerable docker image at various places or at various product in your organization. Many times we have seen that, you know, there are the misconfiguration at the GitHub label or in the Kubernetes that lead to an exploit. And for all those reason, uh, there is a need to have a dev SecOps, which breaks the silo of development, security and the operation which forces everyone to work together, uh, infuse the security in this, um, C I C D pipeline.

And also many times, um, the vendor ask for the bill of the materials. So for that reason, also, uh, having the practices of the DevSecOps in your C I C D pipeline, uh, does helps, uh, in gaining the trust from the customers. So the criticality of having this DevSecOps, uh, are in a various sectors, especially in the healthcare government and in a financial sector with the healthcare where P H I, uh, information is very sensitive, and we all know that lately we have seen a ransomware attack happening.

Uh, our leakage of like, you know, the P H I, uh, data happening, the government financial sector are also primary attack vector target by Aner. So for that reason, DevSecOps, uh, has become, uh, go-to practice to ensure that application are secured in a modern development ecosystems. So if we say about how to add infused security in the whole process of the software development to achieve the secure development, um, life cycle, it starts with the people, uh, where like you need the buying, uh, influence leader to get influence of the security, uh, at the lower down, like top down, um, level where the emphasize of, uh, focus on shipping the secure products.

Uh, you can also develop the champions community. Tho those will be there to advocate, uh, will emphasize this security within that team, and also providing the targeted custom security education, uh, based upon your job role to the people. Uh, that's how you can develop the security mindset.

Um, when we talk about the processes to achieve the S S D L C, uh, you need to make sure that you are doing the design security assessment as early as possible during the design phase at the R F C, uh, doing, building the thread model, trying to identify the threat while the product is still in a very tive inceptive stage. Uh, that's where you can reduce the vulnerabilities. And also qa if they start developing, uh, if they start develop the security aspect along with the unit testing and the performance testing, that's where also they can add the value of detecting the secure bug as early as possible.

And obviously, um, human can't be everywhere. You can't scan through the million lines of the code and find the security bug for that reason. You have to rely on some automation and, uh, some security tools.

So you can always leverage some of the security tools which are out there in the market, like the infrastructure as a code scan that helps in any misconfiguration in your data form. Uh, Kubernetes files. Uh, also running the SAS and s e scan that will help in finding, uh, the vulnerabilities, uh, from your static code or like vulnerabilities from your third party libraries.

Um, also doing the secret management that will let you know to scrub some sensitive secrets, um, which are already, uh, hard coded in your code files. So these are the ways how you can infuse the security in every stages of your development lifecycle. And you can achieve a, uh, DevSecOps in your C I C D pipeline.

And this is, uh, bird view, uh, how it looks like, um, to first is to shift towards the lab where you are detecting, fixing your bug as early as possible, and then achieving that S S D L C by making sure you are addressing and uniting, uh, those people process and the tools, and obviously automating some of the security tasks through the DevSecOps. Um, uh, I'd like to talk about some real, uh, life, uh, consequences of not having or not mature enough DevSecOps, uh, with the organization. Uh, there was a breach in 2017 where the developer's private kit with the credential got exposed and through that, uh, credentials, uh, the ER was able to access to the sensitive information by logging into the cloud.

Uh, another interesting, which most of you guys are familiar was a solar rate attack discovered by the fire eye. The RAC itself took for nine months, and it was very hard to determine the impact on a dete detection. And for that reason, uh, it's ideal to practice a DevSecOps in your organization so that, uh, you can detect those vulnerability as early as possible and you can patch them immediately.

So, uh, this is a good snapshot I would like to share with everyone. This is developed by an nsa, uh, where it says, like, um, for developers, you are constantly building, keeping the security in mind, um, making sure the thread model is getting billed, and then the QA performs the testing. And also, uh, you have a few of your security tools and they did, uh, get your code getting scan at various stages in your development life cycles, and then how it's got delivered, deployed to the customer.

And also, like you are leveraging some tools to monitor, uh, if any security incident happening or not. Um, so this is like, you know, the iterative way of, uh, adding security in a common develop, uh, DevSecOps life lifecycle. And if we go into more deeper layer of, um, the software development lifecycle, and also in order to achieve the secure software development lifecycle, uh, these are the few references of what any organization can, uh, start thinking of implementing, adding security, um, in the each phases of the development lifecycle.

Like you can have your static, um, analyze source testing tool, either integrator in the id, uh, that will provide the feedback to the developers right away, or even on a pool request. Uh, you can also do an incremental SAS running during the come so that any net new findings are there. Uh, you can quickly detect, it doesn't have to go through the full depo scanning, uh, at the bill stage through the pipeline.

You can also hire your SA S C A running and, uh, there might be the question arising that why we need so many tools at various stages in the development lifecycle. Well, the reason is no one tool is sufficient. It's, uh, we always go with approach of defense in adapt, which is one of the secure coding based practices where if one control fail, at least we have enough protection through the another control.

So same way, uh, we don't want to lean, rely only on, uh, one tool, uh, for that reason. Um, we need, uh, various tools and like SAS and EA are good, but again, SAS is very known for, uh, more false positive and it can just do a static code testing. It's more like a white to, uh, white box testing.

And so for that to detect any run runtime vulnerabilities, we still need other tools like I asked, or a d which are more, um, dust is more like a black box testing what like the penetration tester, uh, performs where he doesn't have any knowledge of a source score and he tries to detect the vulnerability of exploit is possible or not. And for that reason, uh, there is a need to have the various tool at various stages of the development lifecycle. And few of the benefits of the DevSecOps, uh, in the today's business involvement is to mitigate the rising frequency of the cyber attacks, um, by implementing, uh, the security initiative as early as possible at various industry.

Uh, not just you will get the peace of mind or the harmony, but you're gonna gain the trust with your customers. Um, obviously, um, you will match your, your development lifecycle, shipping, more secure products, and also, uh, addressing de deviating. The vulnerability volume will be way low if you start focusing or having, uh, that security mind.

And like, you know, shifting towards the left will reduce your ous effort work in just spending the number of the sprint in just remediating the vulnerabilities. So for that reason, um, there are, um, DevOp is like must needed. Um, I'd like to talk about the recent adoption of the AI ml.

Um, we all know a M l help with the analyzing, uh, analyzing and also doing some prediction. Um, it relies on a model and for model, it needs a decent, uh, large amount of the data. Um, you can adopt, uh, the E I M L for your DevSecOps.

Um, lately, uh, it has helped in securing the application, um, and reducing the risk with the rapid, uh, software development lifecycle. So investing, um, your DevSecOps and adopting the E M L, uh, uh, is like, you know, one of, uh, important thing, uh, you need to think of doing it. Uh, still there is a few challenges, uh, in adopting the A M L is it needs to train the data, and so you need an, um, adequate data, otherwise you may get a wrong results.

Uh, many times in within the organization, the tech stack is different. There are various frameworks, so, um, maybe you won't be able to generate enough data that can help you in doing that analysis. Um, uh, this are the few challenges, but, uh, if you like, you know, do more research on for what products and for what process, you can adopt the E I M L in your, uh, DevSecOps.

Uh, I think it'll be a good, um, layer. It'll ease the work of your analyst of, uh, going through the terms of the vulnerabilities and you can better govern and, um, achieve the compliance, uh, with that adoption. So, um, um, I would like to talk about, um, many of you might be inspired of, um, how should I pivot into this DevSecOps engineer or, uh, as a fresher, fresh out of the college.

If you are thinking to explore, uh, the DevSecOps engineer position, um, I'd like to go through few of the key things that you need to keep in mind. Um, it's always good to have the software development background or like, you know, learn how to code, but it's not that mandatory. All you need is to just understand the basic scripting language like Python, Java, ruby, and these days, like, you know, even at the school, the, the elementary kids are also like learning the python.

So pick up, uh, either of those, one of the scripting languages, uh, understand, learn about the DevOps basic comps concept through the linking learning or through the other, uh, training, uh, videos which are available for free. And also learn about, uh, the pipeline implementation, the basic, how the JF uti and what are the other tools are available. Uh, it'll be good if you have the understanding.

Uh, it is the basic understandings about the vulnerabilities, like the cross-site script injection, uh, that may be helpful. Um, but trust me, it is a very demanding road. And also the salary is very liquid.

So, um, it would be good if someone is like, you know, in the dilemma of what engineer role to pursue, maybe think of, uh, becoming the DevSecOps engineer. Um, well, I just, I talk all about like the importance of the DevSecOps in the DevOps world. I'll also talk about the, some challenges.

Some failure can happen if you start practicing the DevSecOps, uh, with not like following certain processes and the standards. Um, uh, let's say, uh, if you just, uh, keep on adding all the tools in your build pipeline, not consolidating the tools, uh, from a less vendor, like, you know, adding all those wire, um, to manage all those tools, uh, it becomes very complex and difficult. Always try to first understand what are the processes the existing traditional way, followed by the DevOps engineer, by the software engineer.

Rather, just like, you know, start blocking the build that may, uh, create a chaotic situation, giving the very bad user experience to your software development team. And these are the couple of the challenges, uh, you may run into if you adopt the DevSecOps, uh, without like, you know, spending strategically, uh, thought through process, uh, for that and some of the DevSecOps challenges. Um, there are like a people challenges.

It's very hard to find the people, um, having this skill set. People not having the security mindset or even like, if you try to enforce, uh, this practices to the development team, they might consider you, uh, as a bump for their development cycle. They may think that, you know, you are unnecessary just delaying the release cycle by, uh, adding some security stages in their, uh, SDLC process.

Um, for practices, like I said, if you just keep on adding the number of the tools in a blocking mode, that may create a very bad user experience for an engineering team. Um, your approach should be, uh, to partner with the engineering team, making sure that, uh, they consider, they know that you know, you are the guardrails, uh, in their development lifecycle to make sure they are shipping a secure products. You are helping them paving the road for them to ship a secure, uh, product and not, uh, causing any disruption or delay, uh, in their existing workflow.

Um, that can be infrastructure challenges based on the type of the products, based on the technology stack, uh, for the products. So these are the few challenges which can, uh, be a bumper, uh, for you. Uh, if you start adopting, uh, DevSecOps, uh, again, uh, there can be a solution for each of those challenges is just you need to think through, you need to strategically, uh, at various spaces you have to start, um, adding, uh, practicing this, uh, DevSecOps in your traditional life cycles.

But it is at chewable and many organization have transform, transition into this DevSecOps and even smaller companies all are also adopting or having a dedicated DevSecOps engineer or a DevOps team, uh, who has, uh, the security mindset. So it is, uh, possible to you. Few tips, um, from my experience, um, is, uh, always be clear with the outcomes, uh, with your partner team, that's the engineering team.

They should not be surprised. So always try to understand, um, gain the trust from your tool, how accurate they are before you start breaking the build. Don't just create the gates of security into the workflow.

Uh, first establish a formal process, get the bind from the leadership, get the approval, do some dry run test, uh, start, uh, testing with like, you know, some minor release with a minor patch. And then you can slowly phase into, uh, business as usual state. You can automate, uh, this data curves, uh, workflow.

So this are the couple of the things to keep in mind. Don't just blindly enforce the sla. Always, uh, think through, uh, before you start and forcing the sla again, like the severity, uh, reported from the scanning tools, they are out of box, uh, from the rule pack.

So based on understanding some compensating controls out there in your organization, you can be flexible and lower down the severity and help your product team to make sure they are able to remediate those vulnerability within the sla. So these are the few things to keep in mind to build a strong, uh, partnership with your engineering team. At the end, I would like to, um, conclude, uh, saying, um, security, uh, should be a responsibility for everyone.

You should always think security at every time. Try to apply the DevSecOps, uh, to your people process and the products. And always choose, uh, the tools which are more reliable, uh, which are friendly to your developer, uh, which meets the expectation of your organization.

And try to adopt the A I M L if possible in your, uh, DevSecOps. Um, DevSecOps, uh, is the reverse, uh, nationalized way the organization handle the security. Uh, it helps in breaking the silo among the dev ops and the security and following the DevSecOps.

Uh, practicing by adding one additional layer in your continuous development and the operation is a go-to approach. Uh, that's a cycling process. The organization should develop or is developing a modern software and that will help you to reduce the risk and shipping more secure product, gaining the trust among the customers and maybe, uh, be a market leader.

Um, that's why desktop ops is a progress. You stay up that the organization need to consider to catch up with the fast digital transformation. Thank you for listening to me.