 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 newly released security features in GitLab 15.3. The first new security features we can see involve approval rules. You can now add approval rules for all protected branches. This improvement allows you to more selectively apply compliance controls with increased granularity. We've also added the ability to remove approvals by code owners only if their files change. That way you can be more selective and only remove code owner approvals if their files change, increasing the speed of code reviews by avoiding unnecessary re-approvals. Let's take a look at how to add approval rules to protected branches. First we go to settings and then we go down to merger quests. Here we can see all the settings around merger quests. Let's scroll down to the bottom and we can see our merger quest approvals. Now let's go ahead and add a new approval rule and here we can add a rule name. We can select either all protected branches or a particular protected branch which can be seen here as feature B. And then I can select who my approvers will be by either selecting a group or selecting a member. And now you can see that that new approval rule for QA has been created and will require approval on any merger quest committing to that branch. The next security features I'd like to highlight in this release are the browser based DAST passive check milestone. The browser based DAST scans now run all the passive vulnerability checks from the browser based analyzer. We've been releasing new vulnerability checks on the browser based DAST analyzer on a regular basis. Going forward we're going to be working on active vulnerability check development. As with the passive checks the individual active checks will be enabled as they are released. Next you can see that we've also improved the speed of DAST API and API fuzzing. In order to perform this we've added support for multi CPU runners. In our benchmark tests using a private runner with three CPUs we saw an increase in speed by about 78%. Note that this varies depending on a number of factors which includes the speed of the API being tested and the test modules that have been enabled. In general when using runners with multiple CPUs you can expect a significant reduction and test time over using shared runners or runners with a single CPU. In order to take advantage of our browser based DAST we just simply have to add a variable to the GitLab CIML. So let's go ahead and open the GitLab CIML and then go ahead and you can see that the DAST browser scan has been set to true. When going to a pipeline which ran DAST we can click on the job output and here we can see all the new jobs run with the browser based scanner. The next new feature is to define password complexity requirements. Now this is for self-managed GitLab and allows an administrator to define password complexity requirements in addition to minimum password length. For new passwords you can now require numbers, uppercase letters, lowercase letters and symbols. This helps administrators enforce their password policies. Next up is all the static analysis analyzer updates. Here at GitLab we frequently bring updates to our different security analyzers. These updates bring additional coverage, bug fixes and improvements. For a deeper look check out the links in the description. In order to enable SAST all we need to do is simply add a SAST template to the GitLab CIML. The template can be added here with the include statement and we can also add the variable SAST experimental features and set that to true to see the newest features that have not been released. Now when going to my pipeline we can see that SAST has run under the test stage and here we see the semgrap SAST runner. We can go ahead and click on that and we can see the job output for this analyzer. And last we can see some other security changes that have been added such as enforcing authorization checks for all media files meaning that images attached to issues, merge requests or comments previously did not require authentication to be viewed if you knew the direct URL. Now authentication is required. We are also now logging audit events for changes to the audit event custom headers. This audit event helps you ensure that your configuration for streaming audit events is correct. And last there are secure defaults for new access tokens. Now when you create an access token the expiration is set for 30 days from the current date and for project and group access tokens the default row is set to guest. Thanks for watching and I hope you enjoyed. For more information on GitLab please see the links in the description. And for similar content be sure to click on that subscribe button.