 Hello and welcome everyone. Thank you for joining us today. We're excited to have everyone on. My name is Erica and I work on the content team here at GitLab and I'm joining you from Chicago today. We'd love to hear where everyone is tuning in from so if you feel so inclined please use the chat function to tell us where you are in the world. Also joining us today is Lee Matos a support engineering manager at GitLab and Dan Gordon from technical product marketing who will be on hand to do some technical tag teaming with our presenter Cindy Blake who is the product marketing manager for security. We're going to give people a few more minutes to get locked on so while we're doing that I am going to launch a poll that you can take part in if you would like to do so. Today's webcast will be going over our latest release 11.1 and we'll focus primarily on our security products and the poll is out there into the world so go for it. All right so as people continue to join I just want to thank everyone who participates in the poll and before we get started I'm going to cover a couple of housekeeping items. First feel free to ask questions throughout the presentation. You can use the Q&A function at the bottom of your screen to do that and we will also have some dedicated time for questions at the end of the presentation and demo but you can go ahead and send in your questions as you think of them and we'll make sure to get to them at the end. If you're experiencing any technical difficulties you can use a chat function to get in touch with the moderator for help. Now I'm going to turn it over to Cindy. Great thank you Erika. So as you know GitLab enables concurrent DevOps by providing a single application for the entire lifecycle accelerating development and delivery by as much as three times by sorry by three times and as much as 30 times and security is really a key part of this capability. It's going to be the primary focus of today's webinar and I'm super excited to share with you how you can have both DevOps speed and deliver secure applications but first let's look at a couple of other highlights in the release 11-1. So the first is we're going to cover advanced search syntax, the redesigned MR widget and the MR panel in the web ID and then we're going to dive deep into security. Before we do though I just want to mention this is our 85th consecutive monthly release and we are so proud to be able to launch every month. You know in addition to these more significant updates we push between 40 and 100 code changes live every day. We use our own product and it empowers us to move quickly and enable our business agility. So we're excited to be able to empower you all as well. So let's look at these three release highlights briefly and you can see even more at the link here at the bottom, the 11.1 release in the blog. So advanced search syntax. As teams generate large amounts of source code continuously searching through all that code can really be a challenge. So having great tools to manage and in particular search for all that code is critical. With this release we are introducing new advanced search syntax options allowing you to nail down your code search with three more granular filters. So now you can filter by file name, file path and even file extension when searching through repository code resulting in more targeted search results. So these filters are available in both the web UI and the API. The redesigned merge request widget. So in GitLab MRs and in particular the merge request widget is a powerful feature showing you many integrated and relevant information points and functionality. So as such we want to constantly evaluate the design and ensure that the information presented is easy to consume and most useful. So in this release we've tweaked the design of the information and pipeline sections making them easier to consume by breaking them slightly away from the rest of the widget content. We've also added the merge request panel in the web IDE. So when working on a merge request or reviewing an MR it can be it can help to refer back to the description for why the changes were made and for more context. So with this release instead of having to switch tabs you can now open the MR description side by side with the code directly within the web IDE. But now I want to get into security. I mentioned that we use GitLab to run the GitLab business. It's really the secret behind our superpowers. So we'd like you to develop your superpowers too. And last month my colleague John Jeremiah presented this slide for the 11.0 release. He reminded us of some quotes from Mark Andreessen such as software is eating the world and cycle time compression may be the most underestimated force in determining winners and losers in technology. You know we've heard these quotes before and there's no doubt the future of business is software and competitiveness really depends on how fast teams can deliver code which translates into customer value. But when you think about security how does application security keep up using tools that were developed for the way software was built 10 years ago or even more. You know software development is moving much faster than application security and the shift is really punctuated by DevOps. So I was researching this a little bit in terms of some quotes and so forth and Jeff Williams who's one of the OWASP founders shared his thoughts on this topic way back in 2014. He said the goal is unprecedented real-time visibility into application security across an organization's entire application portfolio allowing all the stakeholders and security to collaborate and finally become proactive. He further predicts that what's needed is application security technology that will scale massively. So clearly even back in 2014 he saw that the existing application security tools and approaches couldn't keep up and the problem has gotten worse since then. So applications are prime target of cyber attack. We can point to lots of breaches that were application focused. Application tools are expensive and they require integration of both technology and processes and how do you test all the code when code changes faster and faster and we've got incremental incremental changes. You know as software gets more and more automated and tools like GitLab and GitHub and Jenkins, Jira, Chef, Puppet, New Relic all of these different tools come to bear how do you test your applications for security vulnerabilities? Do you have people who sold job it is to integrate and maintain the tools that are used to create and deliver software? If so, you're not alone and you're probably frustrated by this overhead that instead of focusing on creating business value. So you weigh the risk of testing against the cost and speed of doing so and as coding becomes more iterative you struggle with do I test every minimal viable change in the code or do I wait until there's enough substance to justify the cost but at the same time risk a costly rollback if severe vulnerabilities are found. It's a real dilemma. We've known that shifting left is important and that it can be less costly to find vulnerabilities early in the life cycle but doing so is really hard and there's going to be winners and losers in this and the winners are going to create business value and the losers are going to become a business inhibitor you know if you can strike the right balance you can avoid being defensive about one or all of these things you know risk, cost, agility but doing so is really going to require a different approach. You know one of my favorite quotes is from Albert Einstein he says the definition of insanity is doing the same thing over and over again but expecting different results. It doesn't take a genius to see that our existing app set tools are really colliding with modern development methods. So what if you could make a wish and scan all code every time seamlessly for development using fewer tools not more with dev and security on the same page instead of adversarial. You know we believe that GitLab security products can help you get there. In addition to finding bugs you know tools must take into account the demands on the developer's time. Any interruption generated by automated tools forces the developer to switch away from their primary objective of developing code. So the successful security tools are going to add high value while minimizing the distractions for the already busy software engineers. With GitLab all of these tools are automated into every merge request. You no longer have to choose between risk, cost, and agility because there is one tool for the software development lifecycle you can use it on every code commit. All of these tests are run automatically. The GitLab app creates a complete review app so dynamic testing can run on this working code as well all very early in the development lifecycle. There's no need to buy separate single solution tools and if you already have the robust SAS and DAFs tools that have been around for a long time you can reduce your costs of using them by using them more sparingly and using GitLab for every code commit. GitLab is turning secure DevOps on its head. It's not about making those separate app set tools more integrated and trying to fit that square peg into a round hole. It's all about DevOps. It's about using the tools that developers use to create and deliver more secure applications. What good is the best buggy whip if the world is moving towards cars? You get the picture. You've got to have a different way of doing things. Now before we get into the security demo I think it's good to level set on a couple of things. We've been evolving so fast at GitLab things can take 10 steps forward in the blink of an eye and I hear you might be saying you know I understand what GitLab has security for security but I think it's worth recapping because I'm willing to bet you're going to be surprised by something on this list. Now first I think it's important that we are all on the same page with regard to the scope of what we're talking about with security. So GitLab is a secure application and we've got a CISO Kathy Wang that's responsible for the security of the GitLab application and you can find more here at slash security. In addition to that we help our customers secure and manage their software development lifecycle. So features of GitLab like two-factor authentication and and auditing and so forth help you protect your software from unauthorized access. So those two things are really important. Now what we're going to focus on for the rest of this webinar though is the security products and which we're now calling secure and how we can help our customers create and deliver secure applications and so this is all about application security testing for the most part today. Now I mentioned we move fast so if you miss just one monthly release you may have missed a whole capability of what we have to offer. GitLab started its security vision with the launch of SAS static application security testing in December of last year and is added capability in scope with every release. So earlier this year we added DAST and container scanning then purchased gymnasium incorporating its capabilities for dependency scanning and more. Then in the spring we added dependency scanning enhancements interactive security reports and most recently here license management and the security dashboard that we're going to talk about here for 11-1. Now the security dashboard represents an additional persona amongst our target users that of the security professional. So historically we've been focused on the developer and even the interactive security reports resulting from a merge request are intended to help the developer identify vulnerabilities and quickly evaluate them. But the security dashboard is really intended more for the security professional to view vulnerabilities across a project. So today's capabilities represent our minimal viable change version one but you'll see from our track record of enhancements that we quickly evolve and enhance what the GitLab application can do. Now I want to remind you of some security resources that are available. You can find these with these links or just google them. We have a security deck and that deck goes into the security features that we've had prior to 11-1. So SAS, DAST, license management, all of those things are part of that security deck. I would encourage you to go out and have a look. There's some screenshots there and links to user documentation and examples. But now let's focus on what's new with 11-1 around security. So one thing that's important is we continue to add supported languages. So this month we added Node.js to our SAS capabilities. Node.js is an open source cross-platform JavaScript runtime environment that executes JavaScript code outside of the browser. Now SAS allows you to spot code vulnerabilities as soon as your changes are committed to the repository. With the information, with this information available in the merge request, you can fix vulnerabilities so they don't land in production. This is all part of the shift left. You don't need to change any setup in your Node.js project with 11.1. The new language is automatically detected and tested by the SAS job. The other point here is that security reports in the merge request are useful to spot new problems that are introduced by new code even before the code is merged into the master. This is really shifting left here, guys. But since the vulnerabilities can appear even before a merge request is created, sometimes developers need to know the security status for a specific branch in a specific moment. 11.1 completes the set of security reports shown in the pipeline view, adding both container scanning and DAS. Simply review the reports tab to access all security information and take the proper actions. And this is a screenshot here, but I'm going to show you a live demo here in just a minute. They're responsible for. And even after the code has been merged into a stable branch or deployed to production, they need to be able to continually monitor and jump into any problems that could affect security. So in order to make life easier, GitLab 11.1 introduces the security dashboard that reports the latest security status of the default branch for each project. This gives a very accessible view to security teams that can easily spot if something is wrong and actions need to be taken. It's an interactive dashboard, too, so it can be used to dismiss false positives or create issues to solve existing vulnerabilities. And really, I think that this is probably best articulated in a live demo. So let me jump over here. I'm going to make this larger. Hopefully y'all can see that just fine. So this is the security dashboard. So let's say that the security team wants to see the latest status of the master branch of a project, or a project manager wants to assess where the project stands overall from a security standpoint. The dashboard can be found in the project menu up here, project menu of the project side navigation here. It provides a summary of vulnerabilities and other out-of-policy indications found in the project from all of the security tests run on each merge request. Here on the dashboard that includes SAS, DAS, container and dependency scanning. It doesn't yet include license management. That's kind of an open issue of whether or not license management should be part of the security dashboard or not. So if you've got some thoughts on that, feel free to provide some feedback here. Now it's an interactive dashboard, so the security pro can look at vulnerabilities where the developer may have been unsure whether to dismiss it or create an issue. So here, let's drill into one. One, you can choose to dismiss the vulnerability or create a new issue right from here. Now I can also drill down and see where the actual code is that has the issue. And this is really going to help with collaboration between the application security person and the developer. It's sort of the single source of truth. Everybody's looking at the same thing, right? Now the developer might use the dashboard, but it's really intended more for the security person. And the individual developer is probably going to use the security report that's in the merge request. So let me pop over to the merge request view and have a look at what the developer would see. So this is for a specific branch that they're working on. And one thing to note here, in terms of workflow, you could add a security person as an approver if you wanted. You know, our philosophy is that security vulnerabilities should not block the build. That may not be everybody's policy and direction. And so, you know, you've got the flexibility here to add a security prover if you wanted to. Now, excuse me, here you can see that 63 new vulnerabilities are detected. Now this is on a branch, so you would expect that the developer is going to see a lot of vulnerabilities and deal with them before it gets to the master. That's kind of the intent here. So I can see my SAS, my DAS, dependency, container scanning, and license management here from that individual merge request view. And again, once again, I can drill down, and as a developer, I can choose to dismiss this vulnerability or create an issue. So you've kind of got two lines of defense or process here, right? So the individual developer is going to look at the vulnerabilities in their merge requests and deal with what they can. Now, because security is not always easy, you've got the dashboard where the security professional can look at things that are getting merged into the main branch and look at that and decide if there's others that need to be dismissed or escalated through an issue. So with GitLab, you really can scan all your code every time. We make it seamless for the developer, and you don't have to buy a bunch of tools and integrate them. And everybody can get on the same page. So this is how you can scale application security for DevOps speed. It really is a different approach. We solve the problem not by throwing more tools at it, but making it a natural part of the developer's workflow. All these tests are automated with every merge request. So you no longer need to choose between risk, cost, and agility. And because it's one tool for the software development lifecycle, you can use it on every code commit. I know I sound like I'm harping, but it really is different because you can run it on everything automatically every time. So, sorry, I get a little excited about this. Let me jump back over here and see if there are any questions. So I think our moderators are looking for questions. I can jump in to zoom here and see if I see any questions. Okay. So while we're waiting to see if there's any questions, I'm going to mention on the poll results just for just a minute here. This was from the poll that was taken in the beginning with Erika. So 82% of you are not using SAS or DAS security tools. And 76% are using static. That's interesting. Okay. I'm not quite sure I'm clear on the results here. But if you're not using, if you're not using some of the more traditional SAS and DAS, GitLab is a really great way to jump in and start testing your applications very early on without buying additional tools that you have to babysit and integrate and maintain. Okay. Dan, you got a question? Yes. So video SQL, I hope we pronounce that right, is asking did we develop it from scratch? So by it I believe means the scanning security tools or did we use integrate user slash integrate well-known vulnerability scanning engine? So if you go to the, let me jump over here, if you go to the security deck that I mentioned, you'll see some more information there around how we are, what scanning tools we are using for each of the languages. So we're primarily using the open source scanning tools. In fact, it also, it has a list of the languages which might be useful too for, you can see for SAS and for DAS and so forth in terms of more details there about how we're doing that. And I, maybe I should have gone into that a little bit more because we have developed these things all so fast, but I hope that answers your question. Are there any other questions? So we've also got one that we did answer through text, but I think it's worth shouting out. So the question was security tests and so on can also be done with other software like SonarCube, Synopsys, Coparity. They have a neat function where a dev can check the results right in his local IDE. Is this possible in GitLab or is it planned? Can check the results in the web? I'm sorry? In the web IDE? I'm not sure if it's integrated within the web IDE. That's a good question. Lee, do you know? Hey there, this is Lee here. I threw a response to that one in. It's currently not integrated into the web IDE and there's no plans to integrate it into a local IDE yet. Kind of everything with GitLab, the intention is that it will start with the merge request. So for it to start at the local user's IDE is a little bit further to the left than we're not there yet. We're starting with everything in the merge request. So I don't believe there are any plans for that in the short term. But great question. Okay, do we have any other questions? Well, we're super excited that you all were able to join us today and be sure and check out 11.1.