 Okay. So we're live. We've got a introductory slide, but I'm not seeing anything on this side. And we are live on YouTube. I just checked. Yeah. Yep, we're live. And I'm, all right, well, I'm not sure. It just happened to me yesterday when I was doing a drive run with William. It doesn't give me the option to start it like it should. But I'm seeing it on YouTube. Everything you're doing. You are. Okay. All right. Well, as long as you're seeing it in YouTube, then we're good. I'm not seeing the chat in YouTube though, so you will have to... I see the chat. Okay. So as long as you can see the chat in YouTube, then that is awesome. Okay. So we're just waiting for, we'll wait for a couple of minutes so people can jump on. And Kim, is my screen big enough? Yes. All right. We'll give it one more minute for a few more people to join, and then I'll get started here. This is part two of the security sales training. Part one was last week. We went over market and competitive overview. And today, we are going to focus on personas, segments, and sales place. Okay. I'm going to go ahead and get started here. As I mentioned last week, we went over kind of the overall landscape. Some of the progress in the security industry and some viewpoints on application security. We touched on competitive scope in terms of how much of the application security market GitLab covers versus some of the more point-specific solutions. And we went over the abroad value proposition. Now, what I want to do this week is drill down and look a little bit more specifically in the security space. So, we're going to start here with the personas. So, there's three basic personas that you need to have on your radar. There's a security specialist, there's the developer, which we would traditionally sell to, and there's security leadership. And they each care about a little bit different things. So, obviously, you've been selling to the developer. They may or may not have a focus on, they probably don't have a focus on security, but they may or may not have kind of an interest in security. Let's see. Larry says, am I joining the sales training call? Kim, if you could look at Slack and see if some folks are having a problem getting in, that would be helpful. And I'm going to push forward. So, the security specialist, the developer may or may not care about security. They care in so far as it's a flaw and they need to have code that works and accomplishes the business needs. But they usually don't understand some of the details about security vulnerabilities and they don't really care at all about across projects. The security specialist, on the other hand, they're going to want to look across projects and understand, are there patterns in the vulnerabilities that are being surfaced? Are we continuously creating the same kind of vulnerabilities because then they can help educate folks on how to avoid that? They are going to care about the risk involved. So, looking at not just the vulnerability, but what kind of impact that vulnerability could have to the organization. And then the security director could be a CISO, Chief Information Security Officer, could be just a director, even manager level in some instances. They're going to have kind of a longer term view and they really care about the risk more than anything and how can they manage the risk of the organization with application security vulnerabilities being one part of that overall equation. So, if we look at the segments themselves and those personas play into the segments, I would characterize three segments and we're going to cover these here. The first is someone that has a very sophisticated application security program. The second would be companies that have security programs, but maybe not so sophisticated in application securities. And then kind of lastly, those that are really just focused on compliance and doing the minimal that they have to meet to check the box and be done. Okay. Somebody needs to mute, please. So, let's start with the first one, the sophisticated application security program. So, these would typically be the larger enterprises. They probably have a hefty investment in application security. Now, remember from last week we talked about historically security started with protecting the perimeter and infrastructure security, but now that infrastructure is diminishing and so the focus is changing to the application. Most of the significant breaches have come through the application layer and so there's now this renewed or a new found focus on application security. Now, this segment though that have sophisticated application security programs, they've already recognized that so they've already been in that space. They probably have application security specialists that tend to come from more of a developer background, less of a network background. And they may have investments in applications like Veracode or Fortify or IBM AppScan or some of these more expensive SAST and DAST focused tools. And then they probably are also doing some sophisticated threat hunting. Usually it's the financial services industry or healthcare providers, people that are enterprises that are highly regulated and that also really use their applications to their competitive advantage. Their biggest challenges are going to be time to market because their applications are their competitive advantage. They want to be fast, they want to create new applications and improved applications as fast as they can. They're probably already way down the path on DevOps and they're balancing speed with security. So the value proposition for these more sophisticated application security based folks is really not, it's less about head to head, SAST and DAST capabilities because they've already been doing that. It's really more about having that integration across the development life cycle. And so their biggest challenge really is the cost and the speed. So if they are scanning every application, it's going to get very costly in the more traditional application security tool models, pricing models. So they're probably not able to scan everything and they're certainly not able to scan every commit and merge request. So what GitLab offers, I'm going to kind of jump here just a little bit over to the sales play. So the sales play here for this mature application security customer is we have one integrated application. This goes back to our basic premise which is, let me find it here, which is on our main about GitLab page. And this is security is baked in, it's part of the software development life cycle. You don't have to think about it as a separate step, as a separate tool that requires integration. There's other reasons in addition to security to buy up to ultimate. Some of them are listed here, the Kubernetes integration, there's lots of additional reasons in addition to security to buy up to ultimate. But from a security standpoint, this is a way that you can scan every piece of code. It also can get your dev and your application security professionals all on the same page. So they're looking at a single point of truth. They're just a truly integrated process as opposed to a separate distinct silo. So that's an important piece. We'll get to handling objectives here, objections here in a minute. But that's the approach that I would use for those folks that have a mature application security program. Now let's look at the people that have, they have security programs, they understand security is important, but they may have followed a little bit more traditional approach. So maybe they've been focused more on infrastructure security and less on application security. This is really a sweet spot for us because, and I would jump on those as your highest priority, because you want to catch them before they go down the path of $100,000 million investments in these more siloed application security tools. So they may understand that they need a tool. They may be reluctant to spend that kind of money. And if we can come in and do their static and dynamic application security testing as, you know, again, integrated as part of their software development life cycle without substantial incremental cost, then it's a, you know, it's a win-win. They, the way that you can identify them is they may have just started down the DevOps path. They may be a little bit less mature there. They probably don't have a dedicated application security department or professional. They probably have someone as a security analyst that's wearing many hats and trying to do application side of things as well that may also have come more from a network-based background. They may be a little bit more focused on compliance. You know, maybe they've stretched beyond compliance and realized that that's kind of a low bar, but they're just getting started there. The challenges that they have, their biggest challenge is that they are resource constrained. So they don't have a, you know, dedicated app set person. It's very difficult to, for them to expand and hire security people. And so anything that you can do to help just bake it in as part of their normal development process is really going to be a help to them. And in addition, the fact that you can do it without this big incremental ramp in tools and integration and cost is really going to resonate with them. And so this, the ROI page that we have is where I would recommend that you have a conversation. And here we've got a comparison between GitLab, GitHub and Atlassian. This is meant for kind of illustrative purposes and it shows here, you know, GitLab covers all of these things plus security, whereas if you're doing GitHub or you're doing Atlassian, you're going to have to invest in some SAST and DAS tools and those can be quite costly. So this bottom line here can really be painful and really make a point. Another page in the handbook that I would recommend that you use is the difference in scope of what we do versus some of these other siloed point products. And some of them may have started using SonarCube and WhiteSource and if you've come at it from the gymnasium dependency scanning approach, then that's probably who you're going to run into because SonarCube and WhiteSource, they kind of live in that dependency scanning space and BlackDuck came from that space as well. So you probably run into those guys there where you would run in to Fortify and AppScan and Veracode is around static and dynamic security testing and the point here is that we do all of those so you can replace all of those tools with ours. Now we're not yet quite as robust but we're getting there. So in terms of a security dashboard, we just launched our first dashboard and that dashboard is really intended to focus on that security persona. So back here on these personas, that security specialist is really going to care about the dashboard and the reason why is because it looks across what an individual developer may be working on. The developer is going to care about the security reports that come out and I'm going to give you just kind of a sneak peek of those as well. But this scope can really make a difference when you're talking to someone who hasn't started down the path of the big application security investments. So we come back here to the sales plays. Another point is they can grow with us. So come on board with us with Ultimate, get started on rather than starting down a siloed approach, get started with an integrated approach where all of those application security testing capabilities are built in, they're just part of what you do and grow with us. So we've got a great reputation for iterative improvements and as we continue to refine and expand that dashboard and those capabilities, you'll be right there with us. So let me just briefly mention the third type of company and that would be a much more opportunistic play. This is someone who really just cares about compliance. They're not interested in application security. They are barely interested in security, maybe only as far as meeting the compliance requirements that they have. Typically, this is a small company, maybe a startup. They just want to check the box and do what they have to do. They're very resource constrained and they typically lack security expertise because GitLab is integrated with their testing. If they, particularly for software companies that are startups, it can help you check the box. In fact, I should have put the link in here and I didn't. We have a new compliance page and I'm fleshing that out even deeper to get into more of the compliance aspects. But one of the common, lowest common denominators across all of the compliance requirements is that you need to scan your code. So if you are using GitLab to create your code and every code commit and every merge request is scanned, then that can help meet that kind of basic fundamental check box there. Now, Hayden wanted to make sure that I covered objections and I know we're running short on time here. So I'm going to kind of speed through these. What I would love is if you guys have additional objections, please add them to these notes here. I want to take these notes and add them to the handbook. But I wanted to make sure that I'm hitting everybody's objections that you're seeing the most. And I believe the two most common ones are, actually let's say three most common ones, would be that I have investments already. And at this point in today, I wouldn't say that we're ready to displace Fortify and Veracode where they already have those investments, but use GitLab to expand the footprint of what you are testing. So use GitLab to test every piece of code. That would kill you financially to do that with some of these other siloed products. And then use the other more siloed products to do additional periodic scans. Or maybe that's a final scan that you want to do if you're not quite down the DevOps path and you want to, you still feel like you need to have, you know, a customer prospect still feels like they need to have a gate at the end. Use this for the gate at the end and use GitLab all throughout. It's going to save you time. It's going to save you money. It's much less costly to find and repair the vulnerabilities early in the development lifecycle. One of the other objections is that we don't have as, we're not, our security dashboard is not as robust. But you know what? It's a minimum viable product, number, case number one. We are launching more and more robust capabilities and future releases. So get on board now and grow with us. Our roadmaps are public. You can see what we've got planned in 11, 2, 3, 4. You know, you can see what, how we are growing in the past. So get on board with us and join us now. And then the third, actually a couple more objections that we may, that you may face. One would be that we don't have remediation advice right there for the developer. What we do have though is, this is, there is a demo that's in the resources. You can actually see, you know, right here, that I've got 63 new vulnerabilities. And I've got two license management issues. I can jump in here and see what those vulnerabilities are. They are prioritized for you based on potential impact. And they can be changed right here. You can drill down and see a little bit more detail. Again, those capabilities will continue to get flushed out. But that would be, that would be one area to, that you may get some objections in. And then the last one that I think is the biggest one would be languages. There is a page here back in the resources for each one of these capabilities. I would encourage you to go to the user documentation and you'll see the languages that are covered right there. It changes all the time because we're continually adding languages. And I would say if there's a particular, if you've got a really big opportunity with, you know, a customer that's using JavaScript or something that we're not covering just yet, be sure and surface that because it can influence our roadmap and priorities in terms of what we do first. So that's how I would address those objections. Again, please add any others into this document that you come across. I've also started on some FAQs. Again, I will add those to the handbook, but I really, really want you to add what other kinds of questions that you get here. Resources. I mentioned last week we've got the security deck here. If you haven't checked out the deck, be sure that you do that. It's, there's a link here, but also in the handbook right under the pitch deck. We're building out more pages for dev sec ops, for application security testing as sort of an overview, kind of like a data sheet. Joel, I'm going to piggyback on some work that he's done. He's got a great video that he's put together. And you know, I would definitely take a look at that. I mentioned the ROI page. The security lexicon. Actually, under here there's also, and this is where you would also find the security deck. This describes the terms that we use because security has two parts to it. And you may run across this with your customers. There's how we secure GitLab as an application. And that's what Kathy Wang does as our, kind of our CISO. And that involves lots of things about what we do, two factor authentication and so forth, that we do to secure our application. And then there's how we help your customers create secure applications of their own. And that's through dynamic and static testing and all of the security testing capabilities that we have. So make sure that you are aware of those distinctions because you may need to drill down a little bit more when a customer first asks you about security to understand are they asking how we secure our application or how we can help them write secure applications. So I do want to leave just a couple of minutes for questions. And yes, we have three questions. Okay, great. The first one is Phil. Is it safe to say that by not using GitLab, and DAS and DAS and testing and all your code, they might be missing the vulnerabilities? Absolutely. And what's going to happen is, if you're not using any static or dynamic testing at all, you absolutely are at risk for missing those vulnerabilities. And there's a lot of statistics out there, 70 to 80% or more of some of the biggest breaches have been through the application layer. So you really, really, really want to make sure that you're doing that testing. Now where you do it is the next issue. Do you do it at the very end where it's really costly to find a vulnerability and now you have to decide, do I want to hold up production or do I want to go ahead and move it to production and take the risk of that vulnerability being exploited until I can go back and fix it? If you do it as part of your commits and your merge request, then you are, you're nipping it at the bud, right? You're getting it right at the beginning where it's much less costly. And you can do it for every piece of code and not worry about missing one. You have another question? Yes, the next question comes from Simon. What is the licensing model from the competitors? So there's a variety of licensing models. So some are by developer. Some are by the amount of code. There's also a difference between whether it's security as a service or if it's on-premise. Obviously, if you have on-premise, you've got a whole other host of costs that go with that in terms of infrastructure. But it, so it varies depending upon the vendor. But the siloed, the more traditional siloed vendors tend to cost way more than just GitLab Ultimate and all that they are doing is that one piece. Okay, and then finally, John wants to know if you can post the links in the sales channel. Links to... What you were, yeah, your presentation, I'm assuming. Yeah, sure, happy to. Okay. Are there any other questions? We've got a couple minutes. If you have any questions from the Google Hangout, feel free to come off mute and ask them yourself. Yeah, I have another question. So we typically, at least with the accounts that I've worked, they already have a solution in place like a SonarCube vericode or Coverty. Can you briefly explain the advantages of layering GitLab on top at the merger quest level and how that plays with the existing scanning tools that they're leveraging? Yeah, it comes down to the integration aspect. So the fact that we are one application, tightly integrated, there's not something else to maintain. The sales approach that I would use there would be our scope is much broader than a SonarCube. So use us for the pieces that SonarCube doesn't. And if you really like SonarCube, keep using it. And I'd be willing to bet money that at some point they'll realize the benefit that they're getting from that is not worth the cost of the integration and the added expense. We can play with it. That was another question that I've heard come up is, what if I already use XYZ? Great, keep using it. We've got APIs. We can integrate with those things too. But I do think that the footprint that we have is so much broader. If you can get in on any of those pieces of functionality that they're not currently covering or maybe a piece of functionality that's real costly, costing them a lot to cover, then that gives us a beachhead and eventually they'll understand that with one application there's just so many, so much upside to that. It removes some of the head-to-head feature functionality type of argument. Okay, any other questions? We're just about out of time. There are currently no other questions. Okay, well thanks everybody. Appreciate your participation. And be sure and please edit that document with FAQs and objections that you get. I want to make sure that I'm keeping current. Take care.