 Okay. Hello. Good morning. Good afternoon. Good evening. We are live streaming here with the sales training for Security 101. This is going to be part one. We're going to focus on a market and competitive overview. And then a week from today we will be doing part two with a focus on the sales plays and roles and key messages and a little bit more tactical. Okay. So I'd like to remind you that this is live streaming so we can take Q&A. You can put it in the chat window in either YouTube or Google Hangouts. And John Jeremiah is on to help me make sure that I don't overlook any questions and probably also help me make sure I save plenty of time for Q&A at the end. So I'm going to be using the agenda that was in the meeting notice to go through this. And if you'd like to follow along all of the links to all of the content, all of the links are there, most of which comes directly from our handbook. So I apologize if I'm a little bit not so smooth. This is my first time to do a presentation where I don't use slides and I'm using the handbook. So hopefully everybody can follow along. So we're going to start with that application security landscape. Now you can find this here on this page that is under the competitive section. We've got a market overview. I don't want to read all of this to you, but I do want to make a couple of key points here because I think that the context is really important in the context for change. Traditionally, application security has been kind of small potatoes in the overall security pie, right? Security started out with focusing on the perimeter and whether that was network security and work endpoint security and using multiple layers for defense in depth to keep the bad guys out. It's really evolved to a much more proactive and predictive method and application security has taken on a much greater importance. And some of this has to do with the move towards cloud computing with major attacks that have been in the news that everyone sees. So they're top of mind. The GDPR is another one where this is a requirement not only for European companies but for companies outside of the EU that have data about EU citizens. So they need to make sure that their software vendors adequately secure the private information. So there's this heightened sense of how can I do that? Well, applications are a key way that that data gets compromised. So application security just becomes more and more important. There's a great 451 article that talks about the rise of open source code and how just one little piece of code that is vulnerable gets multiplied a thousand fold out there in the wild and how that can become very pervasive. And then DevOps. So DevOps velocity really requires a different approach to security. Historically, security has been something that was done at the end. So you code, you do all of your other kinds of testing, your unit performance, all that kind of testing you get at the end, you do your security testing and someone would review the results and decide if the vulnerabilities that were found were critical and needed to stop movement to production and you go back and do the remediation. That just doesn't work in a DevOps environment. When you are moving things to production, you know, monthly, weekly, daily, hourly like we do, there's just not time to hold up production. Which brings me to a point that, well, before I get to that point, the DevOps can be hard to integrate security in it when it's done as a standalone siloed process and tool. So if you find, if your customers find themselves having to either let the vulnerabilities move to production and hope that they get fixed or stop production, you know, stop a move to production, which is going to hurt your business velocity, you know, these are the trade-offs that your customers are making. And with GitLab having security testing built into the entire DevOps process makes it possible for you to not have to make some of those choices. So you can test on every commit and merge request. You can test without spending a fortune to do that. If you took some of the application security, the siloed solutions that are out there today, they're very expensive. They charge either by line of code or by developer. There's a bunch of different models but the more things that you test, the more it's going to cost. That's not the case here in terms of it's built in. If you're using GitLab, then you get the, with GitLab Ultimate, you get the security testing. Our security paradigm is a good page to share as well with your customers. This is really our point of view. I think Fabio and Philippe worked on this. And it really talks about how we believe that security just needs to be built in, baked in, and it shouldn't hold up the build. And so when you think about that, it does mean for the security individuals that they need to be able to come back after the fact and keep an eye on what vulnerabilities are found and look at it from their viewpoint. And that's where the security dashboard comes in that just launched with 11-1. So let's see, I'm going to just kind of go back to the agenda on where we are for just a minute. We're going to focus on the competitive landscape. And then we're going to talk about kind of an overall value proposition that I think is important to use and then we'll go to Q&A. So from a competitive standpoint, this is the Gartner Magic Quadrant for Application Security Testing. And what you'll see on here is these vendors that are the leaders, they've been around for a very long time. They have very mature products. They are typically point products. I mean, MicroFocus has Fortify and they also have several other products as does IBM. And of course, they can solve more problems than AppScan and Fortify can, but they're going to have to sell you more and more pieces to do that. So the ones that you also may run into quite a bit would be Black Duck, Sonar Cube, Sonotype, some of those guys that tend to be a little bit more narrowly focused. So because we acquired gymnasium and got into dependency scanning, that's kind of the reason why you see Black Duck, Sonotype, White Source, these guys as your competition because they are primarily competitive for dependency scanning. But you got to remember, we have SAS, DAS, Container Scanning and License Management. So all of that within the purview of our security capabilities. So it's really multi-dimensional in terms of who the competitors are, but I hope that this chart which is on the handbook will help you understand kind of where we fit and where the different competitors fit. Let me just make sure I didn't miss. Yeah, so when we talk about the value proposition, it's important to distinguish the difference between this siloed approach that the other vendors have of being a point solution for individual pieces versus GitLab's end-to-end. We are end-to-end not only with security, but we're end-to-end for the entire DevOps tool chain. So that integration is really where the value comes. So we may not have some feature functionality that one of the more expensive guys do. We're working on that. We'll get there eventually. But that is kind of a side benefit to having security built into your DevOps processes. So we'll talk some more next week when we get into the sales plays and who to talk to and what they care about. But this page here will show you, here's a summary of what we have. And this is sort of a teaser for the benefit to each of the different roles. So the developer, they don't have to stop what they're doing and go look at another tool. They're in their native environment and so they don't have that context switching issue. When they run a merge request, they can drill down immediately and see what the issues are and either log an issue to fix it later or fix it right away. For the security pro, now that we have the security dashboard, you can look across merge requests and see all of the different issues that need to be resolved and weigh in on that and be more collaborative with the development team. In addition, a lot of times the security professionals end up spending so much of their time just maintaining tools. And if you're using GitLab and it's part of the process and part of the one single application, you don't have to manage and maintain all of those other integrations. So it frees them up to do what they really need to be doing and want to be doing which is focusing on security vulnerabilities. And for the C-suite, they typically are juggling the level of security versus how much it costs and business agility. And that tends to be a three-legged stool and one or the other typically has to give. That doesn't necessarily have to be the case though because one application was security built in. You save on licensing costs. There's an ROI efficiency, I was going to say slide, but it's a web page that you can look at that does a comparison on if you can replace some of those tools. I think we'll talk about who that message is best for. And you can scan all of your applications. One of the big trade-offs that companies have to make with the more expensive siloed application security tools is they can't afford to test every application. That's part of it. And within the application, they can't afford to test incremental improvements. So the fact that you can test with every merge request really, really has a value there in terms of shifting left and helping people find those vulnerabilities earlier. Which I want to remind everybody there is a security deck. And next week we'll go over a lot more of the resources. But there is a security deck out there that goes into the products that we have and has some demos and gets a little bit more into how we solve the problems. But again, kind of food for thought, save that for next week. And I think I'm at 15 minutes here and I want to make sure that I reserve plenty of time for Q&A. So let's jump over to questions. Let's see. Simon Williams, have we got any stats on how much time GitLab would save on remediation of security issues? So time, not so much cost. There's a lot of resources out there that will show by shifting left how much cost can be saved because what happens is if you can remediate early, you don't have to do the rework and retesting. If you remediate late in the game in a traditional security gate, then the developer has to go back and fix it. You've got to retest everything. And that just, your costs go up exponentially. And I'll try to find some of those sources on the cost side. I don't know that I've seen any on the time side, but I really kind of go hand in hand because the cost is an equation of how much developer time is spent going back and doing the remediation and the retesting. Good question. John, do you have any questions from YouTube? No, Cindy, that's it from YouTube so far. We'll see if anybody else has any other questions. Feel free to post the questions in chat on YouTube if you have them. Okay, we'll give a few more minutes. Maybe it was so thorough that there aren't any questions. So in the meantime, Cindy, what are you going to cover next week? I know we're going to have a follow-on session. What are the highlights for next week that you're going to address? Good point. Very good point. So next week, we're going to talk about selling GitLab security. So who's a prospect and who's not? You don't want to waste your time. You don't want to waste your time on someone that's not a prospect and you really don't want to pitch the wrong value proposition to the wrong segment. So we're going to look at the market segments. There's immature security folks and there's very mature security folks and I think that the approach that we take for each of those needs to be a little bit different because their interests are going to be a little bit different. And then when we look at buyers and users, what do they care about? What does the developer care about? What does the security pro care about? And what I'd like to do is flush out the security plays a little bit. In fact, if you want to take a look at this document in advance, I'd really like it to be sort of a community contributed aspect to this. And then we'll cover resources too a little bit. In fact, just to give you a kind of a sneak peek here, I can show out in the documents. There are pages for each of the five security capabilities. SAS, DAS, container security, dependency security and scanning and license management. And what you'll see here are the languages that are supported. This is also summarized in the security deck, but this goes into a little bit more depth. So I hope you find the links in this agenda useful. Do you have any other questions? I guess let me maybe take a stab at a couple of the questions that I get frequently. One of the key questions that I get is how do we compare to pick your favorite poison? How do we compare to an individual point solution? And I just really want to reiterate the point there that it's not about a head to head comparison. It's really about that integration. And that is really, really key because there's no question whether security is part of the process for every piece of code that goes through your software factory. Okay, well, I think we can give some folks back some time and we'll pick up next week. Cindy, I got another question. Paul Duffy asked a question. Is anyone else providing SAS so early in the dev commit process around commits and merges from Paul Duffy? Yes, they are. There are at least two that I can think of that are actually putting the security capabilities into the developer's IDE, typically into Visual Studio. I think there may be a couple other IDEs out there that it's sort of like a spell check capability where as the developer's typing, it will come up and caution them that, hey, this is not a secure method of coding that and even offer remediation advice. That is something that we can aspire to. We don't do that today. But it's also something that is in the more, some of the most costly vendors out there. Okay, Cindy, by the way, I'm taking questions on Slack too. So if people ping me in the sales channel in Slack, I'll take the questions there as well. Oh, nice. Okay, great. So we'll give people a second or two because I think Larry might have had a question or Hayden was typing right now. Give us a second here. And while we're doing that, I can also address another question that came up quite a bit the other day, which is, can we get this as a slide? And so we're working on putting that image into the pitch deck. Oh, and I had a question for everybody else. Should this competitor scope be in the security deck? Drop me a note in Slack if you want. Let me know your thoughts there. Okay, so two questions. Okay. When I put this in the chat as well from Larry, do you see a coexistence strategy with existing tools where devs are empowered to first and security, you know, a security professional then goes second? Yeah, absolutely. In fact, in the resources here at the end, I think Joel has a video where he talks about that. That's really good. I think for the, and this kind of gets into the next weeks, but I think for those enterprises who have already chosen to invest heavily in really sophisticated application security tools. If they use GitLab security as kind of the broad net that's done on every application and every merge request, it's going to save them from, you know, then they can focus their more concerted efforts and costly efforts on the exceptions rather than the rule. Or maybe they make that as, you know, kind of a security audit process as opposed to trying to push that into the developer space. Because one of the things that application security vendors have a really hard time with is getting developers to change their context and use a different tool. It just doesn't work quite frankly. And so it's been kind of this, I don't want to say adversarial, but it's been a difficult relationship between dev and security. And so I think this can be used to really help that. You've got one view, one tool, one source of source of truth that could help with the collaboration between dev and security very early in the life cycle and then continue to use the more expensive, more sophisticated tools later. Cool. So another question from Hayden, what are some of the common objections you might see something like, you know, do you support, you know, certain languages, etc. So languages, scope of language is always one of the early questions that will determine yes or no whether they can work with you right away. That's true for every vendor. I'd like to save some of that for next week when we talk about sales plays and and we can, I'll make a note to make sure that I cover objections there. Because I don't have anything prepared here to point to about objections, but note taken, I will make sure to cover that next week Hayden. Good. Thank you. And I've got another question I think coming in on slap. So Larry wanted a confirmation. So what we are providing, so his understanding then from what you described is, is it, is the value prop then a reducing license fees and we're, or is the value prop about earlier identification or mediation. This is Larry's, Larry's questions kind of building off of the coexistence strategy. I'm feeling my thunder for sales plays. Yes and yes and it depends on the audience. So the, those that haven't made an investment in application security yet. You can focus on the ROI and the fact that they can avoid making that costly investment and get started with us and get it integrated right from the get go with the folks that have already made those investments. The value proposition really is more around that integration. Cool. Another question Simon asked if we have, do we have case studies or even anecdotes where a security issue or breach resulted in a fine or some sort of a penalty from a regulator. I don't have one handy from a compliance standpoint but that will 51 article that I mentioned down here. It's in the resources as well because it's such a good article right here it. Whoops. It really focuses on heart bleed as being like the first major application security breach that that use third party code that had widespread implications and was very, very costly. Compliance is sort of the lowest common denominator. People that are focusing on compliance tend to not be the very mature security shops because so many people that have been compliant have been hacked. It's really it's just the minimum basic thing that you need to be doing but anyone particularly you know financial services health care software companies. They all go way above and beyond compliance so I wouldn't I wouldn't focus on so much on compliance as I would just on on some of the key attacks that are out there and if it would be helpful for you guys I'm happy to put together an updated list. I always kind of felt like it got tiring because everybody uses that but if it would be helpful for you. Let me know drop me a note I'd be happy to do that. All right, looking at slap it can see Larry's typing something I'm going to give him a second or two. Another way to contribute verbally versus through I am not sure this is a productive. Oh, that was Larry asking Hayden good feedback and so yeah we're by the way we're learning as we do this. We should be in the hangout I don't know why people couldn't join the hangout. We were going to do some troubleshooting offline and figure out why you couldn't be in the hangout to do this verbally. That's the intent of this that you join the hangout if you're one of the first 50 participants. We're in the hangout together and as far as I can tell no one is in the hangout. So we're going to have to figure that out. I don't know if anyone's in the hangout. I think there's 33 viewers. Well, those are I think those are viewers in YouTube. I don't think those are viewers in the hangout so I need to figure out what happened. I'm going to do another test hangout later to figure that out. Okay, it could be that other hangout. Well, it's also possible because we are also competing in this time slot with the retrospective from the release. So that might be it. It could be that we're we're sitting on top of that. So either way. Okay, so sorry about that. I was that's why everybody's so quiet. I guess I didn't think this group was quiet. Well, there's there are two live streams going on from get lab right now this one and the and the retrospective. So which could be why we had this conflict. Yep. Okay. Well, thank you all appreciate your participation. And if there's anything like the objections that you would like to see specifically next week, I need to add it's not already in that agenda. Be sure and let me know. Thanks, everyone. Take care. Bye.