 Compliance requires organizations to adopt processes that help them to adhere to regulatory and legal requirements. But frankly, that can be a pain. In essentials of building a compliance program with GitLab, Somya Upadaya will talk to us about how GitLab can make compliance management friendly, straightforward, and as frictionless as possible. Good morning. Good evening, wherever you are in the world. My name is Somya Upadaya and I'm a product marketing manager here at GitLab. Welcome to the GitLab virtual summit 2020 and today I'm going to walk you through the essentials of building a compliance program with GitLab. Software is eating the world, more so now with a large population of the world working digitally and remotely. The demand for digital and application content has increased significantly as per a recent cyber security business report, developers are creating two billion lines of code on a weekly basis. This means that developers are building code faster than ever to generate a lot of customer value. Let's take an example in telehealth, which seems to be the hottest sector at the moment. So IQRX in the United Kingdom was able to build a video chat application to be used by general practitioners for consultation in the span of a weekend. Now they're servicing over 35,000 consultations a day. This was in the back burner for at least four years, mired in concerns of risk and privacy for the company. In this case now, it became essential for their survival. Business survival here depends on being able to pivot fast and build fast. So today we're here to understand if compliance can really keep up with this rapid pace of development. There are a few challenges with today's compliance. Based on a Thomson Reuters poll on the cost of compliance, a large percentage of respondents identified continued regulatory change as a biggest challenge. As there are at least three regulations that they have to cater to in addition to a number of internal regulations and frameworks that the enterprise itself sets for themselves. The next big challenge is the cost of non-compliance, which is at least 2.7 times the cost of compliance. These non-compliance costs span across business disruption, revenue losses, legal fees, penalties and fines. For example, one of the largest GDPR fines was applied to British Airways in 2019. So cards skimming over a period of two weeks allowed 500,000 customer records to be stolen. It was fined 230 million due to the inadequate security and compliance policies and practices they had in the enterprise. The last challenge is the amount of time spent on compliance related activities. A hyper-proof IT compliance report found employees that are not part of the compliance team spend on an average eight hours every two weeks catering to compliance-related needs, leading to a huge loss in productivity and employee dissatisfaction. And the reality of the situation is that even achieving even basic compliance is hard. The same hyper-proof report actually showed that over 50% of organizations still use a combination of spreadsheets, file systems and emails to manage their programs. Imagine the overhead of managing this. Also imagine the state of their compliance program if this process expert in compliance decides to leave the organization. Scaling compliance really means empowering developers and automating their tasks so that compliance is part of the process itself and not a separate activity. But that is a challenge, right? So most organizations have adopted DevOps on a need basis. So if they have based on specific problems that they would like to solve. So if they have a source code problem, they bring in a tool to fix that specific problem. If they have a code review problem, they bring in another tool. Over time, the landscape has evolved into a Frankenstein system which requires many people to create, manage and maintain the integrations themselves. Many DevOps tool chains only reinforce the silos that you're trying to break in the name of DevOps. Instead of teams being able to collaborate together, their different tools put them already in different workspaces. Now when you layer security and compliance on top of it, it only compounds the problem further. Let's talk about security compliance. Individual vendors for security offer specific point products for each type of security testing. State static, dynamic, dependency mapping, cloud, container, et cetera. Each has its own license cost and integration requirements. Established vendors are very happy to sell you yet another product to give you a dashboard that pulls the results from all of these various different tools that they have. This makes achieving visibility from a security point of view more challenging. And when it comes to compliance, using different tools means your compliance policies enforcement, traceability needs to be set up across these various tools as well. This calls for more fragile integrations which need to be managed as well. So compliance requires organization to adopt processes that help comply with regulatory and legal requirements. GitLab makes it easy for you to wrestle the compliance beast by aiming to change the current paradigm to create an experience that is simple, friendly and as frictionless as possible. So how do we do it? Any well-defined compliance program requires internal controls that allow five key things. So one, defining rules and policies aligned with your organizational or regulatory or legal requirements. The second being generating and maintaining evidence of policy adherence. Third, once you've generated and maintained the evidence, you need to be able to, or once you've defined the rules and policy, you need to be able to enforce the defined rules and policies. Fourth is you need to be able to demonstrate your compliance with easy to access and readable reports and evidence artifacts. And fifth is it is not a one-time setup and you're done, right? You need to conduct ongoing risk assessments to detect and mitigate any gaps in compliance. So any compliance program that does not bring together all of these controls incurs the administrative overhead of maintenance. Organizations often run the risk of overspending on various different tools, creating data silos resulting in them being no better than when they started their compliance process. So GitLab being a single application where developers security and operational personnel congregate, we are well positioned to automate your compliance processes to answer the questions that may arise from your auditors and leadership team. So let's talk about how we do it, right? So the first step towards compliance like we spoke about is the ability to define the policies that adhere to organizational, regulatory or legal requirements. So in the DevOps ecosystem, this could mean who can approve an MR? What is our password management policy? What is our security policy? What's our scanning policy and so on. With granular user roles and permissions in GitLab, you are enabled to enforce segregation of duties. You can easily define your organization's policies regarding credentials, security scanning and rules for approvers as well. Granular permission control allows you to enforce approvals to determine what actually finally goes into production. And application security is an integral part of our CI CD pipeline itself. With that, you can then automate your information security compliance requirements. So organizations these days have to comply with various compliance frameworks and they're increasing by the day. On an average, an organization needs to comply with at least three frameworks. So with GitLab, you can define custom projects like HIPAA or SOX to extract adherence to various different compliance frameworks in a single place. We also have started to provide some of these compliance frameworks out of the box. Within the GitLab projects itself, issues and merge requests are central places where team members can collaborate. They can also maintain documents as well as track chain of custody and overwrite without maintaining these on various different tools, thereby helping you to maintain traceability and a history of collaboration. You can also define a common set of policies to be applied to specific projects with specific labels related to compliance. Compliance checks should be part of the merge request so that the non-compliant code is not merged into the main branch. So with GitLab, you can actually do that. You can apply specific compliance checks like who can approve, who can modify settings to projects marked with the compliance label. And then you can track the status of the compliance within the MR itself, whether you've been compliant or not to those rules. So we've received a few questions whether customers can create their own compliance templates to host relevant rules, regulations that they would like to follow. So similar to the enterprise templates that we've defined for HIPAA as an example, a custom project template can be created to host all the relevant rules and regulations necessary for that framework that you have as GitLab issues. In addition, documentation and file uploads related to this can be hosted within the issue itself in a tool that the developers are familiar with rather than integrating a complex external tool. So in the future, we will also enable common compliance controls like user permissions, approvers, which can be applied to projects with specific regulated framework labels itself. So while by collating within everything within the compliance project, you can automate audit records, such as tracking the chain of custody, lists of comments, mergers, approvers for projects labeled for that particular framework. So as mentioned earlier, GitLab is developing enterprise templates that enable you to streamline audit management with certain regulatory standards. These templates will automatically import issues that correspond to each regulatory requirement. As a first step, we have started with the HIPAA audit protocol, which is already available. Next in plan is SOCs and SOC2. So in addition, we've also put together some guidance in terms of how GitLab security and compliance features can be used to demonstrate adherence to specific frameworks like the ones that we've listed in this slide. You can actually go to these links and these links include guidance for how you can use features like static application security testing, dynamic testing, container scanning, and so on, as well as compliance features like segregation of controls, audit logs and events, credential inventories and so on to how you can use all of these features to demonstrate compliance or adherence to these specific frameworks. The third key thing is showing proof of compliance. It's something that gives every organization a headache and is set to waste close to 26 days of a developer's time each year. With GitLab, you can meet the traceability requirements for audits, such as user actions, permission changes, approval changes, and so on via audit events. So we also provide a consolidated view of various compliance signals in the compliance dashboard, which contains merge request approvals and so on. So if you look at this chart, compliance personnel spend a significant amount of time generating reports for various types of stakeholders. So collation of data and cost of interpreting the data are highest among compliance costs. The other challenge is to get rid of the ever-changing regulatory requirements. Providing systems to deal with compliance requirements and maintaining and reporting through these multiple systems is a key pain point that we've seen through some of these reports. So with that in mind, the GitLab compliance dashboard that is part of our roadmap aims to provide compliance insight in a consolidated view with all the relevant signals, such as segregation of duties, framework compliance, license compliance, pipeline and MR results. The compliance dashboard will continue to evolve. So today we only offer MR details, who has approved and so on, and we continue to evolve that, which the goal is to include more data to save compliance professionals' time when they're managing their compliance posture with GitLab. So as an example, Chorus.ai, which uses GitLab for their DevOps processes, recently when they were pursuing a SOC2 compliance, they were able to showcase compliance traceability with ease due to the single application and single data store capabilities of GitLab. To summarize, compliance is all about processes and outcome. You have to plan adequately for failure and adapt your application for resilience. This means that you have to ensure your basic security and compliance hygiene is in place. That means you're not leaving any unprotected passwords, unprotected databases, and you have policies defined for your regulations. Once you've done your basic hygiene, you have to monitor and detect any issues and adapt accordingly. And third is that manual processes have to be done away with and standardization and automation should help to create repeatable process that help with improvement of your STLC itself. So in addition to supporting customers to build secure and compliant applications, we also put great effort in making sure that our product itself is secure for consumption by customers. So we are a SOC2 type 1 PCI compliant application. We also address various controls that are defined by various regulations. So we've provided links to those. So all of these are summarized in our compliance webpage that is linked in the last slide. And with that, I will thank you.