 Okay, so we're going to go ahead and get started. Samir Kamani is one of our solution architects in the civilian team, and he's going to give an overview of GitLab. Welcome, Samir. I am a solution architect, as he mentioned. I support a portion of the civilian team. My background is software engineering. So I was a developer, propeller head for many, many years, and I came through the ranks of doing waterfall many, many years ago. And I remember distinctly about four years back when a project manager sat me down and said, oh, this is great. We've got this wonderful project plan where you've got your development, your test, your production stuff, and it's all waterfall. It's awesome, but we need to crash it. And I said, excuse me, crash what? What do you mean crash it? And he goes, can you do this in this much time? And I just looked at him like, no, how do you do that? And he goes, well, that's your job. You're the creative guy in the room. You figure that out. So I still remember it. I still talked to him once in a while and I tell him I've got an answer now, except I'm about three years, four years late, but anyway. So I have 10 years of experience in government sector, lots of federal, state, local development stuff. You name it, all kinds of compliance frameworks and checks and the NIST 853 is kind of like, stamped into my brain pretty well. So that sort of stuff. And then to add to that, I did about three years worth of work in cybersecurity. And boy, that's not dog years. That's like dog years times dog years type of work. So you learn just so much just by being in the cybersecurity industry. So that's sort of the background. And what I'll be talking about is security in DevOps, right? That's a big hot topic these days. I'll get into the details about that. And then I'll talk about how GitLab is approaching that. There are many approaches, there are many ways to slice it and dice it. GitLab is in a unique position in being able to do that in a very effective way and that's what I'm gonna be talking about. Hopefully we'll have enough time for Q and A. I do tend to talk a lot so I might go a little bit over, but I apologize for that if that happens. All right, so first tell me about you. How many of you know DevSecOps is, right? So, all right. Some of you might have already run me out of the room and said, DevSecOps, that's not a thing. DevOps is a thing and Sec is just everywhere. Well, yeah. But sometimes you gotta spell it out, especially for those pointy haired bosses who don't get that, right? So, how many of you do DevSecOps? All right, you're the winner. Cool. As you can see, it's not very prevalent. How are you performing application security in your process? Is it happening during the development lifecycle or is it this wonderful jet engine that's just flying through your developers or just churning out code and screeching hauls, security raises up their hands goes, you got stuff in your code, you gotta go fix. Now your project's like five years behind because you can't get it out, right? So that happens a lot. And then predominantly, what tools are you using? So let's kinda do a poll. How many of you are using one tool to do your DevSecOps? Okay, how many of you are using two tools to do DevSecOps? Well, that's good, you're doing pretty good. So which tools do you use, by the way? That's just the security tools. How do you do your DevOps? You felt for it, I apologize. I probably owe you a drink for that. Yes, you do. I apologize. I apologize. So, we did a survey very recently. GitLab did one. The survey results are posted on our website, you can see it. Basically, what we found, and this is a global survey, right? So this is all across the world. Federal isn't terribly far behind, but they're catching up. So some of these numbers don't exactly apply to federal, but they're getting there. What was found was that DevOps is being adopted very quickly. People feel like they're getting a lot of visibility by doing the DevOps model. They are able to deliver applications faster. They are able to deliver more and more faster. So continuous deployment is becoming real. So there used to be a time when all this stuff would be developed very quickly, and then it would go and sit in somebody's desk for some approvals, and then there would have to be documentation upon documentation needed to be written so that a deployment team can deploy the thing. And that's all churning out, right? So now that's all coming out real quick. About 45% of the respondents said that they're doing it, at least somewhere in the organization. So that's good. And generally that's tied to the mobile side of the world, because mobile tools tend to be more around the DevOps model. Security is still a problem. About 50% of the respondents said, well, guess what? Yeah, we're developing quickly, but security is coming up and biting us in the back end after we've actually done more development. So that's a problem. And then what that leads to is that developers have forgotten what they're doing. There's context switching. They have to fight with security to talk about why did you write this piece of code? Because it's all history. It's all forgotten. Security is not even aware of why this was written. They just care about, well, it's broken. Well, there's some vulnerability and there you gotta fix it. It's a lot of work and talk. Remote work, obviously it supports efficiency. So people who do a lot of remote work take that to your management team because they need to implement this more and more frequently is to do remote work. And then testing is hard, which we all know it's still hard. It's gonna continue to be hard because of the way that testing is carried out. There are many solutions out there for it. So this is kind of the security landscape. You have static analysis that has to be done and a lot of people do light analysis in their integrated development environments, which isn't generally very security focused. It's more quality focused. Then it gets put into this code repository where suddenly these bigger tools get involved and they do the security. And the bottom is kind of the landscape as you see today is you get all these different tools and technologies that have talked to each other and each security report is in a separate tool, separate silo of its own. So think about it. You get security involved earlier in development cycle. It's still not easy for them, right? So for every one developer, how many security people are generally in an organization? Think about that concept and then think about how many tools they have to deal with as opposed to a developer has to deal with. Developer just has to do their development work, right? So generally they have one, maybe two, maybe three tools. Security has to think about organizational security. They have to think about network security. They have to think about application security. They have to think about monitoring. They have to think about responsiveness. I mean, there's a lot of stuff going on for them. And then in front of them, now you throw four or five different tools just to do one piece of security and they go, oh my gosh, my work is just too much. They're overloaded, right? Now zoom out a little bit more. Kinda to my point about how many tools are you using? This is what the current infrastructure looks like. You've got your, name it your tool and now you gotta have to integrate it. You kinda have to have a versioning of the tools, the knowledge about which tool change and what version, how does that connect to this other thing? What does that plugin look like? Oh, that's a free plugin that somebody wrote and is no longer supporting. How do I, you know, what do I do? It's madness, madness. So that's where GitLab comes in. And many of you who are using GitLab probably have seen a lot of this. So just show of hands, how many of you use GitLab just as source code management tool? There you go, all right? There's so much more in GitLab that you could be using it for, right? Source code management is just one piece of it. But the biggest benefit is, even if you're just using GitLab as a source code management, the fact of the matter is that as part of one single application to do other things, while, you know, some people may say, well, it doesn't compete against this very specialized tool that does blah, blah, blah for me. Well, yeah, but guess what? It's not the cost of the tool of how many features it has or function it has. How much is it costing you to have that tool in your environment, right? That's the question there. Tool tax. I think it's Forrester, I think, had that terminology. So tool tax, it costs money. It costs time. Think about if that money is freed up from that infrastructure side of it, that could be used for your project to do other better things. So this is just another slide showing you a little bit more about that. Basically, we're looking, our vision is to try and encompass as much of the breadth with the depth and provide you the ability to do more and more just from one application. So you're not switching context. You're not going to five, 10 different places to do this. Right, so we're embracing security in a big way. You've probably heard about the zero trust approach that we have taken for gitlab.com and gitlab as an organization. You've probably heard about the security tools that we are now starting to embed within gitlab. How many of you have heard about that? How many, okay, two. All right, cool. So now you've just heard it from me. We are putting security tools in gitlab as one single application approach. Underneath the covers, they may be separate tools that are specialized to do certain things, but we're aggregating stuff and we're bringing it to the front and making it all kind of work together seamlessly. So once again, that one application approach, you don't have to go looking for that plug-in and that plug-in and that other touchkey. It's all baked in and that's what we're trying to do. So I'll get into the deep dive. So a lot of you who are not aware of the CI-CD capabilities of gitlab and I'm looking at those people who raise their hands just using gitlab as source code management, there is much more to gitlab and this is like the most lovable feature that's in gitlab, which is the continuous integration, continuous delivery model that we offer. So how does that work, right? It starts out with creating an issue. You create an issue, you write information in there, you provide details to the developer of what you're doing. Some people put user stories, some people put stream of consciousness. It could be anything, it doesn't matter. Then at some point the developer realizes, okay, I'm gonna start working on this and they click the create merge request button and they start working on the actual problem. Now, some of you have been in development environment know this, about whenever you're developing about 80% of the time is in deciding and designing your stuff and 20% of the time is in turning that into code that actually works. All right, so once you get that, once you get through that process, you've got your CI-CD pipeline running and that can be kicked off automatically every time you commit the code. That's hugely beneficial, right? So behind the scenes, this stuff is just kind of turning out a runnable application so you're able to deploy, it deploys it, it creates a review application, it does all these things and in addition to that, it's running security scans right at that moment, okay? Huge benefit. So I have an application that's in GitLab. Great, I changed some piece of code not realizing what I am going to do in terms of the security aspects of it. I'll just write the code because I gotta meet a requirement and I gotta meet it within the sprint timeline that I am on and I've got other priorities. But running it through the pipeline, having that do the scan automatically and providing the result gives me that comfort that I'm not gonna suddenly do something that's wrong. Oh, by the way, it also keeps it all in context of what I am working on. So I just wrote 10 pieces of, 10 lines of code. I remember that, I went home, I came back next morning and I see the pipeline run complete and there's one security issue that shows up in there. All right, I know what I was working on last night. I can kind of continue working on it. It's not like suddenly I have to review all of, past history, six months of my life and come back to it. So huge benefit there. The other thing that GitLab does, especially, yes. Yes? Yes. Dependency scanning health. Correct. Which are within the realm of security but also beyond security. Absolutely, absolutely Larry, very good point. And I consider that as part of the umbrella of security. Everything that people are worried about from a security perspective and compliance perspective. So you're right. There is a compliance aspect to it as well. Thank you. One of the things that GitLab does is when the pipeline runs, it is actually able to deploy the application to a live running environment by creating a review app for you. And then that makes it available for dynamic scanning to run as well and provide you results while you're just kind of writing code. So it brings that entire security scanning process much, much left into the development process and you're able to see the results. So back to Larry's point. When I talk security, this is what GitLab secure encompasses. It's built into the pipeline. It's got SAST, static analysis, right? So source code analysis. DAST, dynamic analysis, dependency scanning. So it will go look through your dependencies and run a scan on it and provide you results to say, hey, there's a CVE on this one dependent item that you pulled through from some other open source product or whatever that you downloaded last night. Here's the patch for it, go download it. So it'll give you the CVE link to it. Container scans. Containerization is very, it's like baked into GitLab. We have a container registry. We actually can run a container scan and provide you results of that. So very much like, what's a container scan product that people use? Twistlock, twistlock, very much like twistlock. We use Clare, same sort of stuff, and it does that. License compliance, that's a key point. How many of you actually use open source libraries in your code bases? How many of you know of usage of open source libraries in your code base? Let's start with that question. License compliance can do that, right? And it will also tell you what kind of open source license that library is under and whether you have blacklisted or whitelisted that at an organizational level. That's important, some organizations cannot digest other licensing terms of an open source product because those terms are restrictive in some way. So you want to be careful about that. And then the results show up in merge requests which I'll show you in the demo and then we have group and product security reports. So I'm gonna switch over to the demo. Any questions while I'm switching over? Yes, sir. That's not there yet. That's part of our monitor piece that we're gonna come up with. It's not there yet. We're not doing network security just yet. All right, so I'll start out with this screen here. How many of you are familiar with the GitLab user interface? How many of you work with it like once in a year? How many of you work with it like once in a month? How many of you work with it every day? All right, cool. So many of you are familiar with this so this is not news to you but for those who didn't raise your arms, basically you have the ability to create group structure so we can group things in a structural fashion. Think of like folders in your windows environment or whatever and you can place these projects or repos as most people call it which I don't like to call it repos. Repo is a component of the project. Project is much more encompassing than that but you can have many of those projects within a group. So I have a group here called Samir Kamai, that's me and then I have a spring group and these are all my spring applications and then I have a Ruby group for my Ruby applications and so on, I happen to name them that you could name them by your divisions or your organizational whatever you want to do or functions. Now when I'm in my group view I have a security dashboard that I can view so I can click on that and right there it gives me a chart. I mean managers love lines and pictures, right? So this is like totally up their alley. It shows them right up front how many vulnerabilities, how many criticals, high, mediums and lows there are. It shows you how the developers are working through it so they're down on a trend in this example is indicative that somebody's actually fixing some things. And then down below is a list of those vulnerabilities. So I can actually look at what's going on right from this dashboard. Not only do I get the nice pretty graph but I also can view the results exactly. The other thing I can do is I can sort by project so then I want to zero in on okay which project is actually causing money of these vulnerabilities which is the noisy project. Which one do I need the development team to go to training to, right? That's a huge point. Second one is by report type. So I can, I am a security engineer at a company let's say and I only care about the dynamic scans because that's the only part of what I'm worrying about. I can just very easily just filter that and say okay what did the dynamic scan results show? Or if I'm interested in the dependency scans then it'll show me that and so on and so forth. So I can do the slicing and dicing right from here. I can multi-select. If there are two or three things that I'm interested in I can look at those and then there we go. So I've got like two or more items and then there's the results over there. So it filters that at a group level. So think about this. This is a portfolio view. These are all my spring applications have this kind of layout on them. And then each individual line is a project line. So I have multiple projects under there and it shows me each of these lines and how they're burning through the vulnerabilities. All right, so that's that. Then as we drill into a project many of you use GitLab are probably familiar with this. If you use GitHub very familiar with this kind of user interface very similar. But basically you see your project. You can do your issues right here. You can create your merge request right here. You can view your CICD pipelines. I'll show you the pipeline in a minute. But some of you are not familiar with GitLab. What you'll see is I'm not context switching. I don't have my JIRA console over here and my Jenkins console over here and my IDE over here and any of that. It's all right in one browser interface. Yes sir. So yeah, so yeah I'll repeat that. Yeah, I'll repeat that. So the question was a lot of the features that I talked about in the dashboard area are very similar to SonarCube. And the question is, is the intent to become the competitive product against SonarCube is the intent to kind of do what they're already doing? The answer is a little bit of both. Okay, yes, competitor in a certain sense. We're both open source products. We both like open source stuff, so not from that perspective, but from a perspective of providing it to you in one dashboard. That's the key, one application. Right now, I just mentioned JIRA console, Jenkins console. You probably need to have your SonarCube console. You probably need to have your ID. Now you're talking more and more things being added into your environment. If you are using SonarCube and you love it and you love the aggregation features, wonderful. You can take the results out of GitLab and post it over there and do what you need to do over there, that's fine. But we obviously would prefer you to work in one environment because it just makes you more productive in that sense. Okay, so it's not so much, oh, we're gonna take SonarCube out of it. It's so much as, SonarCube users can continue using that. We'll integrate, no problem. But we also offer a second alternative, okay? Yes, sir? Okay, I'll speed it up. All right, so, going to the project, I have a very similar security dashboard that I can show you on the project. And then, as I was mentioning, this is what it looks like in terms of the execution of it, right? So I ran a pipeline over here. That's what my pipeline looks like. As you can see, right during my test phase, I ran the STAS test and I ran the dependency scan and so on and so forth. So all of those tests were run parallely while the pipeline is being executed. Another new feature that we're introducing is directed acyclic graphs, DAGs, which kind of break this model a little bit, but they allow you to kind of hop across too. So that's a different topic for another time. But it shows you security right at the pipeline run. So we think that that's important to expose right there. It shows you how many vulnerabilities were detected. Again, these are individual tool executions. So it shows you for each type of test that it ran, what the results were. But then, we actually aggregate those results into our merge request view. So some of you have seen the merge requests. You probably recognize this, is this is where everything's happening. You've got your branch over there. You've got your code that's being written. So I only changed a bunch of lines of code, but what it did was it actually made it. So we found the monobodies and we marked which ones were the same and which ones actually got fixed. So if I expand this view, what I'll see is everything with a red X basically is stuff that did not get fixed, but the green check mark tells me what I did actually fix. So from a security management perspective, I wanna see those green check marks so I can say, yeah, this is good. Whatever code changes you made, that looks good. I can approve this. So there can be an approval authority and a chain over here around this merge request before it actually gets merged into your code. That's another key point. All of this is occurring while I'm in my branch just changing my code in my little branch, my work area. And before I merge this, I'm running this pipeline. I'm showing you the results of that pipeline in terms of security, things that I may have added, things that I may have removed, whatever, getting an approval before it gets merged to my master. Huge, huge benefit there. So as you can see, all of that is shown. Let's see, so there's the SAST list, there's my dependency scanning list, there's my container scanning list, and then there's my DAST list. So it gives me all four, five big categories that I wanna see. And then we break out the license management piece, but I can also show you how that appears. So the license management, it actually tells me these are the two licenses in the libraries that I'm using as part of my project over here. The other thing that I can do is I can actually click on this vulnerability while I'm viewing it. I can look at the details of this vulnerability by clicking on the CDE link, which will take you to the CDE website. I can create an issue right from here. And when I do that, it actually pulls in all the details. So let me go click that button, probably not a good idea. But what it would have done is it would have taken those, hey, there's no good demo without a failure. Come on, come on people. All right, yeah. So it can actually create an issue for me, which I can assign to the development team to work on in the future and actually fix this. So it's a very tight life cycle around that. Yes, sir. So we rely on open source tools to scan the code and all the tools are open source tools. And we rely on some of them for their nightly builds. So whatever new stuff came in will be packaged in that and it's a Docker container that we pull down. We actually run the scan against source code or if it's a running site or whatever. So we're getting the latest details about those CDEs before they come in. Yeah, so the question is can we configure to a specific set of checks that we may want to put in like the STIG or whatever? We are not there yet, but we are working towards that. So that's the idea. Right now we just leave it at the native level with just CDE or CWE, that's all we report right now.