 All right. Well, thanks, Cindy, for joining me. This is Joel Kruzwick with Cindy Blake here at GitLab. And we're just having a discussion around security topics today and thought we should probably do a deeper dive. And so when we look at something like GitLab and we see how broad it is, it's kind of easy for some of those those really important features to get lost in the grand scheme of things. And so as many people are aware, GitLab's great at source code management. And a lot more people are also aware that we're the home of an award-winning CI. And so from that perspective, we kind of wanted to just touch on what GitLab actually is up to these days, how broad it goes before we get into that security topic. Just because, you know, as you can see on your screen before you, we do go from planning all the way through monitoring in a single application. And so many people that we engage just aren't aware that that's actually the case. And so we wanted to kind of highlight that before we jumped in on more of the security phase, which you can see we've tucked under verify. Cindy, I don't know if you want to comment on this or take us to the next level. Yeah, sure. Let me, you know, security really spans the entire software development life cycle. All the way from planning through monitoring. The application security testing probably fits most closely under verify, but to be honest with you, we struggle a little bit with where to put it visually because it's not really at the end. The way we do it, it is clearly embedded. I guess let me start with what we offer around application security testing. So we have static dynamic container scanning, dependency scanning, and license management. And all of this is built in and automated into the end to end application of GitLab. So with every code commit, all of these tests are automatically run. So is this something where it truly is components that are part of the GitLab ecosystem or is this something that GitLab is orchestrating external solutions for me? Well, we can do both. We offer our own testing for all of these things. We can also integrate with APIs other testing tools. But the beauty of GitLab is that if you use our CI CD capabilities and you subscribe to our ultimate package, you get all of this. It's not separate tools that have to be stitched together. They don't require integration. They don't require a separate management license, a maintenance, ongoing maintenance, and keeping up with the APIs. It's all one tool. So we can dramatically simplify the DevOps tool chain and the security tool chain that comes to play in there. And this is a pretty broad array of offerings here. So when we look at the marketplace, it seems like this is something of a unique offering, taking this and truly doing a shift left functionality of all these items. Yeah, let's talk about the shift left for just a minute because a lot of people talk about shift left. In fact, it's kind of getting beat to death right now. Yes, it is. But what that means, though, is people want to find vulnerabilities earlier in the lifecycle and fix them so that they aren't fixing them later. An analogy would be you get your mail in from the mailbox and if you throw it on the table and then five people in the family have to look at it and finally it comes back to the first person that needs to deal with it, what if you just dealt with it when it came in? Same sort of scenario in that we can be much more efficient and effective if the developer is able to find the vulnerabilities and resolve them right there because a traditional workflow requires that some of the static scanning can be done by the developer. In fact, some of the vendors have light static scans that are kind of like a spellchecker. So as the developer codes, it will identify insecure phrases and point it out right there and give you remediation advice. But it can only go so far and it's still very siloed and separated from the rest of the testing. So typically you might do that upstream but you still would have to do some additional static scans and then you've got to do your dynamic scanning once you have a working application, which usually isn't until you get all of the individual developer's code merged into an application and you get it into the test environment and that's typically where dynamic scanning occurs. But with GitLab, because we are one tool, you can, at the point that an individual developer commits their code, it's automatically scanned for all of these tests and the results are delivered right there to the developer where they can fix it. So think about the workflow that you're cutting out of that. You're normally a security person at the very end is running the scan, finding the vulnerabilities, has to report that back to the developer. By that time, it may be the next day, the next week, the next month, the developer's already on to another project. They have to kind of re-engage and rewrap their mind around the application they were working on and figure out the remediation, the security person's spending an enormous amount of their time just tracking all of this. What are my vulnerabilities? What's the priority triaging them, following up to see which ones got resolved, which ones didn't? Well, if it's all part of the same one development process, you can eliminate a lot of that and you can tighten up that iteration. As people are trying to do DevOps and have smaller pieces of code, so committing code monthly, daily, weekly, whatever, smaller chunks of code, this sort of process allows security to be married and congruent with that so that your security scans are also on those small code commits and you deal with all of that up front instead of waiting for an avalanche at the end. Yeah, I'm a big fan of that with GitLab, the idea that we can collaborate in one place and everybody from the product and business side and the developers all the way through to security and operations, we're not in those silos anymore. And I think it's great for everybody, right? Because not only are we not waiting on security personas to come through and actually do the analysis, but now we've actually got the visibility to that before anybody from security gives a checklist for us to fix. We can already see this is coming. The pipeline ran and there's problems. Exactly, and if I create the vulnerability, if I know how to resolve it, let me resolve it rather than committing it and finding it down the stream for it only just to come back to me later. So we're really empowering the developers rather than just trying to push some things further upstream. Perfect. Yeah, so one of the ways, one of the biggest things about how we're different is it has to do with the merge request and the pipeline. So everything is triggered by that code commit and everything shows up in the pipeline report of the merge request. So even DAST, and that's really different because when you think about having a working application, GitLab has a review app. So when you commit code, a review app spins up for you to do QA and look and make sure that your change had the effect that you wanted it to. Well, at the same time, that application can be used for your dynamic scanning as well. Sorry about that beeping in the background, can be used for your dynamic scanning as well. And so that's something that application security vendors that are siloed can't do. I mean, they just don't have the visibility because they don't have the repository for the code. In fact, you know, there are some vendors that wanted to show how they do incremental scanning. That's been the big buzzword for the last several years in application security is let me do incremental scanning and just scan what changed. But because the AppSec tools sit outside of the code repository, it's hard for them to figure out what changed. But when it's all one tool, it's an integral part of what we do. It's an integral part of what we do. Yeah, I think that's another piece to that puzzle of how we're different, right? Is the fact that these are running on every commit. And so a lot of times, not only are we waiting because of the complexity of the tools or the tools not living close enough to the source code, but also just from a cost perspective, right? We're not charging per line of code here. There's no limitation on how many times this security scan can be executed. Exactly. So one of the problems that we solve is customers often have to choose what they're going to scan because it's too expensive to scan everything. And so with this approach, you can scan every piece of code all the time. I'm hoping we can kind of coin the term continuous scanning, continuous security because that's really what we're doing. And then in addition to that, we're also empowering the security professionals to focus more on the things that the high value activities. So if a developer is resolving more of the vulnerabilities while it's within their domain and their desktop before they ever commit the code to merge with the rest of the branch, by the time it gets to security and all the developers have done this, there should be far fewer vulnerabilities for them to deal with. And it's only those things that have not been dealt with by the developer. So these are the anomalies where either the developer isn't sure, could this be a false positive? Is it really a vulnerability? Or maybe they don't know how to resolve it. Sometimes the way things are coded, it's very difficult to resolve the vulnerability and so maybe they need some assistance or maybe they are choosing to leave it there because the way the application was written and maybe it's a legacy app and the way it's written, it's just too difficult to make the change. And so either way, the security person is seeing what's left. They're seeing the anomalies that are left and only having to deal with those but let's say the developer said, I just don't know about this one. The security person can look at that same code and you don't have to worry about they don't necessarily have access to change the code but they can see that same code and so it's really going to help the collaboration between Dev and security and get them on the same page. They can collaborate, they can do it real time or they can do it asynchronously. We do a lot of things asynchronously here at GitLab and it really makes our workflow move faster. Well, so let's take this idea and shift the conversation slightly into the strategy of how GitLab implemented this because obviously there's a pretty broad swap of tools here to develop in a pretty short period of time and the idea being that we want to cover as many of the popular languages as we can with as many of the open source options that we could encapsulate as well as some of our own unique offerings. Just what are some of the details available on that? Yeah, sure. You can drill down into those details on docs.gitlab.com. We've got all of the... There's a page there for each of the types of testing that we do, SAS, DAS, and so forth. And it also shows the languages that we cover and the tools that we're using. We are using open source tools that allowed us to get started very quickly and we will continue to build those out and build out the languages. Excellent. Do you have any other questions, Joel? Well, I think we've kind of talked a little bit about what it looks like and we've talked a little bit about some of the uniqueness of what GitLab's offerings are. Maybe we could take a look at an actual output of some scans that have been run and kind of walk through what that looks like and what it's telling us. Absolutely. That's a great idea. So I mentioned that all of the information is in the pipeline report for a given merge request. So here we're looking at a merge request and this is the pipeline report. You can see here a summary of the vulnerabilities that were found. Before I expand that, we've got license management here as well. Just makes sense to put all of those kinds of compliance things in one place. If I expand the security elements here, I can see all of the SAS items that were found. You can see all of the dependencies that were found, container scanning, and the dynamic scanning. So it's all here in one place. Now, these are ordered in terms of both criticality and severity and I can drill down on each of these things. And the really cool thing is, again, because we're one application, right from here, I can dismiss the vulnerability or I can, well, I was going to say create an issue. Somebody already created the issue for this particular one and so it's telling me it's there. I can view the issue. So in fact, the issue was generated here and so you can make comments, add to it, prioritize it, assign it, what have you. I just backed out of it, didn't I? The other thing that you can do is drill down. Let me get back to where I was here. You can drill down to understand a little bit more about that particular vulnerability. Let me pick a good one here. So it's got a little bit more information about what the problem is, what the solution is, how to remediate it. So if you, and this one also has the issue already done, but if it didn't, you can say create an issue and it'll automatically populate a lot of the fields for you. So we're trying to automate as much as we can and make it super easy for the developer within their existing workflow to take care of these issues. And I assume then if we're seeing some things that are scratched out, we're seeing some red X's and green check marks here, it's kind of giving us the status of our actions against these vulnerabilities? Yes, yes. So when they're dismissed, it gets aligned through it. So you still see that it was there, but it's been dismissed. And so you could go back and look, one of the really beneficial things about the GitLab overall, not just from a security standpoint, is the auditability and traceability. So you could go back and look and see that the vulnerability was dismissed or maybe it shouldn't have been or you can drill down and still see the details of that even after that fact. Excellent. So this is at the merge request level. So this is our collaborative hub for the project here. There's also the security dashboard that gives us that bigger picture. There is. Yeah, if you come to the home here and click on the security dashboard. Now the dashboard is for the project and we are working on a dashboard that's cross projects at a group level as well. But it has the same kinds of information. So it has each of those scans that we're done. They're not all populated here, but it has all of the SAS, DAS, dependency scanning, container scanning and license management. And these are going to be a subset. Well, maybe a super set depends on how you look at it, right? They're not necessarily going to include all of the things that the individual developer saw in the merge request because if the developer resolves them in the merge request, they won't show up in the dashboard. So the dashboard has the things that are not resolved. So I think most security people would be thrilled to know that a whole avalanche of work has been taken off their plate. And what's left are the things that where the developer needs help. And so I'm not a security person per se, right? I am certainly concerned with it, but it's not my core job function in what I do day to day. So help me out from a big picture perspective. Why did we drill into these different areas as far as the different security arenas go? So I mean, we've talked a little bit about SAS and DAS, but dependency scanning and license management and container scanning, what made us tackle that variety or those particular five areas and put them under one umbrella? Yeah, sure. So the reason they're under one umbrella is the only individual that can fix all of those things is the developer themselves. So we want the developer to see the results from all of those scans because they're the ones that have the capability to do the remediation. In terms of dependency scanning and container scanning, SAS and DAS have been around for a long time. SAS was first. So that static code analysis and dynamic has been around some of the folks that have been market leaders have fortified. They were a market leader and have been so since 2006, I think, is when they were founded. But the market's changing now and it's changing very rapidly. There's two dynamics that are happening. One is automation with DevOps and tools. So the growth of Jira and Jenkins and Atlassian get repositories and all of that really fueled our growth because we represent an easier way of doing it with a single tool. And we're continuing to expand our capabilities to continue to replace tools and simplify that tool chain. So that's a part of it. The other part of it is the growth in cloud. So as people have really embraced cloud as their cloud-first strategy, they've also embraced containers. And there hasn't been until recently a lot of testing for containers. So dependency scanning is really around third-party code. The way that code is done now used to be back in COBOL days. You had one developer that worked on one application and all of the code in that application. That's not true anymore. Now it's divided up and lots of different developers are working on pieces of the code. And that's why CICD becomes important to merge those things back together and rebuild that into one piece. And dependencies are third-party libraries that you're calling and using somebody else's code that they've written. So you don't have to reinvent that wheel. And the growth in open source and third-party code has been phenomenal. I wish I had the article handy, but if you Google it, there's all kinds of information out there about how much of our code these days is from third-party. So we're skating to where the puck is, and that is around open source and container scanning with cloud and with DevOps. So last question I have for you is, I see that there's a number of vulnerabilities. The screen looks pretty good to me overall. Some of these, I know some of my personal scans have turned out enormous numbers of vulnerabilities. What's my advantage to having it managed by GitLab, basically, or being able to manage my vulnerabilities in GitLab like this versus if I'm using a variety of other tools or obviously working in one place is good, but I'm just looking at the sheer number of vulnerabilities we can encounter day-to-day now. Well, if you're knocking more of them out earlier, you should have fewer than you would normally have had. The real advantage, though, is that you don't have the friction that you would have when you have multiple systems involved. When you have silos of tools, the security scanning tool finds the vulnerability and the security analyst is going to look at that and decide what to do with it, but then they either have to issue a ticket back in the ticketing application, which is probably yet a different tool. The code repository is yet a different tool, so understanding exactly where that code is sometimes is not really clear, whereas here you can drill down very specifically. So there's just so many things that you can't do when you're dealing with a patchwork of tools that are put together with APIs, not to mention the fact that somebody has to manage and maintain all of that. So with one tool, all of this information is in one place and there's one source of truth between security and development. So everybody's looking at the same thing, everybody's collaborating and working together on the same thing, and all of the steps in the workflow can be automated much more cleanly. Yeah, it reminds me there's one thing that we didn't talk about, and that is the fact that all of these things we've been looking at here today are part of AutoDevOps, built into the AutoDevOps functionality of GitLab. I'm a huge fan of that, and I've always seen that as establishing like the baseline of the best practices for what should be in a pipeline today. And it strikes me that we built that in as part of the core, right? You build, you do a basic test, you run a code climate analysis to check your code quality, and everything surrounding that is security, security, security, right? We've elevated that core requirement of what a pipeline should be to being very security centric, and it strikes me that that's no mistake, right? That's definitely pointing to, like you said, skating where the puck is. Yep. Yeah, it's exciting. We are changing the game for application security. Awesome. Well, thank you very much. Any parting words? Be sure and check out our handbook page for your Google GitLab handbook security. You'll find some information there. Also, solutions, gitlab.com, sorry, about gitlab.com slash solution slash dev sec ops with hyphens. You'll find some additional thoughts there. I mentioned the documentation. If you want to really drill down and see what language languages we cover and what tools we use under the covers, it's all there. Very good. Thank you. All right. Thank you.