 Welcome to the GitLab 15.9 new security feature release video, where I'll go over and show you how to use some of GitLab's newest security features. Hello, my name's Fern and I'm a technical marketing manager here at GitLab. And whenever I'm not creating technical content and videos, I'm doing this. If you want to reach out and say hi, my Twitter handle is at Awkward Ferny. In our agenda today, these are the features we will cover. If you want to skip to one, be sure to see the section breakdown in the description. The first security feature we will cover is that users with the guest role can view private repositories. Users can create a new role through the API and assign that role to users who the administrator wants to have view repository permissions. The requirements are having the guest role on a private repository as well as the ultimate license. Now let's see this feature in action. I'm going to go ahead and log in as a GitLab administrator. And here I can see my super secret GitLab instance project. When I take a look, I see that the readme has a super secret in there. Now let's take a look at the users within this project. We can see Farmer Pickles here who has been granted the guest role. Now let's go ahead and log out and then log back in as Farmer Pickles. Now when we go ahead and look at the project, we can see that there is no code shown. Now let's go ahead and give our guest access to view the repository. I'm going to sign back in as an administrator. Then I'll head to my account preferences and go to access tokens. I'm going to give my access token a name and then scope it towards API. Then click on create personal access token. The token can be copied from this screen. Now let's go to the terminal and perform some API commands. First I'm going to export the token I just copied. Then I'm going to go back to my project and make sure I remember the project ID which is 3. Then I'll go to my group and copy my group ID which is 2. We can set this as an environment variable for later use. Now by looking at the member roles API calls, I'll scroll down to the section that shows how to add a member role to a group. This role will allow us to read code from a repository as a guest. To perform the API call, we require the group ID, the base access level, and the read code which is a boolean yes or no. Now let's go ahead and copy the API code and then change some variables. I'm going to go ahead and add the group ID to the URL, change it to the path of my GitLab server, keep the read code to true, keep the base access level to 10, and then add my access token. Then we'll get a response confirming that the member role was added to the group. Now for the next call, we need a user ID. In order to do this, we'll just call the user's API and pass in the username farmer pickles. And then we'll grep for ID to obtain the user ID, which we can see in this case is 3. If we don't have a great memory, we can save it off as an environment variable. And speaking about bad memory, I'm also going to export the project ID which I remember to be 3. Now going back to the documentation, let's look at the section on associating a custom role with an existing group member. In this case the group member is farmer pickles and the custom role is the role we finished creating. I'm going to go ahead and copy the call which updates a project's membership. I'll paste it into my terminal, and then go ahead and change the variables. And success. My guest user now has access level 10, which allows me to view the repository. I'll go back, login as my guest user, click on my project, and now I see the super secret. The next security feature we will go over is requiring multiple approvals from code owners. With code owners, you can now precisely define for which files, file types, or directories approval has been designated as optional, required approval by one user or multiple users. Now let's set this up and see it in action. In this project we see three members, one owner and two developers. As the owner, I'm going to go ahead and create a new code owner's file, where I'm going to name it documentation, require two approvers, and designate who those approvers will be. One being me and one being farmer pickles. And then I'll go ahead and commit the change. Now I'll go to my project settings and click on repository. Under protected branches, I will make sure that the main branch has code owner approval configured. Now let me go ahead and log in as one of my guests, Wendy. I'm going to go back into the project and then edit the read me. I'll just add a simple note, Wendy was here. And I'll go ahead and commit my changes as a new merge request. On the merge request, you can now see that there are two approvals required from code owners. One for the developer on the project and one for the owner on the project, which we defined in our code owner's file. Next, we'll cover a new way to manage license approval policies. We can now create license approval policies via the policy management UI, where we can add two step approval process, where multiple policy rules can be created and chained together, applied at the group or project level, and can be used to require approval for any license that is not specifically allowed. Let's see it in action. Within our project, we go to the security and compliance tab and click on policies. Now let's go ahead and create a new policy. We're going to go ahead and create a scan result policy, which will require approval if an incompatible license is detected. We can go ahead and give the policy a name, a description, make sure that the status is set to enabled. And then within the rules, we can check if license scan finds any license matching or accept. I'm going to go ahead and choose accept. And then I'm going to select the licenses that I want to allow. And then I'll select it for newly detected licenses. And we can target the main branch. And then here I can set who I require approval from to merge any merge request with licenses other than these. I'm going to go ahead and add the GitLab HQ team and click on configure with a merge request. I'll go ahead and merge this code. Then I'll go back to my main project and edit our dependencies file. Since this is Python, it'll be our requirements.tax file. Now I'll go ahead and add some dependencies which don't contain the MIT license. I'll make sure to commit the code change on a new branch. Then I'll go ahead and create a new merge request. Now we wait for our scanners to finish. And then we can see that we require license approval because of the three new licenses which are not allowed. The next feature I will cover is tracking important incident timestamps on the incident timeline. This feature allows you to specify optional incident tags, which make it easy to see relevant incidents based on the timestamp tag. I'll show you real quick how it works. In our project, we'll go to monitor and incidents. And here we have an incident labeled service down. I'm going to go ahead and click on that incident. Then I'll go to the timeline tab where we can see when our incident was created. And we can add new incidents. And from here, we can add an event tag, such as when the response was initiated. Then we'll add some notes and save the incident. And there we can see incident tags in action, clearly defining relevant events within your incident timeline. Next, we'll see a new license compliance scanner. We now support a new method of detecting licenses that is capable of parsing and identifying over 500 different types of licenses. To enable this, all we need to do is make sure that within our GitLab CIML, we include the dependency scanning template. Then once the main project has been scanned, we can see within our dependency list all the different licenses detected. And last but not least, as with every GitLab release, we can see updates to our security scanners. Here we see some updates for our SAS analyzer, new rules for a variety of different languages to better protect against different types of vulnerabilities, and secret detection scanning all commits in merge requests, allowing you to catch leaks in earlier commits. Thanks for watching, and I hope you enjoyed. For more information on GitLab and the features you saw today, please be sure to see the links in the description. And make sure to hit that Subscribe button.