GitLab Govern: Security Policies, 8 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Compliance Enforcement of Security Policies 🛡️

Description

Parent epic: https://gitlab.com/groups/gitlab-org/-/epics/9704

A

Hello, I'm Grant, Hickman I'm, the senior product manager for the security policies group here at Gail, lab I wanted to walk through some of our plans today around compliance enforcement of security policies. So I'll start by talking through why this is important. Some of the problems that we're going to be focusing on and then we can speak to some of the solutions or plans that we have in place today so first off. Why is this important and when it comes to security policies?

A

Essentially these are the guard rails by which organizations operate, and this allows us to surface compliance requirements or internal requirements defined by some initiative into policy, and these policies are often correlated with some type of business risk. So, for example, an organization may have requirements through Frameworks such as sock 2, and to ensure that multiple reviewers review any changes that may impact production.

A

Another case might be that an organization has identified a number of potential risks and they're, creating a security initiative that they want to Define policy and enforce against all of the software development life cycle. So this may be a policy that runs security scanners. Identifies vulnerabilities before they're introduced into production, and then they can address or mitigate those those risks.

A

However, security goes beyond just encouraging the right Behavior. We also have to ensure that we are compliant that 100 of the time we're mitigating risk, once these policies have been defined, and sometimes that exceeds just internal desires from a business to mitigate risk, but there can be real real life, pragmatic, practical legal implications if compliance is not properly met and that may results in fines or other penalties so to address. You know these pain points. We've identified, Three core problems to address within this Epic.

A

The first is the use case I just mentioned briefly above, and that is a common core requirement from customers, as well as some of our own internal stakeholders to be able to enforce, review and approval by multiple reviewers on every merger quest, which is ultimately every change that may impact production.

A

So this ensures that there's, no single user that can unilaterally introduce a vulnerability or negligently introduce something that may cause risk to the business.

A

The second problem is, is really a set of different scenarios where users might circumvent a policy, so we want to make sure that any policies that are enabled are enforced 100 of the time. uh But what what could uh happen or what could occur is that project owners or maintainers may use several mechanisms, um maybe uh well-intentioned, but they may use these mechanisms to circumvent um these requirements. So an example is renaming or unprotecting branches.

A

So if a policy is targeting the main branch specifically, then it's it's possible to change the name of your default Branch to circumvent that policy, and maybe the user does this temporarily and then they change the branch name back to main once they've merged a change maybe to address a hotfix or or something that is again well-intentioned they may also.

A

If a policy is targeting protected branches, then they may want to modify a branch to unprotected, circumvent the policy and then and then change that setting back a few other options are pushing or Force pushing to protective branches.

A

So this is a setting that could be modified at the project level and perhaps the owner maintainer may make this change, which allows them to force uh Force, Through, Changes and circumvent the merge requests process altogether, which means there are no reviews and potential negative implications of of the changes that they're making and then the last one is another set of of settings within project settings for merge, request approvals and what you can do is enable or disable the setting to allow merge requests authors to make their own changes and merge them or approve their own changes.

A

This could allow a committer so someone who's contributing to emerge, requests to commit a change and also approve that change and if a commit is made to the Mr. After all, the necessary approvals are accepted.

A

Then that can circumvent the approval process and essentially the the subsequent or ladder commit, could introduce a vulnerability that has not been reviewed.

A

So within this epic, we've got a number of sub epics that we'll use to address these challenges and close the gaps from a compliance standpoint, and then the last problem I wanted to call out is, is really as a result of the first two we're expanding the scope of our scan result policy type. So, rather than only evaluating policies or evaluating merge requests based on the result of security scanners, we can also Target any merge, request and add these additional requirements and modify project settings in any project.

A

So we're updating the name to merge, request approval policy to reflect that change in scope.

A

Okay, so let's go into some of the individual sub epics and speak to those changes that we're planning. Okay, what I do want to highlight real quick. We have completed two uh two solution: validations um working with users to validate the change in name, tumors, request, approval policy as well as validating the ux and the flows that we've defined here. So you can find more information there and I'm, also working on capturing some of the feedback that we've had from customers and stakeholders. I. Don't think this is comprehensive of all the customers.

A

