 So, hi, I'm Cindy Blake. I'm the senior product marketing manager focused on security or secure products at GitLab. And today's topic is going to be around security. So let me share my screen here, make sure I share the right one, y'all don't want to see all the edits I'm making to different things. Okay, so I just made some major changes to the security deck. And I thought this would be a great opportunity to go over the deck with you. The way that we talk about security is continuing to evolve. And I think we're getting smarter around who we target and the kind of discussion that we have. And so I wanted to update from that standpoint, wanted to show you the changes to the deck. And then also we have the security dashboard that is launching this month. Well, we've had a dashboard, we've had an NBC one. We are continuing to evolve that. And so I want to be sure and cover that as well so that you're prepared to talk about that on the 22nd. So in the deck, the way, let me explain. Actually, let me start here, because I think this is important. I added a section here on using this deck. So when do you use this deck? It's really intended for an audience of somebody that wants to learn more about how we do security how our security capabilities work for application security testing. It assumes that they've already seen the main pitch deck. So I'm not repeating things that are in the main pitch deck. You know, in terms of what GitLab does and who are we, who's our executive team, who are main customers, all that kind of good stuff is still in the main pitch deck. I kind of took some of that out of here to streamline it a little bit. When you're qualifying a lead, make sure that you are talking to the right people. So from a security standpoint, the main people that are going to care about what we do is the CISO, the Chief Information Security Officer and the CIO. And increasingly, at Dev, if there's a VP of development or something like that, is going to care more about the security elements than what they used to. This is something that's new, that's kind of evolving. We had a great conversation with a Gartner analyst yesterday, and he kind of confirmed that the development leadership is starting to look at security as one of many kinds of flaws that need to be fixed. So the whole idea of shift left, have the developers fix what they can, is starting to take hold. Now, that's not to say to ignore the security folks or the application security folks, but they're probably going to be ones that could be more of a roadblock that you need to convince, but not necessarily the ones to take the initiative to start the conversation about how to make the development process create more secure code. Does that make sense? Pause there in case there's any questions about that. Okay, so when you're using the deck, I wouldn't spend a lot of time on this slide. In the US we have a term, don't beat the dead horse. This is something everybody knows, they get it. Security's big, it's important, everybody's worried about it. There are notes in here, I can't get my notes to reopen, but there are notes in here that can help you script the conversation, but don't spend a lot of time on this. So it's important, but what makes it more challenging is that the DevOps piece. So everybody's trying to move faster. So how do you take something that's been gated at the very end and plop it into an agile environment where things are very iterative and bite-sized pieces and fast and the two don't mix real well. It's all a balance of risk and agility. If you're talking at the sea level, this is what they care about. They don't really care about how things are done. They care about the what and the what is help me balance the risk, the cost and the agility. And this slide is in the main pitch deck that says the tool crisis is real. And this is real for security too. So I want to make sure this is where the two kind of dovetail and you need to make sure you're making the point. If they're trying to fit security into DevOps, they're also probably trying to figure out how to weave in their security tools into this whole DevOps tool chain. So that's why we have Secure here. You know, we've got Sneak, SonarCube, Fortify, FairCode, all the different ones, right? People are real hot on APIs to connect those with Jera and Jenkins and all of those things. And in fact, I picked up this brochure from FairCode. I'm actually going to have Luke take out the CA FairCode to make it more generic. But this was a FairCode flyer that they had in an event. And it shows the different tools that they have just within CA FairCode just for security. So you've got a compounding issue, right? You've got all these DevOps tools that people are trying to stitch together and make work. And at the same time, you've got these different silos even within application security that then have to be stitched together and interfaced with that whole tool chain. So it just compounds the problem and gets much more complicated. And what you'll see is companies like FairCode and Fortify, their answer to shifting left is to have this piece that's on the far left here in the under code and commit. It's a SAS static application security testing light version that plugs into the developer's IDE. Usually the ones here, Visual Studio Eclipse, I guess CA does IntelliJ. I don't think Fortify does. And it acts like a spell checker. So as the developer's coding, it will flag insecure phrases, vulnerable phrases that are created, and the idea is to stop those vulnerabilities and correct them right there in development. But realize this is a separate product. I'll be happy to sell you this separate product. It's kind of standalone, separate from the full static analysis, separate from dynamic, separate from dependency scanning. All of these things are separate products that you have to buy or license. And then these vendors create a dashboard to try to stitch it all together so that you can get one view of all of their products, which the dashboards, by the way, don't cross products. So if I'm using FairCode for my SAS light and I'm using Fortify for my dynamic analysis, I've got two things that don't talk to one another at all. So this is where the story really, and I've still got comments in here, by the way, because I am trying to finalize this. So I'm taking comments on the deck itself as well. But this is what resonates at a C-level. CIOs and CISOs is to simplify that whole tool chain. And because we have one application that crosses the entire software development life cycle, not only do we simplify it for, you know, code repo, CICD issues, all of those kinds of things, but we simplify it for security, too. And that same message really resonates with this audience. And the reason this is not an allergy thing, the reason for the make a wish is that little girls at least like to make a wish on a dandelion. But anyway, Dan was making fun of me for that. The idea is scan all the code every time using fewer tools, not more, and have a single source of truth that gets dev and security on the same page. And I'm going to show you a little bit about the workflow because the workflow is an incredibly powerful conversation that you can have around the single source of truth and how things get done. And by the way, the conversation with the Gartner analyst yesterday reinforced this scan all the code every time. In fact, he had an analogy that he used, which was kind of like going to the doctor. So you go to the doctor once a year for physical, you get your blood work, you get maybe a chest x-ray, whatever. You get all kinds of tests done, right? A deep scan, so to speak. But throughout the year, you know, you manage your health with less invasive things like taking your temperature and you might go to the doctor for, you know, a cold and they're not going to run that whole panel of things. They're going to do a subset. And so think of that same analogy with us. You scan all the code every time. It's not as deep. It's not as thorough as a fortify or a varicode, but then, but we're also not as expensive. So you save that really deep scan that takes a long time to finish and wouldn't fit into that workflow where the agile workflow that's all very iterative and quick. You save that for, you know, once a year, twice a year. You do these automated penetration tests, that sort of thing. So that's a really good conversation to have. I'm going to pause. I see lots of chat. I'm going to pull up chat for just a minute and see. The first set of questions, Cindy, is really around the positioning of security in the broader chart. Should it be on the right? Should it be? Which is interesting because we talked about that with the analyst yesterday too, to a degree. Not the exact chart, but the concept of where security fits, right? Yeah. So I hate that Secure is on the far right because that's exactly the message we're trying not to convey. Secure is in the, you know, early or in the middle. I moved it. Sid moved it back. Still have to have some conversations around that. But so, yeah, we'll work on the diagram. So the next question they had, if someone decides to use a third party tool set outside of GitLab, would those results still show in our security dashboard? And what about integrations? Well, I'm kind of jumping ahead there to the dashboard, but we have an API. If they feed the results back to us in the expected format, then it can show in the dashboard. And we've got a big debate over pushing that versus the one application. And it's still kind of up in the air in terms of strategic direction, where we want to focus. But if you have a customer, I wouldn't expect, in fact, Phil has a couple of slides that I'm looking at pulling in here a little bit more. The idea is you're not going to rip and replace everything all at once, right? So you're going to make headways in different areas within here. Security may be one, and it may not. It might be that you make headway, you know, you get rid of Jera and GitHub and eventually they add security, what have you, they're not going to rip and replace on day one. So the concept of those integrations is an important piece. So Vivian wants to know if you can share this with resellers? Absolutely. Okay. Simon Williams has got some discussion going on about an issue where they're talking about layering and some things. And I think that conversation is okay for now. Some more comments about shifting left between maybe putting it between verify and package. Let's see, maybe have security in both columns, right? Then we've got another question. Do we have any experience or security replacing an incumbent tool? So do we have experience doing that? I'd like to say yes, however, I can't point you to a specific customer. Most of the security efforts are still in proof of concept. But John May, I think has a customer in the financial space that I could be wrong. That said that they went from scanning, what was it? And I'm trying to capture this into the customer anecdote page, but they went from scanning like twice a year to scanning, you know, 300 times a year. So if anyone's listening and is familiar with that anecdote, please send it to me. I want to put it on that customer page. But I'm working to capture that sort of thing right now. It's not so much about replacing, as I said, replacing a fortifier or a vericode as much as it is using this alongside and using it to pull the whole staging environment into much earlier in the life cycle into development. So right now, let me go on to the workflow because I'm kind of getting ahead of myself there a little bit, but I'm going to show you the workflow because I think that that's really important. I think you've got most of the questions answered right now anyhow. Okay, and I'll come back to those if not. Sorry, see a spelling error. So the idea is, you know, we're one application end to end. And what that allows you to do with security is some things that application security alone can't do. So if you think about all of these tests being done in the verify stage, I want to walk through a DAST example, because if you tell a security person, we can do dynamic application scanning in the developer's IDE. They may not believe you, and they may discredit you as you don't know what you're talking about. But this is where it's really important to explain, this is true. And we are very different than the other asset vendors and our secret sauce is that review app. So if you did DAST with in the traditional manner, DAST dynamic application security scanning requires a working application. So it'll throw things at it and test how the application behaves. So it's not just looking at the code and looking for vulnerable phrases. It's watching the behavior of the application. Well, in a traditional environment, you don't get that until you've done your code commit. You've merged your branch into everyone else's and then you're in a test environment. And so it's not just my code, it's my code and your code and your code all put together. And now we have a much bigger tangle of things to untangle if something's not working right. And in a test environment pretty far down the food chain. So I've got now somebody else running those tests, usually a security person. And when the security person finds the results, it's usually in very deep security jargon that may not make sense to the developer. So there's a translation issue. The security person has to then give that information to the developer and say, here's what we found. I need you to fix it. And then it may be a couple of weeks later, they may already be onto another project. So they've got to, you know, adjust their context, get back to the other project. Kind of wrap their head around what, what was I working on two weeks ago. And there's a lot of friction in that system. So by having that review app, we can do the, let me jump here actually I may reorder these. The review app is a working application. And it allows the dynamic testing to be done on the review app in that individual developers workspace. So before they've merged their code with anyone else's, they can see if what they created causes any new vulnerabilities to be found. And that's something that is very, very unique to us that no other app segmenter can do, because they don't, they're not one application, they don't have that visibility. So another, another part of this, it's true not only for dynamic but static as well and is we report on the delta in what, what was reported before. So if I've already reported a vulnerability, and I rerun that, that code commit. I'm not going to, I'm not going to report it again in my dashboard so the, and I'm getting a little bit ahead but in the dashboard the dashboard is a some of all of the remaining vulnerabilities that the individual developer couldn't resolve. In a traditional sense, if you go back to, to this picture, I run all my code that's all merged at the very end. And my security people have to sort through all that figure out what's most important prioritize that make sure that those things are not false positives and try to give the things back to the developer that they care the most about. The way we do it, the developers already dealt with the things that are highly important, you know, prioritized in their in the pipeline report. And it's only those things that are left that they can't figure out that are going to show up for the security guys in the dashboard so guys gal sorry I'm text and we call we use that both ways. But in, so in the end, the using get lab you should have far fewer vulnerabilities for that security person to have to weed through. And so this really represents change order here this really represents a fundamental shift. This is friction. There's, there's lots of benefits to focusing the conversation around the change in workflow. Now, here's how the vulnerabilities are reported in the pipeline report. I added this into the. I took out there were a lot of click through demo pieces in there before that were kind of outdated. I've replaced it in this deck with some more current screen screenshots. And this is how I tend to work through the conversation with a customer so you show them the security results right here. You can see the new vulnerabilities that shows up in the merge request. You can expand upon that. So it this expand button over here to the right gives you the details of the individual tests that were done. You can go on any one of those and continue to drill down and it's going to show you more details maybe some remediation advice, and from here you can dismiss the vulnerability or create an issue. And so that's really powerful because it's not, you're not context switching you're not integrating with a ticketing ticketing tool. It's all in get lab. So back to the, the dashboard being a summary of the vulnerabilities that were found. But this view is across projects. So what we have right now, it looks very similar to the MR report pipeline report. This is the dashboard. And what we're adding is and, and by the way, this is across projects, we're adding across groups. And in the notes, there's links to the issue so that you can see the actual mockups of the dashboard. So if you have someone that's really interested in it. And it's much more graphical and pretty and the UI team did a fantastic job. To, to make it, you know, some good eye candy here, but that's the direction of the dashboard. The first iteration of this cross group dashboard is only going to include static application testing. So we had to break it into chunks. And that was the way that we chose to, to divide it up so the first iteration is just for sast. We will be adding Dast and dependency scanning and those things to this beautifully, you know, beautiful graphics dashboard over time. So one other key point here and I want to save time for Q&A. I'm just about out of time is the compliance fees. If you haven't checked out the compliance pages, it is a good conversation to have. We focus a lot on application security testing. But compliance is probably more interested in those things that are like functional controls, policy controls. If you go, in fact, let's jump over here to the financial industry page. There is a video out there with Sid using this page to pitch to financial services target. It is kind of funny to watch too because he was in a silly mood and has rainbows coming out of his eyeballs in that video, but anyway, if you talk with someone and they're interested in audit and how do you verify that, you know, code control. This is a good place to go. There's a financial page. There's one for HIPAA, which is health care. And then there's a kind of a general compliance page that is a little bit more broad across everything. This auditing really applies to everybody out there. They're all interested in audit logs and so there's capabilities. These are not part of the security scanning capabilities, but these are just features in GitLab that contribute to the auditability and change management that are good to highlight. So I want to make sure to bring that up. And Cindy, Cindy, just for clarity, those audit features that you're talking about, are they within the entire platform or just ultimate? Thank you. Are they within the entire platform? You know, I didn't look at it from that standpoint when I put this together. So things like, you know, obviously the security line is only for ultimate, but protected branches and two-person access controls and artifact retention. I don't know. That's a good question. Larry, let me think about it from that standpoint. Thank you. Cindy, there's a lot of conversation going on in the questions here. But one of the questions brought up was, and this may be outside of scope, so maybe this is for more, this might be for one of the basic trainings, but at a high level, what's the difference between SAS-DAS and container scanning? So I don't know if you can say that in a couple of sentences here, or maybe that's a follow-up training, right? There's some training out there that's kind of Security 101. I would encourage you to look at that, but in a nutshell, static looks at the code itself. Dynamic looks at the behavior of the application. Container scanning looks at the docker image. It's oversimplifying, but dependency scanning looks at third-party code that you're pulling in. So there's known vulnerabilities for open source code libraries, and we look to see if you're using any of those code libraries that have those vulnerabilities. License management or license compliance, I'm lobbying to change it to compliance, is really, am I using the library in a way that conforms to its license limitations? So you might want to read from about 916 on, if you look at the chat, Cindy, and you might want to comment on some of this and really good points people are making here. You might want to comment on them. Okay. Yep, let me just stop share so I can do this, have a look. Cindy, I've got a question. So we're surfacing a lot of information with our security. What are InfoSec and developers supposed to do with this information? Like how are they supposed to actually remediate the issues? There's a concept of like with network security and endpoint security blocking, like somehow protecting your environment. Application security is different because it's code, right? So where does that come into play? Yeah, so that's why it's so important that we're shifting the security capabilities to the developer because they're the only ones that can remediate or fix the vulnerabilities, right? So as you drill down into that, the vulnerability findings, it'll tell them what's wrong and they can go in and fix it. And if they can't fix it right there in that iteration of code changes that they're doing, they can create an issue and then it can be changed in a subsequent sprint. And it's the developer that has to do it right now in traditional application security. You've got the security guy finding the vulnerabilities and going and having a conversation with developer to try to convince them to make the change. This puts all of that, it empowers the developer to find them and fix them on their own if they can. Yeah, just to add to that, I talked with a client that their whole infosec team can't even track back who introduced the vulnerabilities. So there's this huge bottleneck that happens once the infosec team runs those scans and finds the vulnerabilities. So having it in the merger quest makes it traceable trackable back to the developer, which is which is really huge. Yeah. And, um, and John, Larry, John answered the question here audit logs are in premium. Thank you, John. Thanks. So there's a white paper coming out soon, hopefully it's been written for a couple weeks. And that is going to focus on work flow. And I would encourage you to give that to, I'll put it in the slack channel as soon as we get it, though, they want to track it. So there will be a link track with a tracking link. And I would encourage you to use that with your customers to really go deeper into the next step after you've had this conversation with them, you can give them the white paper to dive further into the whole workflow element. I'm not seeing too many more questions. I know we're out of time. If you guys have any feedback on this deck, I'm trying to get it finalized and posted out there. Normally this the so the security deck is linked from the PMM page and the handbook. It's always out there always available. What's out there right now is not this version. This is the version that I'm working on to replace that and I want to I want to get it pushed out there but I wanted to see if anybody had any major suggestions or issues with it before I did. I'll probably get that out there this afternoon, unless, unless there's something that's way off. Any other comments questions, any other big ones I didn't get to I'm trying to read through everything. Okay. Well, thank you all appreciate your time. Take care.