 All right, thank you everyone for joining us. This is time stamp April 4th. This is the sales and sales session we're going to be covering. My name is Dan Borden, technical marketing. We're going to be covering a click through demo of the secure capabilities. A click through demo is basically a PowerPoint or slideshow full of screenshots that are created in such a way that a person can get the sense that they're going through the product, but it is also guided so things that I'm saying are should be in the speaker notes so you can pick it up and sit on a plane and read through it and practice to yourself. And when you give this or just sent this to someone, we're not hiding the fact that you're not in the product because you can feel what the product interacting with it is like. All right, so who can share? Okay, so you should be seeing my slideshow. Start the presentation. Do that because I can keep it contained within a window. So this is, as I mentioned, the secure capabilities. So this is the secure stage, which is focused around application security. When you start by talking about, there are a lot of tools out there and what we've learned over time and heard from customers again is that the ability to deliver on the promises of web ops and on quick application delivery of quality products is hampered quite considerably by the fact that there has to spend a lot of time maintaining the tool chain and integrating all the different pieces together. BitLab, we have capabilities across all of those stages integrated together working out of the box so that that integration doesn't have to be done by the customer that you can pick it up and you can start using it, put it in and building secure applications. This particular demo is going to focus on this secure stage here that we have highlighted and particular capabilities there around what kind of scan security. Just a quick overview. I think continuous security is what we want to talk about here. The notion of doing waterfall security with iterative development, obviously there's a mismatch there. What we need to do is have iterative application security to match iterative development. If we're going to quickly do small iterations of changes to our product, we need the security to work in the same way. What we're about to show you is that capability how BitLab can enable and empower the development team to become part of the security team by giving them all the information upfront about the security levels of their application and their changes and even the ability to fix and resolve those changes before we get pushed back to the main branch and for the security team to pick it up and start worrying about all of the changes that they're developing. Hey, Dan, your audio is a little bit muffled at times. Sometimes it's okay, but other times some of your words are hard. Thank you. I will try to enunciate better. My head does not quite work so I'm working with my unusual audio setup. Let me know again if I drown out and talk up. Thank you. So we're going to start with planning and creating. This is an area that the development team starts at. And so because we're talking about how GitLab is helping application security, we're going to look at it from the developer's perspective. The developer is going to start by looking at their issues that they're going to work with or they're going to have issues that they're working with. In this case, we have a change that we want to make to the main page. GitLab has issue boards that are usable that can be used to keep track of all the work that needs to be done and what stage they're in. If I jump into that issue, I can see just a quick brief. There's some changes that we want to make to the main page. Normally, I would create a merge request from there when I'm ready to start working on the solution. The issue is the problem statement or the use case or user story we need to solve for. And the merge request is the start of the solution. And that solution or that merge request captures everything around our solution. In this particular case, we've already run through this. And so there's a merge request already created. So we're going to go ahead and take a look at that. So I'm in the merge request. And this merge request, as I mentioned, captures all of the discussion, all of the changes, all the test results, all the information about the change of the developer is working on. I remember the issue is the problem statement. This particular merge request, we see that things started been run through. I can go and I can even see like the changes that were made, for example, we changed the background color. We changed the string. We added a logo here so I can get a quick understanding of what was changed as part of the solution. I can also see the pipeline that ran in order to run that change through and validate and test it. So take a look at that pipeline. And this is where we start thinking about verifying. This is where we're verifying the work that we've done. This particular pipeline is one that runs out of the box when you get lab. It's called auto DevOps. And it does many things. One is which is it picks up the code and it figures out how to build it. And then we're going to focus in here on this area where we're doing a lot around test. And in the test stage out of the box, we're running many different cases of the security application suite. We're doing code quality checks for one. And that's not security based. That's just static analysis and looking at are we making good quality decisions around our code and how we lay it out and the syntax and everything. The container scanning, which is going to focus around the application environment, the container that our applications being put into, because it's not enough just to secure the code. We need to make sure that where it's running the application environment, it's going to be very secure as well. Dependency scanning over here. Is going to look at all of the, all of the other libraries, all the other software that our code, our software is dependent on. And it's going to check those to make sure that those don't have vulnerabilities or if they do, they will flag that as well. So especially in this day where more and more open source software is being used to build at the other software. We want to be cognizant of the vulnerabilities in those libraries. And then it will do, and is doing all these in parallel. So it's scaling out and doing this in parallel, but it will also be doing license management scanning. So this is doing a license compliance check. It's looking again at those vulnerable, at those dependencies and it's understanding the licenses that are attached to those libraries, those dependencies, so that we can make sure we don't accidentally adopt licenses that are against our policy. So for example, I made this organization not be okay with adopting a license that says, I'm going to give away for free all of my code and my software. So that can be flagged in a policy and then license management will scan through every time a developer makes a change to make sure that we haven't adopted one of those licenses accidentally. And again, if you think about it as single code change in, you know, small one line change can add a license or new sets of licenses because we may add new dependencies from that. And we're going to also do static application security testing SAST that is going to be looking at the code itself. And it's going to be scanning for vulnerabilities, looking for things like buffer overflows and known, you know, versions and things that we need to watch out for and repair that could introduce vulnerabilities otherwise. It's going to also just do testing. This is part of security, but it is part of our testing stage where it's going to run the developer to find test unit test functional tests, et cetera. And then once all of these are done running, we're going to kick off a review app. Now, this review app is kind of a little bit of magic here because the lab is tightly integrated with Kubernetes. It's going to take the changes that we've made. It's going to spin it up in an environment that is specific. It's a staging environment specific for this one change of this developer is working on, this team is working on. This is unique. A lot of staging happens further right in the pipeline where we've gone through and actually check the code back into a release branch or to a default branch. And so this is much better for every developer change we're able to do this review app. This allows a developer to actually interact with their application, not just check it based on code. This allows stakeholders to actually interact with their application with their change. And I'm pointing this out particularly in this discussion around our security capabilities because it also enables our ability to do this next stage, which is dynamic application security testing. With dynamic application security testing, we're not just looking at the code. We're actually looking to catch vulnerabilities that happen when you put all the different pieces together. So things like cross-site scripting attacks. We're able to find those. And this is sort of DAST scanning is going to be doing that. But no, to do that, you need a running application. We also do performance testing as well because we have a lot of that. So this is a lot of testing that happens and goes on. And one of the values here is that you don't have to go dig into each of these to go find the results. We actually bring those all back together into this merge request. It's a single merge request around this, again, around the change that the developer or the team is making. And all that information comes back here. For example, here is that review app. I can easily go and take a look and I can see my changes took place. Again, this is a simple app, but we could do a full application. We're going to take a look now at some of the results of those scans, license compliance. In this case, the Walton team can take a look from the merge request or the management team or anyone else of are there any new licenses that were introduced as part of this change. In this case, there weren't, but we can also take a look at the full report of all of the code. And we can see that overall we're using nine licenses of different sorts. I can dig into those licenses and understand, go get more information about it. And we can also see all the packages that we are using as part of our software that are using that license. So we can get a good sense and overview of where vulnerabilities might be. I can block this. If I have the permissions set up in this project, I can block this to license or approve a license so that it doesn't flag or that it does flag. For now, we'll just leave this alone. Again, if I have permissions, I can manage at the project level and I can actually preset a policy that says these are the licenses that are using the ones that we don't want to have. And then that will get flagged with every change of the developer. Moving on. We also did a lot of different security scanning. And I can look at those vulnerabilities again right from the MR and scroll down to give us a little bit of room here. And right in the MR, I can expand and see, I got 59 new vulnerabilities. That was some pretty bad changes that I made there. And those are listed here. So I can take action right here from the MR, from the merge request. For example, this first one, predictable pseudo random number generator. I can go in and get the details. I can go deeper into that here. And I'll just stop for a minute from my, from my spiel to a point out, there is a, this is the kind of shortened version. You see there's a lot of boxes layered on top of pointing out lots of things at once. There's a longer version of this also available, which does go a box at a time, but it also goes a little bit deeper in areas like this, for example, where you can go and actually see the source of the information. And so that's also available. This is the like 10 minute version or so. So back into, into the presentation, I can get more information about that vulnerability. I can see all the details about it. I can from here dismiss the vulnerability. I can create an issue from the vulnerability. Or if the one's already been created, I can do that. So here we'll just go ahead and cancel and come back here. I can also see exactly where in my code, my changes that vulnerability got triggered. So this is very helpful for troubleshooting and resolving issues. If I dismiss the vulnerability, it looks like this in the print in the, in the vulnerability list out, crossed out when I go get details, I can see who dismissed it on the pipeline, more information about that dismissal. Now you may be saying to yourself, well, hold on, we're giving the developers, the power to basically shuffle stuff under the carpet. And that's not the case. If I dismiss the develop vulnerability as a developer, it's going to carry through. So vulnerabilities that don't get fixed are going to bubble up to the project level. So we can take a look here at the project level. In this case, spring up secure server. Right. So that, remember that was on my change, right? And there's lots of developers working on the change for this one project. At the project level, there's a security dashboard that rolls up. It looks at master and then tells me about my vulnerabilities that are in my master branch. I can see that that's like, that's the, that the Cypher one that I dismissed is also still here and showing dismissed. Again, this is at the team level. So you may be asking me, okay, well, wait a minute, what about the security, you know, the security team, the security admins, the analysts, are they expected to go down into all of the different projects and all the different merge requests and look for vulnerabilities to verify that things are getting dealt with. No, they're not. If I switch to now looking at the group security dashboard, and this is where more security admin or analysts will be looking at, I can go up to the group level and a group and get lab is a hierarchical structure that I can make to have, you know, represent my departments or my groups, a larger sets of projects that work together. So there's lots of projects under a group and that group has a security dashboard. Looks a little bit different. That rolls up that information and all the vulnerabilities from, from all of the projects below. I can filter by severity, by report type, by project. I can get an overall view. Hey, there's seven, you know, high, high vulnerabilities here in this, in this group. I can get trending information. So, you know, that live adjusts to what I'm looking at. And I can also see those vulnerabilities again across the different projects. So like in this case, I can see that all of these critical or all these highs are in tests. So I'm not worried about that. I can also get a quick view as an administrator pay. I can see that as a security person. Sorry that, that the vulnerability has been found that somebody's also created a issue against that. So that's going to be dealt with. I can go look at that and I can interact with that person through the system. I can also see those ones that were dismissed that got bubbled up. So I can, and take action on them. I can get more information. I can decide to create an issue and assign it to someone to say, Hey, this needs to be dealt with. And I can dismiss it as well. So at a high level, I have the ability to take action as a, as a security admin. To not have to dive, dive, dive deep into, you know, the merge requests and the lower level. So speaking of, I talked about, we're really about empowering the development team to, to fix the problems before the security admin has to catch them and say, you can ship this, this is no good, right? Let's kick it back. We want those discoveries to happen and be fixed as early as possible. So I'm going to talk about remediation. One of the things we're focused on is what we call auto remediation. And along the way, there's several capabilities that we're introducing to enable that. We're looking at our project here where I found an issue, which is the ability to download the patch. So we've identified what the problem is. We've identified what the patch is. I can look at that. I can download that as a developer and get applied to my code. And then commit that back in to, to have it go through the cycle and resolve the problem. Now the other thing we have that we just recently added in the last release. Is the ability to start the merge request. And apply the fix. So I can do that right from here. Which will then set me up with the branch and everything so that I can apply that fix. Now where we're heading to the, in the fullness of what we're going here is to have those vulnerabilities found and fixed automatically. Now this, we're not there yet. We're working towards that, but you could imagine as a developer, rather than coming in and seeing the message that I have, I can't, I can't do that. I can't do that. I can't do that. I can't do that. I can't do that. I can't do that. I can't do that. I can't do that. So as a developer, rather than coming in and seeing the message that I have, security vulnerabilities that I need to fix. I'll be able to come in and see that there were vulnerabilities and what they have in the fix. And that's where we're going with this. So that is a quick overview of a secure capabilities. So Dan, I had a quick question about the last slide. Yep. Um, so whenever you hit create merge requests, this creates an entirely new merge request rather than just adding on a commit to the offending merge request. Uh, I believe that's the case. Yes. Okay. Because, uh, this change may be right when we do merge requests, one of you small ones that have a small change associated with them so we can keep track of like what's doing, but if I make a merge request and I make some code changes, like I changed the front page and I also fix a bug and, and I also fix security vulnerabilities under that same single merge request. It starts getting larger and having more effect across everything. So we want to kind of compartmentalize. Yes. Thanks. And that is a, what is it? Get lab flow pieces. Thanks. Thanks for your question. Okay. Um, we're going to just keep going through with questions. So, uh, um, so I'll point out, um, before we do that, uh, to find this, I usually like to start, um, to find this and other clip through demos and all the other demos, you can do the Google search. Um, get lab demos. It is the top natural hit. And this is the page where we consolidated all the demos, videos and whatnot that we'd like you to know and learn and use. Um, along here are the clip crews. I'm sure it might happen to be on that with some instructions on how to run them offline. Uh, this is the directory that has all of them. Uh, and they're also just here. You can run them from here as well. These, I believe, are set on auto play. Um, there are some that are on auto play. We can get directly to the slides from here as well. So you can see, there's a few of them. Uh, we have this short one that we just covered. And at the very top is the long run. Uh, the long one does dive into, um, some pieces deeper. Um, that we didn't see the kind of window over the top of, uh, like, um, but basically dive in closer and like only say, Hey, we could create a, uh, a, uh, new issue out of the vulnerability. We actually will take a look at that. So you can see that all the data is holding. Okay. I'm going to stop sharing. Number two, inspire questions. If you guys have typed one into the chat, I probably haven't seen it. Uh, I will take a look, but feel free to verbalize as well. Hey, Dan, it's Dan Astor. Um, great stuff, man. Really, really impressive on the demo there. Uh, one, uh, uh, thing just, it's just a minor point that I noticed on the project security dashboard. Um, you said, you know, it detects on the master a branch, which it does. If that's the default, the only thing that it just detects the default, uh, branch. So I mean, I'm sure you know that, but 98% of the time it's going to be master, but just in case somebody, I changed my default branch. That's why it's there. The only thing I noticed on that, but that's a very good. Thank you. Cool. I'll make that adjustment. No, it's question comments. Uh, there was a question in the chat, Dan, um, from Mike. Is there any demo for how to onboard a project and sast, uh, and make sure it's getting fully. Um, On board a project and sast, um, There's no demo on that particular right now. Um, if there's a method for that, it might be valuable. We can certainly work on that. Um, And by onboarding, I think you is particularly focused on the scan and fully. Yeah. So I can, I can talk to that. Sorry. Um, the, The process for like getting a project in the check marks is a, you know, two to six months sort of task for any existing code base. Cause you have to make sure that the scanner understands the code. You have to make sure that the rules make sense. You have to remove or add or change rules to make the, the results actionable and reasonable. You don't want like a million false positives. You don't want a million false negatives. Right. So there's a whole onboarding procedure that they like to sell as a professional service. Sort of thing. Do we have. Any, any material on how to approach that. At all. Uh, We don't, but I think that's an excellent idea. Yeah. Yeah. So we can, you know, I'm part of it is right. Part of it is, part of the idea here is that you don't need to do a six month onboarding. Now granted. There's a different level of output right now between what we, you know, we. Do and what they, you know, ultimately do. They're, they're the super tool right now. Um, and we're, we're getting, you know, we're working towards that. Um, ability to identify false positives and things like that. I think we'll come. Um, but right now, uh, you know, part of this idea is right. We are looking at what is the software we're figuring out. What do we need to scan for? Part of what the magic that happens behind the scenes is, okay, we're doing sass full, which, which language and, and you know, what, what do we, what do we run? Right. And so we're figuring that out behind the scenes. Granted. That doesn't cover all of the complexities that check makes and show covers today. But that is the start of the path. And the philosophy is that you don't exactly what you're saying. Me, you know, six month engagement by, by professional services in order to, you know, to, to get that level of scanning. Yeah. That's what we're working towards. Okay. Thank you. Again, I would even suggest your autodevops one because that's set up. And that's just, it does what it needs to do from, you know, being set up for autodevops because it's automatically going to call, you know, sassed in there. Yeah. There's a, there's a click through demo like this on auto devops that you can look at that does talk about just getting a piece of software in and running it through the, the system and getting the sass scans and looking at the results. And what is nice is we have recently templatized auto devops so each of those sections of the pipeline are split out into their own discreet CIMO files that you can import. And so we're actually seeing customers create very complex pipelines to do a lot of different things more so than even auto devops does, but then they'll import the sass component or the import one component of the auto devops. So that's another way customers are using auto, the auto devops. Is taking that as a templatized way to do certain types of jobs. I want to, I want to address Larry's question about the find and fix vision. The auto remediation, there are, there's, we're on the second NBC. So we've, the first one was to show that a patch was available to download. The second one that we have right now is to actually create the merge release for that, for that patch. And then, you know, we'll continue to improve and automate even more so we can actually run the pipeline and show the results. That'll be kind of the next part, but so I don't want to leave with the impression that it's a future. It's, we already have it. And someone had asked our other vendors doing that, our competitors doing the auto remediation. They're starting to, not the traditional application security vendors that have been around forever because they're too, they're not as tied in to the development process, but some of the more recent players that take over the DevOps approach are starting to do auto remediation. And in fact, Forester's report that's going to be coming out shortly really points to auto remediation as being a, a key capability going forward for, for the, the leaders in the software composition analysis space. Thanks. Yeah. The demo does show the, the few screenshots of the parts that we've done towards that. And those are, those are live on good. Common in the product today. So there's a question from Simon about, can we scan projects that aren't going through our pipelines? So. We're not really optimized for that. But you can, set what I would do for that is you have code that's sitting in the repository. You can set a, a scan of that grant of your default branch to happen with, with the schedule pipeline that will basically run through and run those scans and get those results. So it is still through the pipeline that is our automation mechanism. But I don't think we're, we're not set up today to break off and saying, just do a SAS scan on this sitting code. Yeah. That's not really the strategy in terms of why you would use GitLab for, for scanning. You'd use GitLab for scanning because it's built into your CICD process. As opposed to trying to, to scan with us and then send it somewhere else. I think it was more like, if there's a thousand projects and a hundred projects, like if there's a thousand projects and a hundred are being actively developed, let's say, but there are 900 older projects that aren't actively developed, but are still used in the company. They would want to have a security audit potentially of whether those live projects that aren't being actively developed are secure as well. That was the, the sort of thinking behind it. Okay. Yeah. For that use case, we do have a plan. I can't point to it off the top of my head, but we do have a plan for that. Cool. Thank you. I had a question. When William was talking about using the template, the YAML template files, and many customers are pulling those in for the scanning. Now, but in the case of, if there are a minority of projects that maybe use some older code that we don't scan against like Cobalt, and maybe they want to scan those with Fortify, are they able to take those templates and do a little customization on it so that Fortify would be brought in and run as part of the CI CD process with GitLab? Is that doable? You certainly could from a pipeline that's a custom pipeline call Fortify or some or any other scanner to scan, to scan code. We don't have a snippet for that or a YAML file for that. Those components that William talking about are specifically offered the pieces that we provide. Okay. Yeah. I think, so I think there's, there's two concepts. One is we have these predefined jobs, things like our SAST and DAST. And previously you had to copy and paste code to get that kind of functionality. And now those individual types of jobs are, they just ship as templates with GitLab. This is a very recent update. So I don't, I wouldn't say we have a lot of customers do this, but I do know of customers do this and we're working to get like some webinars out. All that's to say is that's one bit of functionality. The other bit of functionality, what you're talking about is if somebody is doing some scanning on a language that we don't currently support, could they port that into the MR? And I have heard of that. I don't know, I don't know Cindy, you probably have more depth on that use case. I'd have to understand why you'd want to do that. What would be the outcome you would expect for a language that we're not supporting. So it's not in the repo. You're not doing CI CD on it. I'm not sure I would understand the value of that. Now I can say though, we do have customers that are importing results from other scanners into our pipeline, but not for like the use case, you mentioned COBOL, you know, it's not for something that we're not already handling. The one that I'm, the one that I'm aware of and I ought to dig up the details on it, but I do believe there's a couple, a few customers or users that are, they're doing a scan and that scan outputs a certain format and they're doing a data transform on that format to put it essentially into the JSON format that our UI component ingests. And so that on the MR, they get not only our scans, but this other tool scans are also showing up in the MR. I see David perhaps nodding has had, maybe you're familiar with that one. Yeah. Thanks. You're exactly talking the case that I did, the one that I'm familiar with is that, you know, we're looking for a particular, like I said, JSON format for those results. You know, this is kind of a, you know, I don't know, it's you know, type approach here, but if you were to get the results of whatever external scanning tool into these appropriate exact format that we're expecting, then it's quite possible you could get at the show in the first place, but if that format changes in any kind of way on our side, then of course, and that format's not going to show any longer. So that's, I've heard of that working in that sense. Yeah. This is a non-supported use case. Exactly. Well, I guess I had a similar question to that or maybe the use case. So I've had a couple of questions from customers and kind of the bottom line is when we talk to the security team, they're most worried about the fidelity of the system. Right. When we talk to development, they want to understand how do we get it in the pipeline? How do we shift it left, et cetera? But the, the security team, the InfoSec team is really worried about, Hey, how do we match up against either existing products that they already have that's doing type of security? What's the fidelity of it? And I think they see the feedback I've gotten, it seems like, okay, we see you're early on in that journey. And maybe we'll reevaluate you later. Hold on. I'm sorry. We're four minutes over. I think this is a great discussion. So I had to cut it off. I think we can have a whole separate. Session on this and we should, we know there's some, some work to do here. This is a, from the perspective of presenting what we do have. That's what this is covering. And I want to cut it off at that. And let's maybe, maybe say we can set up the next discussion to go deeper. Yeah, I think the positioning would be important for y'all to understand in terms of, there's a difference. Those that have incumbent products and those that don't, in terms of approach. So, so Brad, and everyone else, we'll set up separate discussion to go deeper into that and cover that with enough time rather than rushing the answer in the end here. So thank you all for, for attending. I hope this was helpful. Send us feedback.