GitLab Shared Responsibility Model: A Guide to Collaborative Security

GitLab is a popular DevSecOps and collaborative software development platform that enables businesses to automate software delivery, boost productivity, and secure end-to-end software supply chains. However, not everyone knows that like most SaaS service providers, GitLab operates according to the so-called Shared Responsibility Model (or Limited Liability Model).?

This model recognizes the responsibilities of each party at the very moment when a customer creates an account on GitLab and starts using this service. But, do all the users know what responsibilities they have at the beginning? Not sure.?

Thus, let’s try to understand what is a GitLab Shared Responsibility Model and what obligations each of the parties has to follow in order to achieve the code repository security.?

What is the Shared Responsibility Model?

To make a long story short, the Shared Responsibility Model is a framework for cloud security that defines the security duties for both SaaS providers and their users. It defines that a provider takes care of the infrastructure, and the entire service while a customer should think about his own data and related metadata.?

Though GitLab provides a rather full package of tools, including backup and retention schemes, it is always a good idea to know what is really included in the service and what you, as a customer, should think of.?

GitLab’s Shared Responsibility Model in action

Being transparent with its documentation, GitLab states: “As part of GitLab Inc’s contracting process, GitLab provides all terms and conditions with our customers to ensure all parties understand the shared responsibility model.” So, let’s dive deeper and look closely at the GitLab Subscription Agreement where the Git hosting service states all the responsibilities of both parties – its own and its users.??

What is GitLab responsible for?

If we peer into the GitLab Subscription Agreement mentioned above we will notice that “GitLab shall be responsible for establishing and maintaining a commercially reasonable information security program that is designed to”:?

• guarantee the confidentiality and security of GitLab user’s content;
• guard against potential threats to the security of the user’s content;
• prevent unauthorized access or unauthorized use of the user’s content;
• make sure that GitLab’s subcontractors, if there are any, abide by the aforementioned requirements.

It sounds security-proof, doesn’t it? Moreover, if we look at the GitLab Trust Center, we can see that GitLab has a proven compliance and assurance credentials path. The service provider has passed numerous security certifications, including SOC 2 Type 1 and 2, SOC 3, ISO 27001, ISO 27017, GDPR, and others. Thus, it has high-security standards to protect its data: “In no case shall the safeguards of GitLab’s information security be less stringent than the information security safeguards used by GitLab to protect its own commercially sensitive data” (Subscription Agreement: Security / Data Protection).

So, GitLab is responsible for access to the platform and the infrastructure, backup which is run on the same Linux server as GitLab, configurations and maintenance modes, upgrades (here it’s worth mentioning that GitLab isn’t available when the update is in progress for single node installations), and infrastructure-side Disaster Recovery.?

And what about the user’s data? Here is what is stated in the same document:

So, are the users responsible for their data? Yup… Let’s continue talking about it…

A Customer’s Responsibility: Deep Analysis

While GitLab takes care of the entire system, a customer is responsible for his authorization credentials and all the data in his code repository. It can include Repositories, Wiki, Issues, Issue comments, Deployment keys, Pull requests, Pull request comments, Webhooks, Labels, Milestones, Pipelines/Actions, Tag, LFS, Releases, Collaborants, Commits, Branches, Variables, GitLab Groups. So as not to sound unfounded, take a look at what is stated in GitLab documentation:?

Once again, users are responsible for the security of their accounts, “passwords, and files”. It means that if something, for example, accidental or intentional deletion of the data takes place, the customer’s problem is figuring out how to restore it if possible.

Don’t forget it’s a myth that if your account data is deleted or corrupted GitLab can recover it. Read our blog post from the DevSecOps MythBuster series where we have already debunked this myth: “GitHub / Atlassian / GitLab handles backup and restore” – busted!?

Let’s look further into the Shared Responsibility Model

After figuring out which security obligations both parties have, we should definitely speak about cooperation… As the GitLab Shared Responsibility Model, like any other of its type, emphasizes the collaboration between the platform provider and its users. Here are the key aspects that are worth mentioning as well:

Education and training

There are thousands of resources and documentation that GitLab prepares to educate its users about best security practices. Thus, in turn, users should always try their best to stay in the loop – read documentation, blog posts, and undergo security training to boost their security skills.??

Feedback and reporting

As it has already been mentioned GitLab encourages its users to provide timely feedback about any issues they face. By promptly reporting vulnerabilities or any suspicious activity, users not only play an active role in the security ecosystem but also help the provider respond to the issues faster.

Continuous improvement

As any other SaaS provider, GitLab regularly updates its product. So, it’s critically important for the users to follow these updates as they are usually aimed at improving user experience and security.?

What can go wrong?

Human mistakes, ransomware attacks (which are on the rise now!), service provider’s outages, or your own infrastructure outages – all of that can severely impact your business continuity and, what’s worse, lead to data loss. Why not track the history of incidents and see on Use Cases why your GitLab data needs proper protection??

GitLab’s backup failure

Let’s just remember the year 2017 when the worst incident in GitLab’s history took place. Due to the accidental deletion of data, GitLab suffered an outage and needed urgent database maintenance. The service provider’s backup failed to restore, and, consequently, users who used the SaaS solution suffered data loss:?

“The company has reached out to confirm that the outage only affects GitLab.com – meaning that customers using its platform on-premise are not affected.” TechCrunch

Proxyjacking and cryptojacking malware attack on GitLab

In August 2023 researchers from Sysdig were alerted to a persistent campaign of attacks targeting vulnerable GitLab servers that resulted in the deployment of proxyjacking and cryptojacking malware, leveraging the platform’s resources for the attacker’s own gains.?

Though, GitLab effectively addressed and patched the mentioned vulnerabilities labeled as 13.8.8, 13.9.6, and 13.10.3 in April 2021, “individuals who failed to apply these patches have now become targets for the LABRAT threat.” – states Cybersecurity Insiders.?

Is there anything DevSecOps teams should be aware of??

If a company is really conscious about its repository data, it will think about backup – it’s nice to have the possibility to roll your data back in case of a failure. They can make up their own backup options, such as backup scripts, clones, and snapshots, or use any other GitLab backup option. But at the same time, they should keep in mind that they will need to do it manually, which is time-consuming and takes a lot of resources.?

Well, it may seem easy and cheap but in the long-term perspective, it will be tiring and cost-ineffective. Why? In short – in a situation like that, somebody from the company will need to switch from his usual duties to provide backup copies. He will need to make those backup scripts, snapshots, and clones, keep his hand on the pulse to delete the old ones because they can waste a lot of storage space, and, when it is needed, write the script to restore the data. So, your developer will be always distracted from his core duties, which will affect his productivity.

Psst, it's not the end of the story... ?? We have more things to say on this topic! Read the full article and find out what options you, as a GitLab user, have to protect your data: GitLab Shared Responsibility Model: a guide to collaborative security.