GitLab Secure Stage, 22 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab SAST Automatically resolving SAST findings Demo

Description

Staff Backend Engineer Lucas Charles does a quick demo of the new GitLab 15.10's feature to auto-resolve Static Analysis vulnerabilities when rules are disabled

- Release post: https://about.gitlab.com/releases/2023/03/22/gitlab-15-10-released/#automatically-resolve-sast-findings-when-rules-are-disabled
- Documentation https://docs.gitlab.com/ee/user/application_security/sast/#automatic-vulnerability-resolution
- Feature Issue https://gitlab.com/gitlab-org/gitlab/-/issues/368284

A

Hi everyone, my name, is Lucas Charles I am a staff backing engineer on the static analysis team at gitlab and uh today we're doing a quick demo of the new auto result feature for static analysis findings in the lab 1510..

A

um Let's go ahead and click off kick off a quick demo. Then.

A

Now, if we look at the release, notes that came out today for our 5010 release, you can see this item for automatically resolving SAS findings when rules are disabled now. The basic idea behind this feature is that sometimes There are rules that are not applicable to a specific organization or project, um or we have simply refined these rules over time.

A

Those are the two main cases here, so in the case of this initial one that is um disabled, one for a specific rule, type across a project or group, and in the latter many times throughout our release cycle, the stack analysis team will work on refining rules to reduce false positives, improve rule accuracy and sometimes remove them entirely now.

A

The way this feature works is by essentially ingesting the specific uh rule, types that are understand and auto resolving any ones that are no longer detected that we are not currently scanning for, but that's probably easiest to show. So, uh let's jump and go ahead and jump over here to an example project.

A

Now, in the case of this project, it's a pretty straightforward project. Codewise, we have three occurrences of vulnerabilities here. One is detect etholic expression and two occurrences of this detect object injection. If we look at the CI configuration.

A

You can see that it's enabled to recessed, and we also have our stag analysis, custom rule set enabled here which we'll get back to in a second. If you actually look at the customer set configuration, there's two things that are going on in here one. We are overriding. Some graphs default rules with a local configuration which really only has those two rules enabled for Simplicity, and we are also overriding the severity of this specific Rule and detect object injection.

A

Now this is a fairly common use case, where um a user may not necessarily want to remove a rule entirely, but they might just want to lower the severity. So it doesn't seem it's it's simply not a severe in their opinion for uh whether it's applicable to code base or their specific project.

A

Now this particular rule detect object. Injection tends to be a fairly high in terms of noise and false positives, so this is actually one of the ones that we haven't Auto removed.

A

It is a good example, though, so in this case, we'll take a look now. If we look at the latest pipeline, you can see that it has those three vulnerabilities that I pointed out earlier. In this case it is a detected eval with expression and two occurrences of detect object injection here here Now, the default behavior is established in nutriage, because I haven't manually, changed it to a confirmed or dismissal, and you can also see from the activity badges that it is in the still detected State.

A

You would be able to see this detection badge here here or here if they were no longer present on the default branch uh prior to the 1610 change. There's really two occurrences of seeing that no longer present badge one was either the finding was removed or is no longer present, and the other is that the rules type is no longer under scan. So this new feature aimed at Auto resolution, uh aims to address the ladder which is when a rule is removed in tie rod.

A

Now as a quick demo, we can go over here and let's go ahead and remove that secondary occurrence. Here we'll just comment: it up: oh we'll, remove too tired and then we'll take 30 seconds to let this pipeline run as soon as this job finishes. What we're expecting to happen is one of those two detect object. Injection findings will have that special badge on. If that means it's no longer detected, which is to be expected.

A

Okay back to the dashboard, we now see this badge here, because uh this finding was deleted. It still requires a manual triage step for us to set that to resolve and recognize that it's mitigated, but for now we're just going to leave it in the default state. So all of our findings are still untreated.

A

Now, if we go back to our custom, real estate configuration here, what we're actually going to do instead is we're going to want to remove this rule entirely instead of just disabling it. So the process for that is. uh We can essentially ignore this override if it's no longer present, because um we are actually going to remove it from the yaml configuration itself.

A

So, let's go over to our rules here, edit the file and we'll go ahead and remove this entirely.

A

Now, what's going to happen when this pipeline finishes running, is that the.

A

Two findings here that were previously low should now both be no longer detected because we remove this rule type entirely um prior to the 1510 change. What would actually happen is this badge would be applied to both of these here, because we did not previously distinguish between findings that are no longer present versus findings, I've no longer being scanned, but with this new 1510 release, we will actually be Auto resolving these, and we will be adding a dismissal comments explaining the rationale: let's go ahead and check on our pipeline.

A

Okay, so it looks like our pipeline finished now. The process for auto resolution uh takes a second, as that needs to finish for the resolution comments to apply so we'll just go ahead and give this a minute before we visit our vulnerability, dashboard.

A

Okay, now before I go ahead and refresh this page, I just want to make a note here that, immediately after the pipeline ran, you can see that these were marked as remediated as they are no longer being detected, and then the secondary process kicked off to actually resolve them. I'm going to refresh now and now see that only the tech Devo with expression is still in the need for your state. If we set to all statuses, we can see that these are both marked as resolved and by clicking through.

A

We see a nice message from gitlive security bot that this was automatically resolved because the vulnerability type was disabled, and that is the new 1510 feature for automatically resolving SAS findings. If you have any questions, please feel free to reach out to us and happen to address any uh questions or concerns that come up. Thank you.