GitLab Developer Evangelism Team, 4 Sep 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How to set up Security Scan Policies in GitLab

Description

GitLab Documentation: https://docs.gitlab.com/ee/user/application_security/policies/

#devsecops #dast #gitlab

A

I am a worker, City, Congo, developer, evangelism program manager at gitlab, and in this video I'll be talking about security policies in gitlab. Security is no longer something organizations take lightly. It's not possible pattern. Password of software development life cycle in most organizations and security teams in this organization are saddled with the responsibility of ensuring not just the organization itself, and the network of reduction is safe, but also how the organization builds the applications and one way they ensure this is to put in place.

A

Policies that require security, scans are executed anytime and the applications are built or when the developers push their code to ensure that those applications, as those applications are safe and the changes are introduced, are also safe. Also, one other policies is to ensure adequate oversight over any vulnerability. That is discovered during the security scars executed on the applications. Now in gitlab, we have what we call security policies and the security policies allows organizations to do two types of uh to set up to two types of policies.

A

One is scan resolve policy which ensures that necessary approvals are required before image request is merged, based on the result of security scans that I executed. Well, let's say, for example, it's a.

A

Detections scan has executed on the CI on the application and it discovers a secret has been exposed newly now it can require approvals from security team or from engineering manager or from any other members of the team. Before the match, request can be matched, it can also just check and see. Oh a new license has been introduced into the application, and it's not part of the license is approved to be used within the organization.

A

Then it will require- maybe probably the legal team or another team quality assurance for another team to approve that much request before it can be able to match now. Another policy that can be implemented is scan execution policy, so this ensures certain scans security scans are executed for the project or for projects within a group or subgroup. Now this is important to ensure that, even if developers within their applications do not put a CI job, the jobs that has been added to the security execution policy will be executed.

A

Now, even if there is a CI script within a project already- and it doesn't include certain jobs that are required by the security team, they will be executed because they've been implemented as part of the scan execution policy. This allows the security team to introduce new security scan policies that keeps the application safe. Even if the developers or new projects don't include those scans now I'll be showing you a demo of how to create the security policies. Now, in my browser here, uh I mean this group.

A

This is a subgroup on gitlab and within this subgroup let me create a quick project. uh Let me just create from a template. Yeah I can select any of the templates here. Let me just use Ruby on reels. Now, let's see, let's give it security.

A

A

Now, let's make it a public project and I create.

A

It's currently important from the template, it's important for me, the different projects somewhere, where the template is stored. Now within the gitlab navigation here, we'll see, secure and under secure. We see policies. Now when we go to policies you can see, it doesn't currently have any policy.

A

This project doesn't currently have any policy, so we can create a new policy within this section here. If you have any policy that has already been attached to this project, you see them here and where their sources from, but in this case we don't have any policies so we'll be creating a new policy here now, like I mentioned earlier, we have two types of policies that can be created, scan, result policy and scan execution policy. Now, let's create a scan execution policy.

A

Now, within the interface we have two types of mode: we can either use the policy rule editor and in this interface- or you can write it manually yourself, but if you are new to this, it's best for you to use the editor. So let's give it a name test security policy. Now, so you can add a description if you want and you can either enable or disable a policy now, let's see for whatever reason, you no longer need it, but we still want to keep the policy.

A

You can disable it, so it doesn't or it's causing a conflict somewhere you can disable. Now you can select what kind of actions should perform, what kind of rule what kind of action this we have the section for actions and we have a section for conditions now. You and conditions and actions together make a rule, and you only have you can only create a maximum of five rules. Now the let's create the first rule here.

A

The first rule is run a SAS static, application security test and you can select, probably within your uh git lab instance, or your gitlab group. If you're aging gitlabs us, you have specific Runners for certain things or if, for some reasons, you have a runner that is secure somewhere or has some features that you've implemented that you want to run this particular job. You can add a tag.

A

