 Hi everyone. Welcome to today's webinar. My name is Peter Huynh and I'm the manager for Field Marketing in APAC at GitLab. Today we're presenting on DevSecOps, the what, the why and the how by SAMA. Senior Solutions Architect at GitLab. Just a little bit of housekeeping before we get started. This webinar is being recorded. The presentation and slides will be emailed to you after the webinar has finished. If you have any questions during the presentation, please feel free to type your questions in the question box in your Zoom control panel. I'll bring them up during the presentation and we'll also have some time towards the end of the webinar for questions. Now, without further ado, I'd like to introduce you to today's presenter, SAMA ACUB, is a certified cloud architect with over 20 years of experience in transforming business needs into workable technology solutions. SAMA has worked for many large organizations across the Asia-Pacific region, helping to establish their cloud-native practices, setting up efficient development life cycles and aligning their IT plans to the expected business outcomes. Over to you, SAMA. Oh, thank you very much. Please. Thank you, Tim. And yeah, welcome everybody. Yeah, as Pete said, thanks for the introduction. I'm SAMA ACUB. I'm currently a customer solution architect working for GitLab. Before GitLab, I have been working in the industry for almost 20 years. I went through multiple different positions as advisory architect with Pivotel, which is now VMware, as you all know. It's a cloud domain architect with NAB and a cloud-lead architect with Oracle and many other positions. So, this is the agenda for today. We'll start with what is DevSecOps? We'll try to dig a little bit deeper on the differences between DevOps and DevSecOps. Why do we need DevSecOps? What are the different ways of implementing DevSecOps based on what we have been exposed to from working with customers worldwide in GitLab? So, just to go back to the basics, where that DevOps started from. And you know what? I'm sure that most of you today would agree with me that it all started from the try to compress the cycle time, which makes really the difference between winner and loser, who reach or access the customer first, who present the product first in the market, who can expose to new markets faster. Also, how fast can I detect that my strategy, business slash IT strategy is working efficiently before making big investments in my environment? So, cutting that cycle time brought to the table the need for having an automated DevOps. So, in my try to define DevOps, I did that, what most of people would do, logically, went to Google, what's DevOps? And you know what? I got 66,300,000 results. So, I thought, okay, I'll take you guys through the 66,300,000 results to define DevOps. I'm just kidding. I can see your faces, but I hope you are smiling there. So, just the most common, let's say, attributes in most of the DevOps definitions are between the collaboration tools, culture, and processes to be able to deliver the value of fast to the customers, or to the end users, or to deliver my products fast to the market. So, let's remember this, having a very quick cycle, delivery cycle, using collaboration, so DevOps is not only tools, many people may be referred to DevOps as DevOps tool, it's collaboration, it's processes and culture, and tools, all working together. Right? So, cool. Most of the organizations today have successfully implemented fast DevOps cycle, I would say, maybe efficient DevOps cycle, to deliver value to their customers fast. But if we look at the popular cloud vulnerabilities today, most of them are coming from these client applications, known as misconfigurations or vulnerability applications. So, these are coming not only in modern applications, but also from legacy applications. But things have become even more difficult to control with the new applications. In other words, if you look today on microservices, it's all about APIs and APIs exposure. So, more surface of exposure for hackers. More like the security tools used today, and maybe you agree with me, most of them have been developed 10 plus years ago, at least. And we are bringing a modern development strategy or cycle, we're trying to marry that with security tools to achieve a secure delivery, right? The integration in our development cycle is usually coming late or like towards the end of the delivery process. So, to make today's session a bit interactive, let me start with this question, poll question. And please, Pete and Tim, help me gathering the results here. Has the focus, and this is please on the screens in front of you, just give me your idea. Has the focus on security and development changed over the past three months? Please feel free to give me the, like, has increased, yes, 84% coming, results coming, I'll give it 30 seconds before ending the poll, 62, 65, I'm looking for 90% reply. Okay, I'll give it another 30 seconds, I'm just, right, okay. 71% of you guys said it has changed, or it has increased even. And 40% remain the same. And you know what? This is very, very comparable to what I see with the customers I'm working with. And I absolutely don't blame, or I can't understand why this development security changed, because you know what? Regardless of the industry you are working on, you're working in modern electrical cars, you're working in financial sector, and even you're working in government or state operators, nobody is safe. And the attacks are coming regardless you are working on-prem or on the cloud. There is a myth here, and let's agree on, like, just try to work toward this art. I'm working on the cloud and I am safe, because the cloud provider is taking care of my security. This is a myth. This is not absolutely not true. Actually, most of the time if you are working on the cloud, you are more exposed to attack attacks than less exposed. And the first thing you sign on when you work with or you move to the cloud is security is your responsibility, Mr. Custom. Definitely on the application and configuration level. Yes, the tools are there, but it's your responsibility to manage that over all security and it's absolutely your responsibility to scan and make sure your code is secured. So, thanks to Pirates of the Caribbean, there will be almost, trust me, there will be always more of them than there are a few. There are more attackers than number of people you hire in your organization to do security controls and auditing and review. So, the idea here, and this is what I want all of us to agree on hopefully by the end of the session is we want to come to a point where security is a behavior. It is an integrated part in our DNA, in our development DNA. So, what's the reaction for that exposure? Let's solve for obvious cases. And the obvious case is, and this is like you look, this is a typical security or development life cycle. I'm a developer. I send my call to a repository. From there it goes through a continuous integration cycle, then continuous delivery and deploy to test staging environment and maybe production. And then I have these giant engines of security, auditing and review practices. So, I pass my code through these engines and I sit there waiting for the feedback on my tools, on my developed applications. Trust me, if from what I hear in the market, that waiting period goes anywhere from two hours to two weeks, waiting for that review to come back. Because nobody wants to be shown on the news next day as our friends in the previous slide. So, definitely people are doing their job perfectly and they are doing it to the maximum where every line of code needs to be reviewed. And every change needs to be reviewed. But guess what? The business is sitting there waiting for that new capability to be released to the market. The developer is sitting there, they already started working on the next cycle, then the next cycle, then the next cycle. And maybe in a couple of days to a week, they will get back and sometimes maybe even more, they will get back the results. And then the developer needs to go back and remember what he has changed on that day, on that change, on that push request and try to fix it. So, so basically what's happening there many times we feel that security is a square pig in around home. Because we are trying to integrate something very important, nobody did not that it is important, very vital in like, but it has been developed outside like the DevOps idea of having continuous delivery. We are trying to integrate that in our tools or in our DevOps lifecycle. You see my point, the point is, is not really in the, like there is nothing wrong with the security, absolutely this is a very required building block. But what's happening here is, instead of having a secure deep-seq ops, we end up with DevOps plus security. And there is a big difference between the two. Nobody wants to pay, put it a different way. Nobody likes to pay taxes, right? But having tool or security as an extra thing in the tool chain, we end up paying the tool chain tax. We end up having more integration points, more tools on the table. We need to train more users. And remember, the users you are talking about here are the developers most of the time, not the security architects. You need to switch between contexts because yes, that like the development is happening here. But remember, the security tools are already established in the organization here. And there is like, there is an integration. There is a gap between the two, which most of the time the security vendor will give you maybe some plugins to integrate with your development. To make it as it looks like, as if it is seamless, but there are still two different tools, right? And you need, of course, you need to administer these different tools. Can I go back to the polling and get your, look, I will bother you maybe another more time. So this will be a very interactive session, hopefully. So how often does the security fully review the code before it is sent to production? Like on every code change in every branch, on every code change in the master branch. And please, please give me, I'm not recording those who's answering what. So please give me your, based on your experience on the code. Once it is ready for production and post production. Another, I'll give it another 30 seconds. Okay. 67%. Come on. It's one day. Like, yeah, done, done, done, done. Usually I play music in the background, but if you don't want me to sing. Definitely. Yeah. Nobody wants me to. Excellent. Thank you very much. 46%. Which is expected. It is on the code. Once it is ready for production. This is a very, thank you. I really appreciate this. This is a very, very realistic. Results. Because I'll tell you something. It's running security itself, running this security engine is an expensive financially and effort and time once from all aspects. It is an expensive practice. Is it required? Absolutely. Yes. But it is an expensive practice. But you know what? Based on the NIC survey. It costs almost 30 times more. If it is in the production, if it is discovered in the production. Compared if it is discovered in the early stages of the development. Imagine, like, okay, you can see the picture. So let me hear. Just rehearse a little bit. We understand the value of the security. Sorry. The value of the DevOps. Yes. We understand why it is important. Yes. We understand that by having DevOps means you are being exposed more to the attacks. Yes. And like there are so many market news and articles on companies who have been exposed. So definitely yes. So we understand the value of having security in the cycle and integrated but that like the challenges of having that. Yes. The problem is now having another security engine means I am checking the box of having a secure call. But I am I'm checking the box of the key of the key purpose. We set up the DevOps practice, which is a quick delivery. You remember that 66 billion results. All of them agree on having quick delivery of value to the customers. So we are sort of unchecking that by adding another milestone, another bottleneck, another gateway in my code release cycle. So now it costs 30 times more. What happens when you find 10,000 vulnerabilities at the end of the software development type cycle? And trust me, 10,000 is not an exaggerated number. It's like and people who have been working in big enterprises. I have seen this number. They know that this number is like can be seen. So you now need to go back to the early stages and fix these 10,000 up, let's say up to 10,000 different vulnerabilities and let your developers work on them. Good luck convincing the management that you need extra time. So the point is what if you dealt with each one of them at the time where it was introduced? Yeah, sorry. So remember what if I, what if you dealt with each one of them at the time where it was introduced? Which means I'm a developer. I'm putting this piece of code. I'm able to run the scanning now. Not one type of scan, right? I'm talking, I will come to that, but I'm talking here about fully being able to know in my branch, in my changes that things are secured being able to fix them immediately before they are moving or managed into the master, master branch. You know what that means? Means that your master branch is always deployable to the production. And you're, you are able to deliver almost at the speed of the business requirements. So most important security product won't be a security product. I should have a poll question here to, to see you if you think or if you, if you agree with me, but I would assume yes, because this is from someone who's, who's deep into security and VMware. And the point is what he means that it's, it's all about practice. It's all about having real dev set ups, not their ops plus security. And, and we, we, I think now it's clear what's the difference between the two. I promise last one. Does accelerating development and delivery mean that you have to sacrifice quality or security? Do you agree with me? Yes, no. And yeah, Peter or Tim, can you bring up please the polling? Yeah. Thank you. Okay. Thank you. I think we are almost there. 46%. No. 48. 33. 77. 78. There are still 10 more guys who didn't vote. And then, then, then, then, then, then. So. And here we go. It's almost a tie between no. And it depends. And I totally agree with this. I'll tell you something. Usually when this DevOps cycle is happening. And, and you are sending more and more changes to the security department, especially in big enterprise organizations. You are talking here about things that start to be accumulated, to start to be accumulated at the security side. And here the business security, they have two options. Either, or actually three options, either which the business usually they don't take, either they hire far more people to be able to cover that cycle. But guess what? The more people you hire, the more releases coming, the more people you hire. So that will not happen, especially in this room. And like in what's happening today in the month. Second, the security, they have to lower their expectations or standards so that the code can be released to the production faster. I mean, I mean, they may say, okay, things under low to medium criticality. That's okay. I'll accept that for now. But first of all, classes that haven't been exposed much in the last two years. It's okay. I know there are vulnerabilities there, but I'll accept them because I don't have time to go back to that development team and make them choose or use different classes. Or the third option, the business has to lower, the business story has to lower their expectations by accepting that the code will not be delivered in a week. And if they need another two weeks to be able to release the code secured in the market. You see my phone. So just so you know, either you hire more people, which trust me, it will not happen. Or you hire or you lower, you lower your security standards, which is, I'll accept a bit, I would be more relaxed working with security teams in previously they tend, they don't tend to lower their standards. Trust me, they enjoy that power. Or the business have to accept the lower standards, lower expectations from the release. So what if we can scan the code every time? Remember, you told me before that most of the scanning is happening just before we go to the production. So what we want to do today, what if we can scan the code every time? What if we can bring that even to the development? What if we need, we can use fewer tools and have developing security and operations on the same page, and not have DevOps practice and security. And of course, make the auditors happy, which usually it's not an easy task. Most of the time, I'm sorry for people who have iPhone, most of the time I have Android phone. I used to have a DSLR camera, which I invested good amount of money in it. And when we used to go out before, used to, this COVID thing. If you still remember, we used to go out in cars, seeing places, taking photos that's in the past world. I used to have two tools with me, big one and the other mobile, each having their own, doing their own business and now then trying to integrate the output from the DSLR in the input of my mobile and sharing these photos and images with friends. Until to a point where my integrated tool, my integrated platform, which is this one, is able to provide me with an end solution from communication, from texting, from taking good quality pictures and share them with my friends. You know what I did? I sold my DSLR and there was a good amount of money. Because I feel that the value of this integrated platform is bringing me to the table is far more than having an extra 10,000 K, whatever, resolution in that camp. Now, in normal, normal, in normal DeepSecOps, you don't have, you don't have to ditch your current security engines, which are built for purpose. I'm not saying that at all. I'm just saying that this DevOps community, they need to have security as an integrated practice. It is an integrated part in their daily life. Trust me, simplicity and integration always wins. You want to pass that through that engine at the end. It's fine. But instead of having 10,000 vulnerabilities there, we'll end up with so much fewer number of vulnerabilities, which can be fixed easily by the developers who have been doing the developing. And by time, this tool will learn from the outputs from there. And most of that, you will end up having a completely stream output to the production. And this is what GitLab has been helping customers around the world to do. Shifting security lift and making it within where it fits most within the DevOps practice as an integrated practice inside the DeepSecOps. As you see here, we in GitLab provide the security capability to run on the feature branch, not only on the master branch. I'm not saying that you can run it on the master branch. And by doing that, I am a developer. I create a managed request. I do my changes in my branch. This is important. And you are doing the security as close as possible to my changes, basically as close as possible. I mean, once I push or commit my code to that feature branch, the review will happen there. The changes, I will be able to see the changes, or sorry, the outputs or the results from that review immediately there within the same minutes where I did my changes. And I will be able to fix that there. So instead of having, as you said in the previous poll, instead of having most of my scans all the way closer to the production where it is 30 times more expensive to have to fix the results, the findings, I'll bring them all the way to the developer side. And by doing that in the GitLab, we provide, and actually recently we even added one more, we provide container scanning on the developer next to the other tool. We provide static application security scanning. We provide dependency scan. We provide license compliance scanning. And we even go ahead and provide dynamic application security scanning, sorry, testing. Each one of these in the security world means a totally separate engine that I need to integrate with. In GitLab, they are all coming and become part of the cost of the developer tool chain, daily tool chain of the developer keys to the development kingdom. Right? And even recently, it has just been released yesterday, we have added the Puzz testing. So what does that mean? It means that I have a continuously, a continuous integrated real debt sec ops. Right? From I do the development, the new comments coming into the Git repo, the scanning and analyzing is happening there on my branch. I can see the outputs and I can mitigate the findings. I can protect them. I'll come back. I can protect them once they are deployed to the production and then that development life cycle continue. So do you want to have, once it is deployed to the production, let me go one, actually two steps back. Do you want to have another tool for in your existing environment for extra scanning here before you go to the production? Please be my guest and do that. But the point is we need to hear, we need it to be clear. It's about having security integrated in the DevOps cycle to make it a real debt, the sec ops cycle. So you did the SAS scanning. Oh, sorry. You did the security scanning on the other side. By the way, here it says on our roadmap, it's already on our production. It has just been released yesterday, the fastest. So this is from pre-release. Once it is released, we have sec ops visibility. We enable our customers to deploy web applications, firewall, container networking, security, and even content on our roadmap, container host security. So you can define your security policies and let GitLab deploy them to your environment, especially if you are working in a Kubernetes environment. So GitLab, and this is, many people know GitLab as the source code management or source code automation platform. GitLab means it's meant to have an end-to-end deep-sick ops platform that starts from creating an idea or what we call it an issue, whatever you want to name it, all the way through the agile project management capabilities, including the development, having security integrated. This is what I was trying to explain here and then deploy that to the production. So for people who like graphics, this is a real screenshot of a pipeline developed in GitLab. And as you can see, the security capabilities are integrated on the branch level with the security findings available for the developer to see them or to check on them. And I can choose, by default, GitLab can even automatically, what we call auto-devops, can even automatically integrate for you all the required scanning based on the code you are developing or the platform you are using for the development and do then the review and test. But let me stop here for a second and just highlight on the dynamic. People who have used dynamic application security testing before, they know that it has special requirements than all other development tools. And that's why usually this step is done on the production code because it requires a running version of my application. And most of the time, the license from whatever tool you are using is based on number of license of scans you do. And number of scans I mean, one page can have 10 links. These are 10 licenses count inside that page. In GitLab, this is all under one GitLab platform. And the solution is able, or the platform is able to provision for you a life instance of your application and then pass that output of that instance, sorry, a life instance of your application based on the changes you did in the branch. So this is important. I am again, remember, this is all a branch. I'm doing my changes on that branch. I've changed the color from orange, the background color from orange to green. I want to see how green looks. I don't want to integrate back into the master because in the master, still the program should show background as orange. I did my changes here. The application will be able to deploy a life code of my green newly changed background into a testing environment. And if it is working, if you are deploying against Kubernetes into a different namespace event, automatically provision, run the DAS solution, the dynamic testing there and even the POS testing there and then giving you the outputs. This is very important. So this is here, if you see in the right and the left side, this is the cycle I've been describing. Code commit, code changes. The developer is getting the outputs from the security scanning. The DAS is working. There is a review sample app and then deployment. These people here, the security team, with all my respect for the people on the call, but these people are most of the time, not absolutely not easy to satisfy. And they are most of the time suspicious of whatever is happening here. Their job actually is to be suspicious and their job is to be very careful on whatever the developers are releasing in this cycle. This is why in GitLab, we provide the security team with an end-to-end review of all the findings that are happening across all the developments. On the project level, on the group of projects level and even on the whole program or enterprise level. Even if the developer dismissed one finding here, the security team will be able to find that dismissed finding. So if I go back to slide number two, you remember in that 66 million finding, we agree that DevOps is all about releasing quickly using processes, tools and collaboration. And this is why in GitLab, the findings, users and the security architects, sorry, developers and the security architects and even within the development community, they can review and triage and commit and collaborate on these changes. Paired finding, actually down to the line of code. Not only that, they can also create, push that vulnerability finding to the beginning and create an issue based on that to add it to the backlog and of the DevOps cycle so that it will be handled. Let me hear a highlight very important thing. You find, you get your code. You pass it to the development, sorry, to the security. The security team have their findings. They pass the report back to the development. I have seen it many, many, many times. I'm sure it may be in your environment. That passback is done through Google form or Microsoft document. Then these findings either fixed, dismissed or lost in the cycle because remember, these are two different tools. And in GitLab, because it's one integrated cycle or platform, the findings can be transferred back and changed into an issue and be added to the backlog as a ticket to be fixed. This is the view I promised the security architects to provide and security auditors and end to interview of all the findings that happened in my security in your development environments across 30, 60, 90 days, across all the projects and you can filter based on the confidence report time severity. I think I don't like most of the security friends I know would be happy with that. Actually, this is a big, big issue. What's happening where it's not about the tool. Trust me. It's not about the tool. Most of the tools in the market are good. Most of them are excellent even. It's not about the tool. It's about what I'm scanning and how I'm using this. That's the scanning outputs. So at the end of my session, I don't want to take longer, but I just love to leave you with some lessons learned. Driving fast with DevOps and here driving, I mean it, driving like driving a car. Driving fast with DevOps means higher crash rates without proper security. Without proper seatbelt, it means higher engineers. Right? So just remember that God forbid nobody would have any accident, but that's real life. It is the sick ops, not the ops plus security. And please remember that there's a difference between the two. Next time you sit in a meeting and people say, we have the sick ops practice. Try to dig a bit deeper and see what do they really mean. Do they really mean DevOps cycle where developers are releasing code and then that output is done as securely or monitored and at the end of the security. Sorry, at the end of the release cycle. Developers need to have security available as part of, sorry, of their daily tools, daily tool change. I'm providing the developer with a development environment with deployment environment. I also need to provide them with security tools. The way in the security finding is as important and I would say it's more, most of the time it's more important than the what I'm scanning. Yes, the scanning result is important, but trust me, a very detailed scanning report, which by the way we provide in detail, a very detailed scanning report can become sort of users if it comes too late or if it is becoming a bottleneck in the release in achieving the business objectives. So the way is as important as the what I am scanning. As a compliment and thanks for your time today. This is the link and as Peter said in the beginning, we will share the slides. This is a book on, authored by a certified security personnel and get that. It's about 10 steps every season should take to secure next-gen free to download and we will pass you the links after the session. So please feel free to go through it. It has very valuable real life examples on customers who have done deep sec ops in a successful and unsuccessful way and what to look for when you implement healthy deep sec ops. What do we mean by the sec ops? I hope you found this helpful and yeah, I'm happy to take questions, Peter. Thanks so much. It was very insightful. We've got a number of questions. So first off, first questions. How do you deal with a situation when security guys are not well versed in language, in the language you are using? Perfect. Thank you very much. Thank you very much. This is a great question. This is where it becomes the standardization becomes very, very important and delivering the report in a language that the security and the developers understand becomes very, very important. I'll give you an example to the gentleman who asked. Assume you are doing Java scanning, right? And you are doing on SAS scanning or security scan, right? Now, the security team may not understand the Java vocabulary, I would say. But they would understand that there is a high critical finding from your Java code based on a package that was used or based on a vulnerability that was reported publicly and here's the link. So this is the value of having a common shared platform between the security and the DevOps and the development team where each will have their own dedicated view on what's happening. I hope that answers your question. Right. Next question is, what about SRE? Is it getting integrated as part of DevSecOps? Please share your thoughts. Absolutely. Absolutely. I'll tell you something. SRE is most of the time it's all about having different roles in the development or in the release cycle between development operations and fixes. Absolutely, yes. And evidence for that is in GitLab, we not only are doing the scanning continuously, we are also providing, and maybe I should have added that, we are also providing recommendations on the findings to a point where you can apply auto fixes to the back end of that code. This is one thing. The other thing is we enable our customers to train the tool based on their findings and acceptable finding and have their own customized, I would say, life cycle for implementation. Yeah, please. There's just a comment from Moe. He said, the SRE depends on your organization size and shape. Not everyone is Google, and therefore not everyone should go for the same model. Thanks for that comment. I can't agree more. I can't agree more. I can't agree. Thank you very much. This is very realistic input. Yes, I agree with you. Implementing SRE also on different, look, I have worked with organizations who have 2,000 developers and have worked with organizations with less than 20 developers. What you want to adopt from the SRE, it really depends on your requirements. And you don't want to adopt the practice, just for the practice, you want to see what's the value on having different roles. Yes. Great. Great question. What would be the, what would be good security tools to be part of DevOps and is SAS and that's mandatory. Okay. That's a very nice question. What it would be a good security tool? Look, I can't really tell what in your organization would be a good security tool, but because it really depends on what kind of development you are doing. For example, if you are not using containers at all, your scanning doesn't make any sense. Right. But SAS and that's, let me make it a general comment. These are the most common. And by most, I mean 99.9% of the organizations have them. If you are doing any kind of development. Right. Because you, the vulnerabilities in SAS, there are always vulnerabilities in SAS that you want to, you need to be aware of. And that's the requirement. The needs, sorry, the need for that was way back in time where we need, we used to have low, you know, remember that only load testing tools only or like, was that hacking testing tools? So I would say yes. If you are doing publicly available applications or web applications, then yes. If you are doing any kind of development using development tools or say yes, but the overall answer, what are the security tools? It really depends on your environment of what you are doing. Okay. Next question. How do you integrate the outcomes from DevSecOps into the wider enterprise security picture in a way that makes sense? Perfect. Perfect. Thank you very much. The direct answer, we provide, actually we slash the security vendors, the key players in the market, they provide as well integration plugins with GitLab. Right. Plus all the features I've talked about today and described are available through well-defined RIS APIs for, for, for integration. Right. Third, Webhooks are commonly, commonly used for integrating GitLab with external, I mean entities and, and please whoever asked the question, please feel free to approach me directly. I'm happy to run you through a demo where we integrated GitLab with external, external entities. Last thing in our GitLab integrations menu, you will find a very long list of a brief build integration capabilities with external applications. Maybe I would add one last one on Google. If you, if you, if you just Google GitLab security integration with external tools, I think the first or second link would be, will show you how to do like a pass that reports from GitLab to the security tools and vice-versa. Great. We've got about another five or six questions. So in general, we will fix most critical and high and sometimes medium security issues and then leave the lowest security issues for the next release as part of backlogs. Mostly this is how we work. Is this best practice? Okay. I think, I think whoever asked knows the answer. I think he knows, he knows the answer. Is this a best practice? I can't say yes. It's, it's not, I'll tell you something. Okay. Okay. Let me be fair here. It really depends on these findings at what are, what is that, what acceptable means in your industry. So, what is acceptable for financial is totally different than acceptable in retail than acceptable and like a normal home grown website. Right. So that's one thing. The other thing is. If you are moving these medium to low vulnerabilities to the next round, you are wearing the risk and cost of fixing them later. Remember fixing them like later in the cycle means it's would be more expensive to be fixed. Developers who develop them are not always there and they are not always, they don't always remember what they have changed. Third thing, you are taking a known risk to the production. So I can't make judgments here on what people are doing. I can't say this is bad, but to answer the question, is this the best like a best practice? I would say, I would say no, but further details are more than happy to set after the call if they are approached us and go through this cycle, these findings and help sitting up best practices for that for the demo. Great. Moving along to next question. I think DevSecOps needs to integrate with the rest of the stack as well because the stack integration is a major vulnerability. If there is vulnerability in the BIOS and it can be inherited in the application layer, will any of the DevSecOps effort make a difference? I'll thank whoever asked that question. Thank you very much because he highlighted a point, maybe I should have also highlighted during the call. The integration itself between DevObs and security is a vulnerability or attack point. So bringing security under the same tool means you are patching and maintaining less tools. Remember here, more tools, more integrations, more things to be patched and managed. Even the security tools themselves, they are tools by the end of the day. So what we are doing here, they are moving this capability inside the DevSecOps. It's still your option to choose which tool to change or which security scanning to run, but by the end of the day, no more integration required, which means this vulnerability and less attack service, no more individual patching and administration. It's just one tool and I'm sure that's always up to date and integrated. Yes, please. I'm going to wrap a couple of questions together. The questions, do we have a free trial to explore these DevSecOps features and then also what are the tools available by default within GitLab? Okay, excellent. The first one is easy. GitLab.com, you can register for 30 days trial and that includes the ultimate, the highest, and from there, yes, you can start using and experiencing the GitLab security offering. By the way, GitLab works exactly the same on-prem. I'll say, okay, exactly the same with Astric, okay, because there are some details which we can go through after, but with the same source code between on-prem and the SaaS offering. So just go GitLab.com. You can register there and start your 30 days free, I mean trial, plus you can approach us, Peter, Tim, on myself, and we are more than happy to help you set up trial of GitLab and go through your requirements and even help you like piloting these changes and tested in your environment. The second part, what are the security features? Let me wrap up with this. Static application security testing, dynamic application security testing, compliance testing, license scanning, first testing and dependency scan. And they are all available on, if you go on GitLab.com security, then you can see all of them. Hope that answers both questions. Yeah, so there's a couple of follow-up questions related to that. So does GitLab have an inbuilt security scan feature or does it depend on other tools like Fortify, AppScan for SaaS and Das and then also what are the security scans done as part of their ops cycle? Excellent, excellent. Thank you very much. So the first part, the second part of the first part is no, we are not depending on these tools. But for the SaaS scanning, and this is all documented on our SaaS scanning tool, we use open source tools to run most of our SaaS scanning, not any open source tools. These open source tools, most of them are highlighted and mentioned and to some certain extent recommended by the standard organizations for security scanning and vulnerability testing. And we maintain them and we provide the customer, keep the customer up to date with all the vulnerability databases. So this is for that one. What was the second part, sorry Peter? What are the security scans done as part of their ops cycle? Maybe I partially covered that. The security scans would do the static scanning, the dynamic scanning, the dependency scanning, the license scanning, compliance and fast testing scanning. Do you have to run all of them? No, it's your choice. Which one to run? Can they be dynamically even using the tool integrated? Absolutely yes. You can start within half an hour, sorry, within five minutes. You can build a new Mavin project and have all the security teachers running on your code. And yeah, I hope that answers the question. Okay. And do we have plug-ins to connect to commercial security products such as IBM AppScan and Veracode? Okay. It's a case by case. We have a lot of... I haven't worked on, to be honest, I haven't worked on the IBM tools. Okay. I'm happy to, if the gentleman who asked if he can reach out, I'm happy to dig into that question and see the integration part. As I said before, I never found it difficult to integrate with any security tool available at the customer side because we have all of them as integrated APIs. Just let me a little bit go one step back to the previous question. So I answered for the tools for SAS, for dependency scanning or other security scanning tools. We use, for some of them, we use our own security testing tools like GitLab or security testing tools like for dependency scanning, we use gymnasium for fast testing. We use the new solutions we acquired in GitLab. So it's a mix between open source and GitLab solutions, but all of them are supported through one business and integrated through GitLab. Okay. And how does the remediation recommendation look like in the UI? I wish I had yesterday maybe I removed that slide, but it's basically and especially for dependency scanning it is in the same dialogue as this one, right? If there is a remediation, I mean recommendation, it will show up here as a button or as a link and you can apply that directly to the source code. Especially for now, mainly it's supported for container and dependency scanning. For example, for container scanning if there are patches or upgrades that can be done to overcome or solve that vulnerability the recommendation, the button will be here and that can be like just click and apply that recommended remediation to the back end solution. Okay, just a couple more. So is Kubernetes overkill when we're a team of five people and are only running two apps? Look, before answering I'm a Kubernetes certified administrator. So I am a bit biased with the Kubernetes. It really depends on your organization requirements. I want to measure the Kubernetes efficiency based on number of people necessarily. I have seen organization with like two or three people still they have Kubernetes and it's adding big value. Look, I can't really say it is an overkill, no? I'm happy to have that discussion. Please, please approach us and I'm happy to have that like a casual discussion and to understand more of what you are trying to do. Does Kubernetes make people life easier and certain extent, yes? Does it complicate if it is misused, does it complicate people especially the developers life? Yes. How we can help in GitLab? I don't have the screenshot here but GitLab is an integrated can integrate out of the box with Kubernetes cluster and even you can use GitLab interface to create Kubernetes cluster in AWS and Google and deploy your application directly to that cluster without, I know, without opening that black screen which people may not really like. Great. Anyone? Yeah, we've just had a few people ask about hands-on sessions and workshops. These are in development at the moment. We do have a number of training elements on our website so you can go there and have a look at the videos on how to get set up. As I mentioned, we are looking to develop some hands-on labs or technical sessions to be able to work through these types of things. We're looking to do that on a quarterly basis so be on a lookout for that. And then also there was a question around a comparison in terms of our offering so obviously the free and the additional tiers. So we've got, I think it's a bit much to go through but we do have a page on our website in terms of the feature comparisons for all our tiers. So feel free to have a look at those. And I'll add these links to the chat. So that's the feature comparison and then we've got the training page as well. Great. So that's the last question. Thank you very much, Samar for presenting and thank you for everyone for joining in or tuning in. Hopefully that was insightful and valuable to you. Just a reminder that the slides or the presentation recording will be emailed to you within the next few days. Also, we're running our next webinar on September the 16th, which is around GitOps. So we hope to see you there. Thank you very much. Thank you. Thanks. Bye-bye.