Obviously they're interested in this. This is a very common point of feedback that we've uh we've received, so we're working on kind of capturing it collecting those here.

A

Okay, so uh going back to problem one, we want to enable order, enforce two percent approvals on all merge requests, so the sub epic. That will focus on that.

A

Is this epic here so allow users to enforce EMR approvals as compliance policy?

A

So the first change that we'll be introducing is INS in the new merge request, approval policy type we'll introduce a new option in the configuration to Target any merge request how we will have a setting, so you can enforce that against any commits or just any unsigned commits.

A

um There will be an option here to also override project settings, so this will ensure that two percent approval does happen in every case, um and so we can talk about each of those options, but then the last part of the flow is some existing functionality, but this is where you can Define the number of approvers required and rather than in the current scenario, requiring an approval from a security reviewer when a scan result, finding violation occurs.

A

In this case, you can Define two approvals required, for example, from a developer or maintainer, so two approvals with those two roles, and so that will ensure that any numerous request that's created will enforce and require this. This additional reviewer approval.

A

Okay um and then yeah, let's speak to these settings that could I think there's a lot of kind of technical details to cover there. So the first we'll talk about the four different settings here: there's prevent approval by merge, request author uh prevent approval by anyone who has added a commit, and then, if there is a commit added after approvals, have been given, then we want to strip the approvals and and require them again. So for these three settings we will default to true there's a fourth setting that we can override and I.

A

Think this one is just a bit less common, so we'll default that to false, as the user hovers over each of these options, we want to provide a little bit more context so as you're defining these policies, we'll have a hover state that provides a more detailed description.

A

um And, let's see uh what can happen here too, is this. These settings can be enabled on any policy and we'll have these defaults, but you may have one policy: that's targeting one set of projects and other policies that that's targeting a different, a completely different set of projects depending on the requirements, um so we'll have the options available in every policy. But what can happen is you may have conflicts?

A

So maybe you have one policy that has uh prevent approval by merge, request, author and then uh the second uh does not, and then it instead has this setting enabled. So what we want to do is is to default to the most secure posture or position possible.

A

um Another scenario might be that the target project actually has these settings all enabled, but the policy does not have these settings enabled so in that case, as well default to the most secure position and let's keep that setting enabled for the project.

A

So, if, essentially, if, if any policy or the project has a setting enabled, we will keep that setting enabled for the the target project and then lastly, I wanted to note here as we roll all the changes, this could impact existing policies. So, while these are defaulting to true for new policies that we create, uh we want to default all to false for existing policies so that users can actually make that change and communicate and work with those project teams as needed before beginning enforcement.

A

Okay, I think that covers everything in that section: okay, yeah next, so we covered problem one. Let's talk about the various circumvention flows, so we'll note that the branch related flows here are already in planning breakdown, already ready for development. So we've been discussing these, but I'll just highlight very quickly what we're working on there.

A

So first off, we are introducing a new option to select default, Branch, protected branches or all branches I'm. Looking for the design, so here they are.

A

um So, rather than today uh explicitly listing um the branch name, such as main users will be able to select default any default branch. That means that, regardless of the branch name on any of the projects that are being enforced, we will enforce the policy against the default Branch so that that circum avoids that circumvention of renaming the branch to something different will always enforce against the default. Branch same goes for protective branches. If you have more than more protective branches, Beyond default, you want to enforce against.

A

You can select that option and you could always also select specific branches.

A

The scenario that can happen here, though, is you- may have a scenario where you're targeting or enforcing against protected branches, but maybe some some developer has by accident, marked their branches protected, and it is not relevant for the enforcement rather the policy. So there there is a flow to be able to work between the developer and the security team. That manages the policy to add their Branch as an exception, and that would free up the user to be able to protect that branch and uh and avoid the the um enforcement.

A

And I think you know related to this effort. There are some um projects setting over rides that you'll see in a different epic to where we, we lock the ability to unprotect the branch. So I'll call that out here shortly.

A

um Yeah and I think this one we've covered in the past, but we we speak to the yaml and some of the detail required to be able to add exceptions.

A

So we would capture the name of the exception branch and then the full path for the um for the project and group or if we want to create an exception, Branch exception against an entire group. You can just specify the group level.

