 Thanks for joining us today. We're excited to have you on. My name is Erica and I work on the content team here at GitLab, and I'm joining you today from Chicago. We'd love to hear where everyone is tuning in from, so if you feel so inclined, please use the chat function to tell us where you are in the world. Also joining us this morning is Lee Matos, a support engineering manager at GitLab who will be on hand to do some technical tag teaming with our presenter DT, a GitLab Solutions Architect. We're going to give people just a couple more minutes to get logged on. While we're waiting, I'm going to launch a poll you can take in part in if you'd like. During today's demo, we're going to spend a little time on security before we get into GitLab's project management tools and how they can support enterprises. So I'm going to launch the poll now. Awesome. Thanks for participating in the poll and feel free to keep participating if you haven't yet. And before we get started, I'm going to go over a couple of housekeeping items. First, feel free to ask questions throughout the presentation. You can use the Q&A function at the bottom of your screen for that. We'll have some dedicated time for questions at the end of the demo, but you can go ahead and send in your questions as you think of them and we'll make sure to get to them at the end. Also, if you're experiencing any technical difficulties, you can use the chat function to get in touch with a moderator for help. Now I'm going to turn it over to DT. Take it over, my friend. Awesome. Can you hear me okay? Yes, we can. Awesome. Well, good morning from a, it's a little overcast here in Santa Cruz, California. Super, super excited to be here to talk to you about GitLab for the enterprise. When I'm a classically trained software engineer, I've been writing code for 20 years. I'm super excited to showcase the GitLab platform. When I'm not writing code, when I'm not working with customers, I like to run the very, very long distances. So if anyone has ever thought about running past the marathon into the 50 mile, into the 100 mile realm, certainly chat out and I would love to have a conversation with you. So here at GitLab, we believe that everyone can contribute. And that's an important notion, right? We want everyone, whether it's, you know, regardless of the state, thinking of the stakeholders and regardless of your role, regardless of how technical you are, we want to provide an environment where everyone can contribute to your projects, to your code, right, to the delivery. But security is a really, really big topic. And so today I'm gonna, I'm gonna, I'm gonna talk about security in a world where everyone can contribute. Before we jump into security, super, super excited to announce 10.7 GitLab just released on the 22nd, which is three days ago. Now here at GitLab, here at GitLab, we release features every month. Lock, lock, lock and load, it's what we do. Once a month, all, an entire new batch of features come out. But for today's, for today's webinar, I'm gonna focus on security. And in 10.7 that came out three days ago, there are a lot of really key features that came out. Static application security testing for new languages, C and C++, go, there's already a long laundry list of support we have of languages that we support so far. But 10.7 came out with these new ones. I'm also going to talk about the web IDE. We just open source the, the online editor. As part of everyone can contribute, we want to make it easy for folks to come in, make changes, make changes to multiple files, commit them. You don't have to have be like an SCN expert, etc. And the web ID is a big part of that, big part of that, that journey. Now, if you've been following GitLab, maybe you have, maybe you haven't, but I'm going to give you a quick overview of what the journey that we've been taking the last six months. Along this path, looking at 10.0 that came out in September, October, November, December, etc., all these, all these releases, lots of really, really good features. But I want to focus on some of the security things. So, for example, in 10.1, GPG sign commits. All the way to 10.3, static analysis, 10.4, dynamic analysis, static analysis for containers. If you're using Docker and images, we have built-in container, container scanning. 10.5, we have dependency checks, etc. So a lot of really, really good features. I encourage you to go down along the, on the bottom there. You can see there's a links is about.gitlab.com slash releases. That's our public roadmap. And you can see a wealth of information. Every release that we come out with, there's scores of features that have come out. This is just a highlight, but I want to highlight some of the more security-focused features. I was trying to think of like a fun tagline or something to like, something catchy. And at the end of the day, security is everyone's problem. And as I said before, I'm a classically trained software engineer. I've been, I've been writing code since the 90s. I've worked for very, very large e-commerce systems, many of which are still running today. If you've ever purchased an airline ticket or gotten, or hotel online, you probably use some of the code that I've written back in the day. Back then, security was something that we never thought about, right? You just check in your code, you upgrade your libraries, you move on, right? And maybe like weeks later, a month later, months later, a year later, somebody will come knocking on your door and say, oh, hey, by the way, there's a vulnerability, right? You've got a problem. And then you have to go back and like start a new project. But we never thought about security as a first-class citizen. So one of the things I would encourage you to do is take a look at the Verizon actually comes out with these data breach investigation reports, DVIRs. I'd highly encourage you to take a look at Verizon's an example. There are a lot of good examples out there with security vulnerabilities, right? We hear all the time about sites being hacked, credit card information being stolen, you know, your personal information being accessed without wanting it. But what's interesting about the 2016 report, and I have a link down there below, is when they looked at the all the kind of hacks that were coming into Verizon, 85% of those successful exploits were from 10 known vulnerabilities, right? So I think back when I was a software engineer writing code day to day to day, in fact, I have a really good example. There was a Ruby library that had a memory leak in the regex parsing. It was like patch level 153 or something, right? And so I knew for the application that we were writing, the memory leak caused a problem where we had to basically essentially restart my particular application once a week, right? And so I was that person, I was that developer who was monitoring waiting for this patch, waiting for this fix, waiting for this memory leak to get fixed, right? And so sure enough, months later, the gem comes out, it's patched, and guess what I did? I upgraded my application, pushed it out to production, and a week later, we're rocking and rolling. Now, who knows, who knows if that regex library fix actually had a security problem, right? And so this is the kind of problem that we have today is that it's really easy just to upgrade libraries for your application, push them out and not knowing what's actually behind the scenes. There's actually a database, a CDE database, common vulnerabilities and exposures database, you can look it up online. There's a wealth of information, entire database, an entire community, an entire world, trying to focus on finding these vulnerabilities, publishing them and making folks aware. But of course, how do you know, right? You don't want to spend your day monitoring this database and wondering about all the libraries in your application, which particular CDEs are affecting you, and that's where GitLab and Automation comes in. So what we're doing at GitLab is we want to bring all that information, we want to make it easy for you. We'll scan all, we scan all those databases, and as part of your pipeline, as part of your software development lifecycle, we want to bring that security left in front of you, in your fingertips. And I think back when I was a developer, I would just check stuff in, right? I'd upgrade libraries, check it in, I'm good to go, it's five o'clock, rock and roll, done. But here at GitLab, we actually want to make or help bring security forward, make it a first class citizen. And so even if you're a developer who's making a single line of code, single line change of code, we want to give you that feedback. So static testing, dependency scanning, dynamic testing, if you're doing web applications, and if you're using Docker and images, we want to scan your containers, right? Imagine, you know, and think about the containers, those containers are built up of layers from other, you know, other containers and containers and container containers, we want to scan those for you. And so what I'm going to show you is that we have security built in right in the merge request, write your fingertips. So static testing, what does that mean? We want to do static analysis on your source code. We pull in the best of the best libraries, open source libraries out there. It's very language dependent, right? So whether you're writing C++, C++, Python, Ruby, Java, et cetera, we're going to pull in those libraries. When you do a commit, we want to scan your code for known vulnerabilities. Static testing. Within GitLab, and I'll show you in a bit, we're going to give you, we're going to give you that report, right? Green checks, green check, green is good, red is bad. We want it, we want you to know that on a single commit, a single, if you're pulling in a new library, you're pulling in a new gem, you're pulling in, you know, you're referencing some other open source library, we want to scan those and give you that information right away. In development, right? Not in production, that's a bad thing. In development, that's a good thing. Dependency scanning. We want to analyze all of the dependencies that you have in your code. So whether you're using JavaScript, Python, Ruby, Java, PHP, and as I said before with 10.7, the list keeps growing. We want to run scans, vulnerability scans on your code, managing your dependencies as well. It's a really hard problem. Back in the day, we didn't care. We didn't think about it, right? And so right within GitLab, we're going to show you this. As part of your, you know, make a single commit, we're going to show you that, show you the scanning information. Container scanning. Docker, Docker is, Docker runs the world today. And I think back when I was a developer and, man, if we had something like Docker and containers to manage my libraries and the versions and dependencies and I could just like package up something and push it out in the world. It's a breath of fresh air, right? But your Docker images are built on other images as well, especially if you're building your own images. So we want to scan those as well. And so we're pulling in Claire to do that, to do that scanning. And so here you can see an example within GitLab. We're going to show you all the CVEs, right? Talk about it earlier. We're going to show all those CVEs that are potentially impacting your containers. Let's move on to dynamic security testing, right? I've been a web developer for a long time. I built some of the, I've been a part of teams that have built some of the biggest e-commerce sites in the world that are still running today. Being able to test those sites, not only in production, but also in like in a sandbox environment is key. And so we're going to, we pull in the, we pull in OWASZAP as a tool to do live testing against your web applications. It's something that, it's something that in the past it was really, really tough to do, but we want you to be able to make a change, spin up an environment, run these tests and get the feedback in the live environment. So if you're doing web development, DAST is key. And we provide that. So here's a screenshot, right? So imagine making a change, being able to deploy your web application out to an environment, spin it up, run some tests against it, right? Get some live, you know, live, live data in and out, get some feedback, vulnerability checks, right within a GitLab. At the end of the day, we want all of this information, all of the security information, SAST, DAST, all that stuff, right near fingertips, right in the Merge request. At the end of the day, we want, we want, and it's important that security becomes a first class citizen, and we want to put all that stuff right in the fingertips of the developers. All right, so I'm ready to jump into GitLab. Are there any questions? Erica, any questions in the chat? No, I am not seeing anything just yet. But again, you guys, feel free to jump in with any questions. Thanks all. All right, perfect. So I'm actually going to move over to, I have an on-prem instance of GitLab running. There are many projects in here. If you, if you spin up your own GitLab instance, you're going to have lots of projects. There are many projects, but this one is mine called XP app. Now, I don't want to make any assumptions for folks that are watching. Maybe you, you know, maybe you've never used GitLab. Maybe you have, but let me give you, allow me to walk you through sort of the core features of GitLab. So along the left, there are three, there are three areas that I like to highlight. One is, is the repository. Of course, we have Git in our name. So, you know, that should resonate that we're, we do source control. So under the repository tab, we do everything SCM related files, commits, branches, tags, charts, etc. Anything you can imagine that's SCM related. We've got you covered under the repository tab. I want to move down to issues. So when you think about, what does it take to actually build good, high quality software? It starts with requirements. It starts with somebody having an idea of what to build. And so here at GitLab, we want to capture, excuse me, we want to capture those ideas. And with boards, as you'll see in a little bit, we want to help you plan out those ideas. Merge requests. This is where, this is where the rubber hits the road. This is where the merger quest essentially represents the changes that people are making, intensely making against the repository. CICD. This is my favorite part about GitLab. And we're going to talk about this at length. We're, when you're making a change, we want that automation to kick in. We want to run your tests or run the security test, SAST, DAST, all that stuff. Give you that feedback right away, not only on master, but also in your, in your feature branches. So those are, those are the key areas, the repository issues, merger quests and automation with CICD. So as part of today's demo, oh, I'm getting my, sorry, I didn't drink a tea here. So as part of my demonstration, I'm going to walk you through with the end in mind, an example of, of GitLab, and how those pipelines and the security, the security test can be run, even with the simplest change. So when I talk about GitLab, I like to start with, with environments, right? So here in this example, it's a really simple example. Like, like many of you, we have a lot of different environments, testing, staging, production. There's all those environments that you deploy to. Here in GitLab, you have visibility to that. So in this example, I have a staging environment. And I have a, on the bottom here, and I have a production environment on top. And you can see, for example, within the staging, the last time I was committed to, for example, two hours ago, I did a push to staging. Along the top, you can see I pushed a production a week ago. So GitLab is going to help you push out those deployments, have traceability into what was actually going out. Now within the staging environment, because I've configured my very, very simple demo application, it's a simple web application, but I've configured it in my project to let GitLab know where it's deployed to. So on the right here, I can open up, I can open up here a really simple example. High world, right? Red background, somebody missed the memo, it should be hello world, it's high world. So what I'm going to do today is I'm going to walk you through doing that fix and help you understand how security can play a role in that. So let's go back into GitLab. We're going to fix our high world. Now, normally, you could just go in like make a commit to master, push it out, all the automation kicks in, and that would be just fine. But in a real example, we have teams of people, you have requirements, you have gates along the way, approvers, this and that, you're going to have some sort of process. And so within GitLab, any change that you make to your environment, to your project, I like to think of it, we like to think of it starting up with an issue. So I'm going to go into issues and go to my list of issues. There are lots and lots of issues. We have issues. We have issues, friends. It's a linear list. It's hard to digest. There's a lot of good visuals here with the labels with the dates, the milestones, but it's hard to decipher. So I like to actually come into the board view personally. And the board view gives me an XY two dimensional view of all the issues that I'm working on. You can have many boards with the Enterprise Edition. So for example, you can have a Q4 planning, you can plan for, if you're doing Scrum or Kanban, you can manage your sprints or your time boxes. But ultimately, this is the board that I'm going to use to manage my work. And let's see here. So, top to bottom, you can see I have a backlog, I have a to do column, a doing column, and a close column. You can have as many columns as you want. Whatever your value stream is, whatever your flow is, you can set that up. But ultimately, I'm going to make a change to fix initial homepage message. So I like to talk about, when I talk about boards, I like to think about Scrum teams doing planning, right? So like as a product owner, as a stakeholder, as a subject matter expert, I'm going to come in and start prioritizing this work, right? So I'm going to drag the work up, prioritize the work, let people know what are the highest priority items. As part of that team, when I come in Monday morning and we say, hey, yeah, you know what, in our two hour planning meeting, this is one of the things that we're going to work on, right? So visually, we let everyone who's part of this project know what we're working on. As a developer, I come in on Wednesday, I'm like, hey, you know what, I'm going to work on this, right? So you can use these cards, you can use the boards as a way to visually let folks know the stuff that's in flight. So I'm going to go ahead and open up one of these issues, open up this issue. And you can see here, it's part of our issue management. It's a requirement. It's really, really simple. It's hella world, right? But within GitLab, we have a rich language for letting you describe those requirements right within here. So you don't have to have word documents, etc. You can do all right here. It's all good stuff. But within this issue, this is the change that I want to make. Along the right, you can see it's assigned to me. So if you want milestones, if you want to time box it, right, getting ready for a quarter release or if you're GitLab, you're like, hey, on the 22nd, we're releasing. So my milestone might be, you know, May 22, the next release coming out, due dates, labels, etc. All the things you'd expect from a first class issue tracking system. But ultimately, I want to make a change. I want to go fix, I need to fix staging, right? So I'm going to come down and create a merge request. And the merge request essentially represents an empty bucket of changes. And you can see here, for example, there's a, what GitLab does behind the scenes, best practice, create a private branch. Now, not only is the merge request associated with the issue, you can see here, if I close the merge request, it'll close the issue, the requirement. The merge request is essentially capturing and containing all the work on a single private branch out of the box. I just click the button and I get a private branch. Right. There are no changes right now. It's empty. So we're going to go make a change. So I'm going to click on that branch. And you can see here there are lots of branches, but this is the branch I'm on. I'm going to come in and make a quick change. So we have our new web IDE, which we just open sourced three days ago. So let's make a change. You can see here I've got my server file. Let's just make it hello world. Let's fix that. Get back to basics. And we'll make it a hello world and we'll make it a green background. And also, because I'm in the web IDE, I'm going to edit multiple files. So let's just say, let's get rid of all this and say, green and hello world. All right, make a few changes. All right. And then I'm a comment fixed messaging and we'll commit. So it's really nice in one interface, multiple files, make all those changes one single commit. That's good. Now, we were in the merger quest. And as I said before, the merger quest represents the change that we're making. And it was a soup. It was a really simple change. I'll be honest. Right. Let's go to merger quest, fix initial homepage messaging. And let's see what get lab is doing behind the scenes. So here you can see as part of the merger quest, we've kicked off a pipeline, and the pipeline is that automation and I'm going to fold back. I'm going to wheel wheel back to the initial topic of security, right? What if I had included a library, a third party library and open source library, right? How do I know if it's broken, how do I know if I have vulnerabilities, it'd be great to know, even if I'm doing a really simple change, it'd be great to know that information. And that's what get lab is doing. So here you can see I have a pipeline. I'm just going to show you real quick as part of the merger quest. This is where you can do code reviews. So you can see really simple, real simple. You can see the differences and the changes that I've made, right? We've been doing code reviews for years. So this is nothing, nothing super crazy. But what is super crazy is the pipeline that's running up above. You can see here just by eye that we're kicking off a pipeline. It's got lots of stages. Let's actually drill in and take a look at the pipeline. Automation out of the box, do a commit, run all your, run all that run all your, your automated tests in your build. So you can see here, for example, in this, in this example on my private branch, I have several stages that are part of my pipeline. Build, test, security, review, cleanup, et cetera. Right. You can define, you can define as many stages as few or as many stages as you want. But ultimately in this particular example, when I do a build, I'm going to package up my code, compile up my docs, get them all together. If everything's good there, I'm going to go into the testing phase. From here, I'm going to do, I'm going to run code quality. Any coverage integration unit tests up to you, you can specify as many jobs as you want. In fact, if you, if you were to look at our, our, our official GitLab project, which is also in GitLab, we have like 70 jobs as part of the test. A lot of, sorry. You can specify as many things as you need there. Once the test pass, you go to the next stage. In this case, I'm going to run some security tests. Here we go right now, SAST. One of the great things about GitLab is, is not only do you have the, the green good, the, the red, the red, the red bad, the check, the checkbox that's that says something failed. But you can also drill in. So for example, if I go into SAST. I can click here and you can actually see the output from the actual security run. Now there's a lot of, there's a lot of detail here, and I don't want to overwhelm anyone here. But ultimately we're pulling down a Docker image. We're taking your code, we're injecting that code up into the container, and we're going to run the analysis against it. And so here, if you, if you, if you want to geek out, as I like to think, you can actually see the raw output from, from the test, the security test here. Ultimately, here's the output. This is the old school, right? Back in the day, this is, this is, we just sit and look at logs. We have to SSH to a server, get the logs, you know, parse it, scan it, look at it. But ultimately what we're doing at GitLab is we're taking all this raw information and we're putting it right in your fingertips in the merger quest. So let's go back to that merger quest. I don't need to be jumping around here too much, but the merger quest represents again that, that entire body of changes that we're making. It was a simple hello world. On our private branch, you can see here, for example, the pipeline has passed. So we know that that simple change has gone through all the automations, security tests, package up the code, all my unit tests, etc. Great. We've also deployed it. You have an option, depending on your applications, you have an option to deploy it to a review environment. GitLab can spin up a sandbox environment to deploy your application. In this case, in this case, it's a web application. So out in Kubernetes, I've deployed a pod, I've launched the service, and it's given me a unique URL. So for example, I can go here and boom, hello world, green background. What does that mean for me? Well, I can take this URL, it's a little, it's a little copy book here, but I can send this URL. I can copy and paste this, send this email to any stakeholder on the project and say, hey, come check this out. Click on this link. Come see my changes, right? Let folks collaborate and communicate. At the end of the day, though, that simple change has done several things. I've run my code quality tests. So I've got some indentation issues, some lying too long, yada, yada, yada. But more importantly, I've run my security tests. And here you can see that GitLab has said, great, you know, you fixed hello world based on the code review down below. And there are no security tests or security vulnerabilities. Now, what would it look like in a real world? Well, I have a good example for you. So it's a bit of a mock-up. But it gives you, it'll give you a really good sense of holistically what's possible. And this is stuff that's available in GitLab today. So here's an example of a merger quest, just like mine, the one we just did. You can see here the pipeline that's run. You can see summary from tests, code quality, security tests, performance metrics, coming soon, license management. All this information because you made a single one-line change of code. But what I want to highlight here is the security stuff. Within that merger quest, we want to give you upfront as a first class citizen a report on dynamic, static, dependency tests, container scanning, all in one view. All because you made a simple change to the code. Of course, you know, in a real world, you're importing libraries, and we want to report on that. Okay, so let's go back to our example. Where are we? Okay, so this is our change, our pipeline, the actual change. Our pipeline has passed, which is good. So you can see here. Looks good. We sent around the URL. Everyone gave a thumbs up. Let's go back and let's merge it in, right? We're on a private branch, so I'm going to resolve it. Yep, everything looks good. I've passed all my SaaS tests, all my security tests, and now in a real world example, you might have multiple people on your team like architects, your team leads who have to review these kind of changes. In this case, I'm just going to go ahead and merge it, but you could have a workflow where you have to have people sign off. Before you merge into master, master being the golden branch. But ultimately, for today's example, I'm going to go ahead and just merge this change right into master. So what just happened, right? I'm a team, I'm an individual, made a bunch of changes. I just merged into master. Changes merge into master. And what you should expect from GitLab is automation and making change. So I'm going to my pipelines. And sure enough, you can see there's lots of pipelines that have been running on different branches, master all over the place, some pass, some failed. But right now I've got one that's running and you can see here it's on master. That's because I'm integrating my changes into the quote unquote production line. Let's take a look at that pipeline. So you can define your pipelines. They can be different depending on where you're making changes. If you're making changes to a branch, your pipeline might be smaller. Security tests can take a long time to run. So what I've been, I've been talking with customers and, and frankly, some of their security tests take like 12 hours to run. So you might want to separate, you know, separate those changes, pull some of those security tests into the future branches, put some of those security tests into your mainline development. At the end of the day, you want to get those reports sooner than later before they go to production. Here's an example of a pipeline. That's my master pipeline. It's a little bit different than the one, a little bit different than the one you saw. I'm going to reuse some parts of that pipeline. I'm going to build my code, package up my docs. I'm going to run all sorts of tests. In this case, my security, my security stage is a little bit different. I'm still going to run SAST, but I'm also going to run different security checks, maybe look for sign commits, eventually be able to push out to staging, right? If you're on a private branch, you're not going to push to staging. You want to push to a review environment. But once you get on the mainline, you're going to want to push to staging and eventually push to production. And so GitLab gives you that ability. Now, your jobs might take some time. So for example, we're kind of, we're kind of waiting for this code quality job. So let's go take a look. See what's going on there. And sure enough, it's doing some Docker magic. We're running some Docker commands and it just succeeded. It's cool. Let's go back. And you can see here all my tests passed. I'm doing all the security stuff. You can drop into SAST, for example. Let's take a look at something that's kind of kicking off at the moment. I don't know if we're going to see anything here just yet. There we go. So GitLab is going to pull down the, pull down this image. It's going to take your, take the code in the project or run the security test against it. Get that output that succeeded and said five security vulnerabilities. Okay. Well, it's good to know. And we're just going to staging. Let's go back to my CICD pipelines. Good thing we're just going to staging. But if we go back to that pipeline, you can see here. That we are working on the pipeline. And I'm waiting for my staging environment to get that. So there's my remote API. Fixed just went out waiting for staging to be published. Let's go and take a look at that guy. Job succeeded. If I go to my environments and go into staging. Open that up. There we go. How do I know that I actually fixed something that something's changed? Well, let's go to production. Take a look. Let's go to production. I didn't show you this earlier, but production still has the old high world. Right. Here in staging. And I, the, let's do the exit full screen. There we go. Make it a little easier to go through my tabs. If I'm looking at my production environment, if I'm looking at the old red broken high world staging, it's fixed. Perfect. So I'm going to go in here in the staging and say, okay. Time to push. Now you have an option within GitLab. It's part of our, it's part of our enterprise offering. If you're deploying your applications into a Kubernetes environment, which a lot of folks are going that way with cloud natives. You actually have the ability to push. You have the ability to push your change to a subset of pods, a canary environment. So you can actually just test, you can test your change in a, in a sliver, if you will, a sliver of the production environment in a production environment, test your change in a sliver and see if it's working. If it doesn't work, you can pull it back out. It gives you an option rather than like doing a full role against production and upgrading everything. You can actually just test your change and sort of blue green environment along, along the side. I'm going to go ahead and just click on production here. Let's push that out. As, as part of the workflow of my project, I want all of my changes that are going into a state, they're going into master to automatically go to a staging environment. Right. So day after day, week after week, we go to staging, but the actual push to production while you could have it automated. In this case, I actually want to have like a, you know, like GitLab, we release on the 22nd of the month. It's a, it's a known date. It's part of our, it's part of our DNA, you know, we don't release on the 21st, we release on the 22nd. So it's a manual step. So GitLab lets you choose to have a intervention, if you will, as part of your flow to, to pushing to different environments. And so I went ahead and pushed to production. I might take some time. Let me actually take a look here, staging. That's actually, I'll just go back and reopen it. And go ahead and close all this out. Let's go ahead and reopen it from here. Let's take a look at production. It's probably still, yeah, probably still getting pushed out. And that's okay. It'll take some time. Ultimately though, as part of today's webinar, as part of our presentation, security is a huge focus. Automation plays a, a key role in making security a first class citizen with GitLab, especially with our enterprise addition. The pipelines, if you will, let me go back. I can click on us. Within your project, you can define, it's a real simple text file. You check it in with your project, but your, that file will define that pipeline. It will let you pull in security testing. Bring it closer, shift left, bring all that stuff for in the forefront of the, of your development process, your release process. If you're, if your tests take five minutes to run, if they take five hours to run, that's okay. You can separate them. You can make that part of your pipeline. Within GitLab, we want to, we want to make sure that you can have a repeatable process for delivering great software and make security a first class citizen.