You can specify the tag of that Runner that our runner uses to run jobs. You can specify it here, but here we just select automatically. Then we can also add a other criterias. Maybe you want certain CI variables. If you want to customize the CI, be able to add, you can do that. You can add another action, maybe aside from SAS, it should also do Secret detection. You should check our application for if any Secret has been exposed constantly it should do that now, then, what are the conditions that should we met?

A

So the conditions are you can either you can have two types of conditions, either triggers or Shadows triggers are basically okay or anytime emerge or any time uh your pipeline is running against the particular protected branch that then it should execute. You can either specify the protected Branch or it should execute for all protected Branch. For example, here, if we leave it at the condition that triggers we can specify either all branches default range, all protected branches, or you want to specify a specific set of protected branches.

A

So here I will just select output, protective branches. These two actions should be performed against all protected branches. Let's see master of main production sandbox, any branch type we've protected. This gun should run against them. Now, then we can decide. Okay, we also want it to run based on the schedule and anytime and for Shadows. You can either specify for each to for the trigger to work with your branch or with an agent if you've integrated your gitlab group or project or your instance, with the kubernetes cluster and you've installed the gitlab kubernetes agent.

A

You can specify that agent here for uh discounts to be executed against, which means, for example, if you are using, uh you want applications that have already been deployed to your cluster to be tested. You can specify that before, in our case, you'll be using Branch now here you can also specify specific, Branch or or protected branches.

A

You should run against them, although we can't specify a branch name here or let's just see the default branch and we can set when it should execute daily or weekly at this particular time now. So, let's leave just the uh first condition for triggers now. The next thing is: okay. You've created your rules. This is an example of what it looks like in yaml. So if we switch to yamo mode, you see it has automatically filled with false. So we are saying the type of policy we want to create a scan execution policy.

A

The name is specified, there's no description and the rules is, should be a pipeline and Branch type protected actions it should be scan, should be executed. Sas and another scan should be executed, secret detection. Now it if you are not used to the syntax, it's always best to use the editor like I mentioned earlier. So now to save this, you need to configure with the merge request the way gitlab handles security policies is to store them in a security policy project, a separate project called security policies.

A

Now and when you click on this configure request here, it will create the project and.

A

Give your image request to push this yaml file to the project now. The reason why we create you it puts them in a separate project is so you can either use it for a different project or use it in a group or use it uh for any other project instead of just this one more like repopose it for other projects. Now you can even decide to have created it already in a project and just add it to this, create it separately in its own project, then add it to projects themselves.

A

Now, let's configure uh our match request now, once the project is created, like I said you can add it to as many projects one too many if you want or one to one just for this project now you see it has. What it has done here is. It has created a project and automatically is asking us to merge this policy that we've created to that project, and once you match you see it's the same policy that we saw when we're editing it earlier now. If we merge.

A

Done we'll also notice that okay, let me go back to my subgroup here, see now. Instead of this is our project. Now it has created a new project. This project is automatically generated to manage security policies for the project for this project. Now, once you go back to our project and we'll see secure, go to secure, we go to policies we'll see. We now have this.

A

This is our security policy and we can see the details of security policy. Here, it's going to run SAS it's going to run secret detection and so on. It's enabled I can't even see the yaml file you can edit it. It will take you to the editor and you can make changes if you want so anytime.

A

We come to my project. Now, let's go to.

A

uh Now you see our condition is every time a pipeline runs four, this you should add secret detection and sust. So let's go to our positive here, I think we should have yeah a CI file. So let's check our CFI. What does it do? Okay, it has a SAS already now.

A

If it has access already, if a job already exists, it will run another. Probably there are certain conditions or uh that the main one that in the policy has that this doesn't have now. So, let's run our pipeline. Let me go to build and pipelines, and we can see here that there is no secret detection.

A

So, let's go to Pipelines, then let's click run pipeline against master and run pipeline.

A

Now you see here that we have secret detection, then we have a now. You notice that we have Brickman sast. Then we have big masses to zero. Now the first one is the SAS job that the CI file itself has that it wants to run. Then the second one has a dash view is the same thing, but with a dash is you now the dash zero? Is the one hour policy introduced?

