GitLab Govern: Security Policies, 29 Sep 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Using GitLab Security Policies to Enforce Vulnerability Management SLAs

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Hello Grant Hickman, here from the security policies group, we recently released additional scan result policy filters in 163 and I wanted to highlight one of the filters that we've added around defining SLA based filters, essentially to block merge requests. So essentially the policy that I've created.

A

Is not visible okay, so the policy that I created by default here is is what is commonly seen in a lot of configurations today, where we're running a dependency scanner or some security scanner and based on the severity we'll block the merge request. So in this case, if we find a critical finding from dependency scanning or high or medium severity, finding we'll block them as requests and require approvals based on the action here and in this case I'm allowing one approval from developer, maintainer or owner.

A

So in this first example, you'll see that I've raised a merge request. It introduces a new dependency and some changes in the package Json and yarn lock files that our dependency scanner has then detected and we've we've detected these two. You know high and medium severity vulnerabilities which are causing violations for the security policy and therefore it is blocking the merge requests and requiring an approval.

A

So what I'm going to do next is I've created a new policy here.

A

That I'm calling block dependency scanning vulnerabilities, reduce noise and, in this policy, I have I've set a similar rule as we had before for critical findings. So if there's a critical finding we'll still block the merge request, I've also added some attribute filters to filter out false positives and fix IFA dependency of scanning vulnerability does not yet have a fix available, we'll filter those out which we won't see yet in this demo, specifically, but maybe in a follow-up.

A

But then what I've added from an age or SLA based filter standpoint is that I've added additional rules here. So if we detect a vulnerability with a high severity, then we're going to ignore that results in the Mr for three days that Mr can then be merged. The vulnerability would appear in the vulnerability report and you can then create an issue set a due date for 30 days and give development teams time to address the issue before and Mars are blocked.

A

But if we do detect that again past 30 days, we'll start blocking the merge request for that, given finding so we've done that for a high severity and then for a medium severity. We set the age to 60 days, so I had this disabled I'm going to enable this policy.

A

And then, when I go back to the policy management screen, we'll see that this is now enabled and then the default policy that I had I'm going to disable.

A

So I'm just going to go back this way. All right now, I can see. Reducing noise is enabled default, is disabled, so we'll use the new policy in favor of the old go back to the merge requests and I'm going to go ahead and refresh this job and I'm going to pause. While the pipeline is running here,.

A

All right, so the the job is completed re-running and we have a different result. You can now see that this approval rule appears. This is the new security policy for blocking dependency scanning vulnerabilities, but we're working to reduce the noise of these approval requirements only to focus on what is actionable and what is aligned with our organizational policy.

A

So if we scroll down here to the Mr widget, we can see you know we have the same findings here. We have a high and medium severity finding, but per the policy we're only going to block the merge request. If that finding is critical- and in this case it is not- we have a high medium, so there is no approval required.

A

We could go ahead and merge this and then work on kind of setting up an issue to follow up and address it and in 30 days, if it is not addressed, we would begin blocking this merge request if we detect that same dependency, scanning vulnerability, again, cool I hope that is helpful. Thank you.