GitLab Compliance Group - Product, 16 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Use a single, not multiple, compliance frameworks for a project

Description

Sam Kerr talks about compliance frameworks, why GitLab only allows one to be applied to a project, and some best practices on how to think about combining multiple sets of requirements.

Product documentation: https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration

A

Hi, I'm sam kirk, I'm a principal product manager here at gitlab and today in this video. I wanted to talk to you a little bit about how you can think about get labs compliance frameworks and how to work through the case where it seems like you might need multiple compliance frameworks for project and how to really only use a single compliance framework. Instead, one of the things that gitlab does with our compliance frameworks is that we only allow you to apply one to a given project at any given time.

A

This might seem like a limitation, but it's actually very much intended and it's a feature designed to help reduce uncertainty or ambiguity for different requirements that might be defined.

A

I'd like to walk through a short visual description of what this might look like at a conceptual level and talk about how you would solve this problem and then we'll go ahead and look at how you would solve this problem using actual gitlab projects actual get lab compliance from.

A

So let me share my screen. So what I'm sharing right now? Imagine that we have a hypothetical project called my project.

A

Furthermore, let's imagine that the team that works in this project works in north america and that the project is also being uh paid attention to by sox and the group that manages sox compliance.

A

Furthermore, let's imagine that in this organization any project that sits inside of the north america division has to follow certain business requirements.

A

Let's also imagine that any project that has to remain compliant with sox also has to follow certain business requirements.

A

It might appear that would be easy to apply a compliance framework label for any requirements required by the north america division and then apply another framework label that implements any requirements required by the sox division and that the project would be easily able to comply with both, but this is actually going to be misleading and I'm going to show you why we get like don't allow using multiple compliance frameworks for this sort of use case now.

A

Imagine if we had gone ahead and added two different compliance framework labels to the my project, one for north america division and one for the sock team, sox team. Imagine if each of those frameworks define defines conflicting requirements in this simple example. I'm saying that the north america division might be saying. Projects must not run the acme test 3.0, while the sox specific requirements say that a project must run acme test 3.0, because these requirements are conflicting.

A

Gitlab doesn't know how to resolve these resolve that conflict or that ambiguity, because that conflict has to do with the unique business requirements and organizational requirements that are being applied to this project.

A

So what needs to happen here instead is that the team either managing the project or someone in the north america division or the sox team would have to figure out which of these requirements would take precedence, and so, instead of applying multiple labels potentially running into these conflicting sort of scenarios at gitlab, we require only a single compliance framework label to be applied to a project and the way that we suggest that teams still meet the different requirements from say a north america division and a sox team division is by creating those as templates and then including one of those templates into another and forming their ultimate compliance framework pipeline in that manner.

A

So, basically, what this might look like is the compliance framework requirements would start with anything defined at the north america division that must not run acme test. 3.0 example- I talked about previously that would be defined as a small template or a small snippet that would be included into the next file, which perhaps the sox team has written, which would say in this case that a project must run the acme test 3.0 scan and that this should take precedence over any other requirements. So overriding that north america division's requirement and removing the ambiguity.

A

At that point, we will have had a single file which can then be applied to the my project. The compliance framework and compliance pipelines can be run without any sort of ambiguity or conflict, so conceptually. This shows why we only allow a single compliance framework label to be applied to an individual project to gitlab.

A

Now that we've looked at this from a conceptual level, let's take a look at how we might actually implement this inside of a real gitlab project, all right. So now that we've looked at a conceptual example of how we might want to bring together multiple sets of different requirements in a compliance framework. Let's look at how we might do this actually in gitlab, and so the screen that I'm sharing right now is our compliance demo project and in it I have a few files.

A

We have a file for the north american requirements that we talked about previously, as well as a file to contain the specific requirements that we also looked at and if we look at the north america.yaml file, what this is doing. This is implementing that required job that we want to run, and in this case it's saying we want to run the acme scan 2.0 rather than the 3.0.

A

If we look at the socks.eml file, we'll see the same job as being defined, but in this case we want to run acme scan 3.0, and this matches the conceptual example we just looked at. So, let's take a look at our compliance job yaml file, which is going to show how to bring these two sets of requirements together in a single pipeline definition file and the way that we're going to do this is we're going to use an include directive in this file and we're going to include those north american business requirements.

A

Then we're going to include the socks.aml file with the specific requirements and then finally we're going to end by including the project specific uh configuration.

A

This is going to be what actually builds the application, what builds the developer's code, and so then this will be our single definition for how we reconcile those two sets of requirements which may conflict with each other. In this case, we're resolving that conflict by just saying use any definitions that are in socks.yaml to override anything. That's been defined in north america.aml, but this is where we would do any sort of more involved sort of disambiguation.

A

If we wanted to run an acme scan 4.0. For example, we could define a new job here to update or change any of those requirements as needed, and so, if we go look at the actual application development project which is going to be using that compliance framework, we can see it has our demo framework compliance framework label applied and if we go click into the latest pipeline, we can see our required job was added, as we would expect, and if we click into it, we will see that acme scan three redux was run.

A

So what we've looked at in this video are a few different things. We've talked about why gitlab has intentionally limited our compliance frameworks to having a single framework applied to any given project to avoid the problem of ambiguity or conflicting requirements. If multiple frameworks were applied, we've talked a little bit more about what that looks like at a conceptual level and how to disin disambiguate that by including multiple sets of requirements together in a single definition and resolving those conflicts.

A

We also looked at an example of how you can do this in practice with git lab using include directives as part of your compliance pipeline. Configuration so I hope this has been helpful if you have any questions, comments or feedback, we'd love to hear from you again, I'm sam kerr, my handle is at st kerr at gitlab, if you'd like to have a conversation, feel free to tag myself or any other team member on issue. We'd love to hear from you thanks. So much have a great day.