 Oh, hey there, 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 security features in the GitLab 14.0 release. Now GitLab always has a large set of features every release, just like this intake I just installed. Now let's get started. So the first thing I want to go over is aggregating identical DAS vulnerabilities into a single vulnerability. So as you can see here in the evidence tab, it'll have a bunch of different URLs. In the past, all DAS vulnerabilities found in a scan were listed individually for each URL the vulnerability was found on. In order to reduce the overhead of managing vulnerabilities, GitLab combines identical vulnerabilities found on multiple pages into a single reported vulnerability within the DAS report. Now let me show you how that works. If I go to my pipeline view, and I see the pipeline that just ran, and within the security tab I search for DAS as my scanner. If I click on one of these vulnerabilities, you can see all the information for server leaks version information via server, HTTP response header field, that which is my vulnerability. And then if I look down, I can see within the evidence all the different URLs that were tested where this vulnerability was found, meaning that all these URLs contain the same vulnerability. This makes it easier to search by vulnerability and see everything that's affected instead of having to click on each similar vulnerability, making it much more efficient. Now I'll talk a little bit about container scanning integration with Trivi. So now by default, GitLab's container scanning solution uses Trivi as the default engine. This provides customers with much more timely vulnerability intelligence updates, more accurate results and a support for a larger number of operating systems. In order to see this, all we have to do is within our GitLab CI.yaml, include container scanning, and within our pipeline, if we just look at container scanning, we see that it's using Trivi. And Trivi is maintained within our GitLab infrastructure. That way you don't have to worry about any changes being made to the actual application itself. In case you want to try a different solution for container scanning, we also offer gripe. We like to give users flexibility and choice in selecting their container scanning engine. In order to use gripe, all we need to do is just add the CS Analyzer Image variable and set it to this. And now we run the pipeline. Now this can also be added to your CI.yaml variables. And now I'll wait for this to run and fast forward. All right. Now that the job's done running, I'll go here and click on container. And you can see that gripe is running. Next, we have the security report generalized detail structure. So what this does is we standardize the way that all of our security reports are done. So by that, meaning we have a standard schema for each of the security reports. And I'll provide the link in the description, but you can see the different security report schemas here in the security product section. And it'll cover the different schemas for dependency scanning, container scanning, et cetera. Now what these generalized details do is they allow us to integrate a wide variety of security scanners with minimal effort, allowing us to go even further with rich formatting options for finding details, making it easy to map most tools, existing outputs into our JSON reports format while adding consistent presentation logic automatically. Let me give you an example of what this looks like. So here we have a DAS vulnerability that was found. And when I go down, you can see under the evidence section, there's information for a code sample, for a diff, a file location URL, et cetera. And we can customize this with third party scanners when we integrate them with GitLab. Another enhancement what we do pretty often is the static analysis analyzer updates. So as you may know, GitLab static analysis is compromised of many different security analyzers that the GitLab static analysis team actively manages, maintains and updates. So there's been a couple of updates, such as SEMGREP has been updated to version 2.8. Gosec has been updated to 3.1. And there's a plethora of other updates. And this is done within each release we go through, and we analyze the different SAS scanners and other scanners as well, and make sure that we are up to date and that they are working efficiently and accurately. And the last thing I wanted to point out is that expired SSH keys added to GitLab are now disabled by default. In the past, expired SSH keys added to GitLab were enabled by default and could be used unless explicitly disabled by an administrator. This is done to enhance our security policy.