A

Then, if you, if we look at uh that of node.js scan SAS, also we have zero here and here same grip. The same thing. This is like the CI job. The CI file of the project already has a SAS included, templates included, and our policy will still run its own job, even if there's an existing, similar CI job in the local CI of the of the project. The way you can avoid duplicates is to disable certain uh just by setting a CI variable.

A

Sas disable task to disable is equal to false and so on, so that that we within the local project, the SAS or the job, is not executed, but the one from the policy cannot be stopped to be executed. Now.

A

Then you see the alternate executes and we have a down to deploy job. These are just some of the jobs that the um the low costly item of the CI template file of the project has now, let's go back to our secure. This is scan execution policy now, let's now create scan result policy, but first, let's see our security dashboard.

A

If we go to, let's see vulnerability reports, if you come to vulnerability reports here, we'll see that it has secret detection has detected the secret detection. I've added has detected a vulnerability and this vulnerability. Let's see.

A

Oh password is included in the URL, so you can either create an issue for this to be treated or add an existing issue and escalate to the team. Now then, let's create a scan result policy for.

A

Now s go to edit new policy, then scan result policy.

A

Now, within the scan result, policy is similar, but the only difference is in the rules. The actions also, you can only create a maximum of five rules, so tests.

A

Result policy, so it's enabled, then we will now say anytime, there's a security scan and it's you can either select all or you can see. Oh secret detection and it runs against all protected branches and it finds any vulnerability that much the following criteria: either a new survey team of let's see, um let's select all except this or maybe uh you can a new status.

A

Previously existing that means the security is previously existing and it's, uh let's select all, but it's not resolved. The state of the vulnerability is not resolved, but it has discovered it again but not resolved, then what action should it take? It should require approval.

A

How many approval we can set the number of approvals required. Let's leave one approval from you, can either specify a rule or you can specify individuals or you can specify a group, so you can maybe select a group or specify a rule in developer and maintain on owner or you can specify individuals within individuals. You can specify. Okay, let's let me, let's see, for example, I select Michael, you see this is what the rule looks like now. So let me then configure this rule, so it it creates.

A

A second match request in the same security policy projects that we have already now. Let's see the changes, it's introducing.

A

Okay, now it's adding to the same policy file. So let me merge.

A

Done so, let's go back to our project. If we go back to the file, let's say um code repository and I. Look at our policies here, the policy file. Then you see here we have the our scan execution policy. Then we have our scan result policy. Now, let's go back to our project in.

A

Our projects, let me create, um let me make some changes to our application.

A

Let me open the web IDE and, um let's say I just make a small change, application views and welcome and I see hello instead of hello rails. Let's just say hello, gitlab and uh here I will specify okay, welcome, gitlab.

A

Then, instead of committing to master I want to commit to a new branch now I can specify the name of my Branch or I can leave it empty and just hit enter to use any name. Now it does don't call me then I'll create a mod request.

A

Now, within my mod requests, welcome gitlab, Mr and I, assign myself and yeah. It should delete the source Branch. Now, let's create image request. Now, as it's running, you see, it has shown here that it requires one approval from test result policy and that approval is here zero of one.

A

A

Annotation DNS machine uh Michael's name here, it's my teammate, so it's going to run all those tests and it's going to run against also secret detection. Oh.

A

He I think I need to make a change. Our secret detection didn't show up here because.

A

Our scan execution policy only runs against uh only runs against protected branches. So let me change the policy edit policy and instead of only protected branches for now, I'm going to put it to all branches, including um Mr branches.

A

Now, let's configure this to create a match request for us to update and now this is where we are changing instead of protected by changing it to all now, then, merge.

A

Now, once we merge, uh let me go back to my project and.

A

Select here, okay, let's see my mod request and we have this. So let me this is to run in.

A

So now you can see here one of the things that.

A

