 Good morning, good evening, wherever you are in the world. My name is Saumya Upadhyaya, and today I'm going to talk about the need to rethink security within DevOps. With the large population of the world working remotely and digitally these days, the demand for digital and application content has increased significantly. As for a recent cybersecurity business report, developers are creating over 2 billion lines of code every single week. That means developers are building code a lot faster to generate a lot of customer value. Today we're here to understand whether security and security teams are able to keep up with this rapid pace of development. The pace of development is just one aspect of it. Security not being able to keep up is accelerated in a cloud-native world. The landscape in a cloud-native world gets very, very complicated. As you can see, the deployment packages in a cloud-native world get smaller, as opposed to a large monolithic application in the past. They are packaged as containers. Developed in various different languages, there are multiple entry and exit points to the application. As opposed to in a traditional application, there could be just one entry or one exit point. So all this means that the software development team is moving much faster as they're adopting some of these cloud-native technologies. With this changing landscape, how can application security keep up by using tools that were built for the way software was developed about 10 years ago? If we analyze the breaches over the last few years, most, if not all, security breaches were because of misconfigured applications and not because of the cloud-native provider itself. The security in your organization is only as strong as your weakest link. Now that we've established that security is one of the largest challenges organizations are facing when it comes to application development, let's take a look at the ground reality. Even basic application security is hard and we are in the middle of a cybersecurity crisis. Traditional application security tools were built 10 years or more ago before the modern software development methodologies like DevOps with daily deploy came into play. Typically, these old security technologies are retrofitted to meet today's applications and cloud-native technologies. They've integrated too late pretty much after the development process, often detecting too many security issues, too late in the cycle when there is very little time to fix. Current security tools are great, they provide a lot of depth, but they're too complex for a developer to own and use without a security teams intervention. The number of developers far outweigh the number of security team professionals and this dependency can be a blocker to your security. Current tools also require integration of tools and technology and processes. The security industry is trying to adapt, trying to get into the SVLC, but we need to go beyond a simple shift left by just giving the developers a light static application testing in their ID. Security is all about empowering the developers. The teams adopting DevOps have optimized people, processes, as well as technologies for being able to develop faster in a more iterative manner. Established security tools were intended to fit at the end of the SDLC. Are we trying to fit a square peg into a round hole of DevOps? What can we do to change the odds? Let's take a look at the traditional application security workflow. With these tools, dynamic application testing could only be done near the end of the SDLC because it required a working application to test. Individual developers' work was already merged into the master and the developer would have context switched to something else. And these tests would be actually run in a QA test environment because DAST occurs so late in the life cycle. Interactive application security testing was gone. By instrumenting the application, the app could automatically be tested for security vulnerabilities while QA tests that. As you can see, security in such a scenario at the end of the development cycle where the developer has already merged the code and moved on to the next context that they have is not a great position to be in because any time a security issue is now found, you need to context-switch the developer back here. You need to identify the right developer as well. Most organizations have adopted DevOps on a need basis based on specific problems that they have to solve. For example, if they had a source control problem, they would bring in a tool to fix that source control problem. If they have a code review problem, they would bring in a tool to fix that. So over time, because of bringing in tools at various points in time, the landscape has evolved into this Frankenstein model which requires many people to create, manage, and maintain the integration itself. Many DevOps tool chains only reinforce the silos that you are trying to break in the name of DevOps. Instead of teams being able to collaborate together, these different tools actually put them in various different silos. And when you layer security and compliance on top of it, it compounds the problem even further. Individual vendors offer specific point products for each security testing, for static testing, dynamic testing, and so on. Each has its own license cost and integration requirements. And each will have a separate dashboard, a separate tool to create a dashboard that brings all of these products together. When it comes to security, the hard truth is this, that there will always be more developers than security personnel. So you really need to empower your developers so that they can take in a lot more tasks than the security people. So what do we need, what do we really have to do to ensure security works, while also making sure that the software development velocity is in place? So often we get focused on one specific aspect of security that we go very, very deep into those protections and leave a lot of other areas open. Are you using the very, very powerful scanner for your mission critical app and either not scanning others or leaving applications out in the open where hackers can come in and hack? Maybe not scanning a third party code because you expect it's already so widely in use. It's probably, it probably does not have any vulnerabilities but think again, think of Apache's strategy. By integrating security only at the end of the development cycle, the risk that you face is that you may encounter 10,000 vulnerabilities at the end. What are the choices you would need to make at this point? It's too late, so you might want to just accept the risk and move forward or you would want to fix it and then delay the release. What's really required is that we test early and we test often. So that the developers who are working on the code identify the vulnerability as soon as it happens but have the opportunity to fix it before it actually moves on to their desk and they context switch to their next activity. The cost of fixing the bug is six times more when it is detected later in the cycle in implementation and about 100 times more if it is detected after the deployment. The later in the cycle that we are pushing out a security issue to be fixed, the time taken is much, much higher. Often it is too late and there is an organizational pressure to either push it into production or delay the release. I'll asking you to make compromises that you would not have made if you had fixed it earlier. So it's time to solve the problem a lot differently. Security needs to be thought of more as an outcome and part of your process rather than a separate tool and department. So in an ideal world, security will be part of your developer's workflow. As soon as the developer commits the code, the CI pipeline will run with various builds and tests, including the security tests. The developer should be able to visualize the vulnerabilities they have introduced right within their pipeline. They need to determine whether this needs to be fixed or not. There's a new issue for the ones that need to be fixed and dismiss the ones that they don't want to fix. At the end of the dev cycle, the security person rather than going through all of the vulnerabilities will now only look at the vulnerabilities that have been dismissed as exceptions. So they will try to make sure that developers have not dismissed something that should have been fixed and so on. This makes the security teams a lot more scalable. With GitLab, all of these tests are automated into every single merge request that the developer is coming to. You no longer need to choose between risk, cost and agility. Because it is one single tool for the SDLC, you can use it on every single code commit. All of your tests, including your security tests, are run automatically. It also creates what we call a review app. So dynamic testing can be run on this review app as well, very much early in the software development life cycle. Also, there is no need to buy separate single solution tools. If you already have a robust static application and dynamic application security testing tool, you can reduce your cost of those tools by using them sparingly while using GitLab for every single code commit as well. In an earlier slide, we said that test before the code is merged. What does this actually mean? The countable developer sees the results immediately of every single change that they've made. Vulnerabilities and licences that they have introduced are shown as a part of their natural flow itself. They can see everything that has passed, and if it has not, they have the information that they need to remediate it if they want to. With GitLab, like we said, a review app is created at the end of the CI pipeline. The developer can see and test the working application and also run a dynamic application security test for the review app itself. They can quickly iterate and resolve vulnerabilities much before the code actually leaves their disk. One of the things we frequently hear from customers is that they have already invested in security. Well, that's great. These tools are great and provide a lot of depth, which can be used at the end of the development cycle as it is required. We like to compare this with the analogy of a mobile phone camera and an SLR camera. Of course, the SLR camera is great and it has its specific use cases. For example, if you're doing wildlife photography or landscape photography, you might want to still use an SLR because the quality of a phone camera is not great. But 95% of the use cases of photos that are taken are on a phone or of portraits to record a memory, to share a memory, without really requiring to transfer it to a separate device. You get 80 to 90% of the results compared to an SLR camera, but the convenience completely beats carrying around a bulky SLR camera. Similarly, in the case of security embedded within the DevOps processes, it's lightweight. It's part of your process. It's also contextual for the developer who can fix the issues before switching on to another class. That's the benefit of including security as a part of your development process, DevOps process, the simplicity and the integration. So GitLab automate security testing to empower the developer by bringing security right within the developer CI CD pipeline. Let's see how we do it. You can define a CI CD pipeline that runs for every single code come out made by the developer. In this case, in addition to the build code, quality, unit testing, we also included container scanning, dependency scanning, static application security testing, license compliance and dynamic application security testing. As mentioned earlier, GitLab creates a fully functional review app that can be used to test the changes that are made to the code. To run a dynamic application security testing before the code even leaves the developer's hands, before the code is merged into the master plan. The merge request is typically a central place of collaboration and results in GitLab. It contains all of the security scanned results in one place. Peers who are reviewers can review the changes, comment, collaborate with one or more developers and everything is recorded from an audit and compliance contribution. When the merge request is ready to merge into master, one or more approvers can be configured to merge the code, leaving the trace for auditability. The security reports itself can be drilled down to identify vulnerabilities as well as the severity of the vulnerabilities and then the developer can take action on it. For each vulnerability, the developer can dismiss the vulnerability or create a new issue right within their pipeline workloads. This level of integration is only possible because GitLab is a single application that can be used for the entire DevOps lifecycle. As we mentioned before, a security person can only then look at an overview by exception. They can drill down into the dismissed vulnerabilities and identify the ones that actually need to be placed. They can also visualize overtime trends of the security one. As per a CSO online stock cybersecurity report, 69% of breaches involve vulnerabilities where there was a patch already available but it was not applied. With this, we are trying to automate that by identifying the availability of a patch and automating the application of the patch as well. So GitLab is a single application that covers the end-to-end DevOps lifecycle, from planning to monitoring and defend. So, are we all breadth and no depth? That's not true at all. Apart from being one of the most widely-accepted Git repository management systems, Forrestal ranked our CI capabilities as a leader in that 2019 wave before. We've been able to do that by leveraging the power of convention of our user base, best practices from thousands of organizations being open source at the core so that everybody can contribute, releasing every month on the 22nd and building on open source technologies itself. We're also proud to be recognized amongst 11 vendors that have been placed in the Gartner Magic Quadrant for application security testing. We've been placed in the niche quadrant. We are thrilled with this placement as it is our first time being recognized for security in the Gartner Magic Quadrant. We think this is a validation of a strategy of shifting security left because our focus is to empower the developer and find and fix as much as possible as they are iterating on the project. As they're iterating on the port itself. To enhance our capabilities around first testing and improve our security capabilities, we've recently announced the acquisition of two security companies, Fuzzit and Peach Tech. Fuzzing finds unknown vulnerabilities that are missed by traditional application security testing and these acquisitions help us to fill that gap in our current security portfolio. Application security testing is so much more than scanning. It's more about what you scan, when you scan and what you do about the findings. GitLab helps you identify and fix your vulnerabilities and dependencies earlier in the application development life cycle. Like we've said throughout this presentation security is really a process. A research by ESG research of 372 cybersecurity professionals shows that security teams are constantly in firefighting mode. They're always addressing high priority and emergency issues. Hence they're not able to spend enough time on strategy and process improvements when it comes to security. They find it extremely hard to keep up with new hosts, new applications and users with the traditional tools that security tools that they have. And a lot of their processes are manual which is causing a lot of employee dissatisfaction. The research also shows that developers and security professionals are stuck in a rut leading to a lot of employee dissatisfaction. To summarize, security and compliance is all about process and outcome. You have to plan adequately for failure and adapt your application for resilience. This means that you need to make sure your basic security and compliance hygiene is in place. You're not leaving any unprotected passwords, unprotected databases. Out in the open, you have policies for various regulations and so on. Once you've done your basic security hygiene, you have to monitor and detect any issues and adapt accordingly. Manual processes have to be done away with and standardization and automation should help create a repeatable process that helps to improve continuously your development lifecycle. GitLab is trusted by a number of organizations in the enterprise space to automate their end-to-end dev sec and ops workflow. Some of the key reasons why these enterprises trust us in addition to all of the things that we spoke about was that we innovate rapidly. We release every single month on the 22nd of the month for over 100 plus months consecutively. This means that we're able to iterate fast, get feedback fast and pivot fast based on customer requirements. We're an open core company. We have tons of community contributions that get included in our product every single month. Hence, we're able to iterate a lot faster. We're also an open company. Unlike a lot of vendors, our roadmaps are all public. We openly talk about our feature maturity where we have to improve so that customers have an idea about our focus areas at any point in time. This makes us a trusted advisor for most of our enterprise customers. I hope you found this session informative. That's all I have for today. Thank you very much.