 Hey, my name is Fernando and I'm a technical marketing manager here at GitLab and today I'm going to go over some of the compliance and security features of GitLab's version 13.11. So the first item we'll go over is creating custom compliance framework levels. So GitLab currently provides several predefined compliance framework labels. With this release, you can now add your own custom frameworks, enabling you to customize your labels for your own specific frameworks and processes. Let's take a look at how this works. So at the group level, and it must be the main group, not a subgroup, what we can do is we can go into our settings, our general settings, and you will see this tab that says compliance frameworks. We can expand this and add a framework. So here we can give it a title, a description. We can provide a compliance pipeline configuration location, which I'll discuss next, and we can assign this label a color. Then we can go and press add framework. So now we have this framework applicable. So now we can go ahead and set this compliance label on our project. We go into settings, general, and then we see this compliance framework optional. We can go ahead and apply the compliance framework, which we've set up. So now when we go back to the project, we can see that this label has been applied. Now we'll show you what you can do with that. The next item I'm going to cover is compliance pipeline configurations. For teams looking to implement compliance requirements in the pipeline workflow, they can now enforce even more separation of duties by setting up a single pipeline definition for a specific compliance framework. This means that anything with the compliance framework that we added will run a specific pipeline that we define. Now let's see that in action. So coming back to my group, I'll go to settings, general, and under compliance frameworks, you can see that I've added a compliance framework configuration location. So what this will do is it will run this file that's here in this group, this subgroup, and this project. And if it contains this label right here, if it contains the SOX GKE label, then this will be the pipeline that runs for any project containing that label. So a good practice would be to keep this in a separate location that you have for different compliance frameworks. And then every single project that's tagged with this label will run that particular compliance framework. Now I'll show you this running in my project. So if you take a look at this project, you'll see that I have two files. I had the original GitLab CIEMO file, but I also created this other file to run for the compliance framework. So that includes we're just running security, some coverage fuzzing, and a code quality test. And you can see that running on this project right now is the compliance pipeline rather than the pipeline that will send the project. So now we can enforce different pipelines to run depending on the compliance label that's set. And the last item I wanted to cover is GitLab plus CEMGREP, upgrading SAS for the future. So we've traditionally been powered by lots of different open source tools. We've been evaluating new security analyzers and are very impressed with CEMGREP. We're in the process of transitioning many of our LIMP based SAS analyzers to CEMGREP. We can check this out in action by adding SAS experimental features to our GitLab YAML and setting it to true and having SAS enabled. Then within our pipeline, you can see that the CEMGREP SAS job runs as well. Thanks for watching and I hope you enjoyed. Please be sure to hit that subscribe button and check out more from GitLab.