We have a gitlab security bot is created, anytime, executive policy is created against a project now and here is showing us that the policy violation has occurred. Now. Security and compliance scanners, enforced by organization have completed and identified that approvals are required due to one or more policy violations, review policies, rules, and this is because there's a job that needs to be executed. That isn't so in this case,.

A

Either you review the rules in our case here, I've already fixed the issue. Now, let's close this Mr and introduce a new Mr, then let's see I can okay probably make this again and put an exclamation. Then.

A

We create welcome gitlab on a new Mr, but on a new uh Branch, for example, and let's create a match, request to master assign myself and.

A

Yep, so here now we should see that yep. It now includes all the other jobs, secret detection and so on now.

A

Also, like I mentioned earlier, you can remove duplicates jobs that instead of the instead of discussed scans, to be executed from the policy and also from the local CI configuration. We can disable that of the local project, and we can do that by coming to our CI. Let's see here, we go to our CI file and we say.

A

We can specify a variable sustable, but first, let's look at our job here. Okay, it's executing and let's see it's almost done.

A

You can come under variables to create a variable Let's see. We have our variable here.

A

Sas disabled now, let's wait for this to finish before we start another job.

A

Okay, it's almost done. You need test job and so on now before this is done, one of the things you need to be aware of are additional. Approval is required. One of the issues we encountered in the um previous MRI that we had when it's cut, it's kind of result is can't policy is removed, for whatever reason a a scandal is supposed to happen didn't happen. What is expected by the policy now? Maybe someone stops a security job.

A

The security job that needs to be executed, for whatever reason it was stopped, will be required before the magic rest can proceed now and also if there is a manual job that blocks the rest of the CI.

A

An approval is required before it's proceeds, so it will not proceed until an approval is given before the rest come be completed. Now, uh if we see here, the security board has already mentioned that. Okay, there are policy violations and which needs to be fixed by an approver.

A

One of approval is from DNS Michi, but our CIA is still running. Oh RCI has finished executing, so let me refresh and see what is the violation.

A

Now security scanning detected, no new potential vulnerabilities, so I'll be introducing um I, see a small vulnerability. So let's say I see as ADD dot EMV Dash sample, then I add API key is equal to.

A

So let me put uh an AWS key a sample. Let's just see uh AWS key, then AWS underscore.

A

Secret then I would like you can put any circuit here.

A

Now then, let's submit on the mark now here we can see, add key. Then we let's commit to a new branch and.

A

Press enter then we'll create an MR, so we added key. Let me assign this to myself and create a match request, so this is going to run I see first, it says until everyone approves.

A

This is not going to proceed then.

A

Once the job is done,.

A

We'll see here that there are no duplicates of such job. This time we only have such zeros. That's zeros are zero, there's no such one, because we added the Saturn underscore disabled. So that is how you avoid duplicate jobs. Now, so once this is executed and done, we'll be able to check the security vulnerabilities, that's been generated by the CI. So let's view the pipeline and see okay, what are the things? Okay, it's still running the last job.

A

Now the first kind result policy: the rules are only evaluated after the job has been completed, the CI scan and the CI jobs have been completed. That is when it evaluates and checks. Okay, has this policy been evaluated? Has that policy been evaluated be violated and the results are displayed in the Mr.

A

Okay, let's see our pipeline is almost done.

A

Okay, this is loading, it's almost done once it's done, it will display RCI results here.

A

Now we can see here like showing that we have one critical. We have a new vulnerability and what's the vulnerability, critical AWS access token, because I added a sample token, there I just got it from Google somewhere. So if we click here- and you see here, it's showing that you can resolve it- security, training, okay for security, token to be exposed, huh probably need more trainings for the Developers.

A

Then we can enable security training which is a future of git lab or we. You can also come to review. Oh, what happened. Where was the secret exposed? This was way too exposed and you can create an issue to resolve it yeah. That is how you can set up security policies in gitlab, like we said you can set up security, execution policy or security result policy.

A