A

Okay, let's see if there's anything else, I need to cover here.

A

I, don't believe so.

A

Okay, moving on to the next two kind of options for circumvention here, there's Force pushing and pushing so that's covered in this epic. Here.

A

um So these these two settings we want to uh to be able to disable I'll note that this is um anytime, that we have enabled uh one active security policy. If there's one active security policy enabled in that in that project, for the targeted protective branch, then we're going to disallow these settings to push or to force push and so I kind of wanted to highlight and call out. This is an implicit enforcement, so you there are, isn't a control or setting that can be enabled or disabled.

A

So the the only option that we'll have here, if you want to enable that setting, is essentially to disable the policy or to remove this project from the scope of of the enforcement.

A

um We will also want to include an error so where the scenario would come up as more likely in the terminal when you're actually trying to do a push or Force push, so we'll want to create our own custom error response to alert users that you know this is. This is not an option that they're disallowed from pushing or Force pushing.

A

um And yeah both of these features I think we'll we'll definitely want to ensure that pushing force pushing that these occur at the same time, because this will be a change in the behavior of existing policies.

A

So we'll want to create a banner message and start alerting users in advance of rolling this feature out, so that can give them time to if they want to disable policies or modify the scope of their policies or alert their own teams, that these settings will be disabled. Moving forward. They'll have time to to do that or provide feedback to us.

A

A

All right yeah, so uh so once this happens once we've disallowed the policy again, this is the design I wanted to kind of call out for Force, pushing or unprotecting branches, uh we'll also be going into the projects and changing some behaviors there. So you'll see that the allowed a force push option will be grayed out.

A

I think this needs to be updated in the design now, but this is the other setting if you want to push or if you want to force, push we'll gray, that out once you've protected a branch you'll see the protective Branch list appearing elsewhere in the settings as well, and then that way you can modify from there and protect the branch.

A

So these settings allow to force push a lot of push and merge will be grayed out and unprotect and then we'll have a hover state to give more context to the user that these settings have been disabled by a security policy to work with the security team to to manage the policy. If there are any any concerns, for example, if they wanted to um have a branch added to an exception, so we'll have more detail and documentation to link to there.

A

And while it's not in the in the design, this uh push to merge or push and merge State. uh What we'll want to do is enforce essentially that no one is selected and that it's grayed out. So this may be something we can continue to iterate on in the design itself. But we've called out that requirement here.

A

And we talked about error messaging, so this is uh just kind of going in more detail about how that could appear in the terminal.

A

Okay, yeah, if you have questions on that, please let me know.

A

So we covered reading branches, uh unprotected branches, pushing and force pushing, and the last one is in terms of circumvention would be these merge request, approval rules so I think we kind of did speak to that to some degree yeah. We talked about it here, so um I think I would just note yeah these. So these are settings that are in uh merge, request approval settings in each project.

A

Oops I'll need to update that link.

A

I'll just find it request.

A

Approval settings I think yes, so uh that maps to these approval settings uh here.

A

So when we are in the project, settings I think that's that's something that may not be clearly called out um in the project settings in the design, but I think we'll need a similar, lock and hover state for users to show that we've disabled these project settings so I think that'll be a follow-up action for me from this video, okay and then the last problem that we call out is just the change in the policy name to merge, request, approval policy and so that'll be the last epic here.

A

Yeah and we've uh been documenting uh the various locations that we'll want to update um the the text here. This is just a terminology change, but we will want to make some changes in the uh in the yaml want to make changes in our various screens and the breaking change of um of using I. Believe we decide on approval policy here in the yaml we'll want to to roll that change out in 17-0 as it's a breaking change, but that is what we'll be working on in this Epic.

A

Okay, um anything else to call out checking my notes.

A

Yeah I think there's.

A

One note is that we do have. um We do have this epic currently assigned to group source code, so we'll be working with them to see. You know if this is something that they'll be able to include um on their end or if we need to take action from how we're in to implement it, but we will definitely be collaborating with uh source code on these changes.

A

um So just keep that in mind all right uh yeah if there are any other detailed questions, please reach out in the um in the relevant epic or just reach out to me and we'll we'll keep working to refine and start breaking this down for development. Thanks for your time,.