 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 new security features in GitLab 14.8 The first new security feature we have is that we now support new types of SSH keys These keys allow users to take advantage of hardware backed SSH authentication So the first thing I'm going to do is plug this hardware security key into my computer and show you how the process works Now let's go to our terminal and run the SSH key gem command with sudo We'll add dash t and the key type in this case I'm using ecdsa dash sk and I'm going to provide a comment as well Now I need to touch my authenticator, which is my ube key and then I'll enter a location to save and a passphrase and my key has been generated Now you can cat the key from the location you saved it in and then within our GitLab UI We can just add it to the SSH keys section We also have security approval policies Here you can define a policy of when to require approvals as well as which approvals are required It's a better experience in many ways than the vulnerability check It enhances separation of duties and allows management of several policies within one project In order to set up security approval policies We go to the security and compliance tab and click on policies From here we can click on new policy and under policy type. We're gonna go ahead and select scan result This provides us with a default YAML. We'll click on rule mode and let's add a name a Description we'll check the policy status to on and We'll set up a rule if sast Scan in an open merge request targeting the main branch finds one or more Vulnerabilities of any type That are newly detected Then we'll require approval Now I'm gonna go ahead and add someone Sam White as the approver and then I can go ahead and create via a merge request Now you can see that we're in a new project called Chachi security policy project And we take a look at the changes and here's our policy It's in a separate project because we can perform separation of duties and manage policies in a project with different permissions now I'm gonna go ahead and merge this and Going back to my main project. I'm gonna go and click on policies again and When I click on edit project policy, you can see where the security project Containing the policies is located Now I'll go to a merge request which contains vulnerabilities You can see that one approval is required from Sam This is because sass vulnerabilities were detected Then there's coverage guided fuzz testing corpus management in previous versions of GitLab if you wanted to use a seed corpus in a coverage guided fuzz test You needed to upload the coverage fuzz seed corpus file using a variable This made managing a corpus completely manual now We've added new variables which automates the corpus generation which can be easily integrated into your testing workflow We can see the generated seed corpuses by going to the security and compliance tab and clicking on configuration Now we scroll all the way down to coverage fuzzing and click on manage corpus And here we'll be provided with a list of all the generated corpus files and we can even download them We can also add our own corpus by clicking on the new corpus button We'll specify a name and choose the file and zip format In order to enable this feature go to your GitLab CI Amel and Scroll down to your coverage fuzzing job and make sure that you include the following variables Cove fuzz use registry and Cove fuzz corpus name You can now customize built-in sass and secret detection rules For each rule you'll be able to change the name message description and Severely fields to help your DevSecOps teams know which vulnerabilities to fix first In order to create a rule set we create a directory called dot GitLab and within it We create a file called sasth rule set dot Toml Here I'm creating a rule set override for go sec So what's going to happen is any vulnerability detected with the type Cwe Equaling 703 will have its description message name and severity overwritten Now if we go to an mr with a vulnerability detected with Cwe equals 703 We can see that the vulnerability parameters we specified have been overwritten if this was merged These overrides would also be present within the vulnerability report We've also included several updates for the static analysis analyzers Here we can see the different updates which have been added We continuously maintain several open source tools within our infrastructure and update them when needed Thanks for watching and I hope you enjoyed for more information on GitLab 14.8 Please see the links in the description and make sure to hit that subscribe button