GitLab mulls ban on hiring Chinese and Russian support staff because 'security'
Did Uncle Sam put you up to this? observers wonder
GitLab is considering a ban on hiring any Russian or Chinese support staff in order to improve security.
The debate has been going on for a couple of weeks. In its issue pages, the company said:
In e-group on Monday October 15, 2019 we took the decision to enable a 'job family country-of-residence block' for team members who have access to customer data. This is at the expressed concern of several enterprise customers, and also what is becoming a common practice in our industry in the current geopolitical climate. The countries involved are:
This issue is to track the addition of the process to the support handbook, and whatever recruiting processes need to be update to make certain that:
- We do not make offers to individuals residing in these countries
- Current team members are prevented from moving to these countries and remaining in a role that prohibits it.
We do not have a technical way, today, to handle this based on permissions.
The company also said it was wary of creating two classes of GitLab employee with different levels of access to systems.
"As such we feel a country block is the most humane solution at this time – especially because it affects zero current employees," the notice added.
It will also consider changing the role of any staff member who moves to Russia or China so that they no longer have access to customer data. GitLab currently has no Chinese or Russian staff members.
Response to the proposal has been as divided as you would expect.
GitLab reset --hard bad1dea: Biz U-turns, unbans office political chat, will vet customersREAD MORE
Candice Ciresi, director of global risk and compliance, wondered if more countries would be added in the future and if so on what basis. She noted that tensions were increasing with other countries so that some sort of objective standard should be set rather than just adding countries ad hoc.
There was a general assumption that the customer demand was from the US government.
VP of engineering Eric Johnson said: "Please be aware there is an active, time-sensitive contract negotiation linked to this matter."
A GitLab contributor suggested the ban should cover anyone with friends or family in the two countries who could be used to leverage GitLab staff.
Commentators on Hacker News have admired the company's openness and transparency while others questioned how much worse China's policies are compared to recent US foreign policy.
Some wondered if the ban was security theatre or would have a real impact on integrity of data, and Edward Snowden also got a mention.
The company recently performed a backflip on whether it would pick and choose customers on ethical grounds and allow political discussions at work. A ban was quickly reversed: GitLab staff can talk politics again and the company may turn down business from ethically dubious companies.
It illustrates the difficulty of creating company policy on moral and ethical matters in an iterative way as if it was software that needed bugs removed. ®
Updated at 10:56 6 November to add
Gitlab has been in touch to say:
The US Department of Homeland Security Cyber Security currently lists China, Russia and North Korea as the countries with current cyber threats, so it is expected that the large number of US enterprises using GitLab.com would have concerns about their user data accessed in the countries their government has identified as a major threat.
In the interest of users of GitLab.com, access to their data is restricted to the team members who need it for their day to day work. We currently do not have team members for the roles Support Engineers and Site Reliability Engineers in countries that are identified on the US Department of Homeland Security Cyber Security list of threats (https://www.cisa.gov/cybersecurity), namely China, Russia, and North Korea.
GitLab is considering not opening Support Engineers and Site Reliability Engineers positions in these restricted countries. This has not been implemented at this time, as we are discussing it as a company.
In line with GitLab's value of transparency, and our "everyone can contribute" mission, we discuss and iterate on processes and company policies in the open. By using public issues and MRs we enable and welcome participation and feedback, always within the parameters of the the GitLab Code of Conduct. These discussions are internal business discussions that you would not see happen in the open at other companies.
We are not surprised by many of the reactions to this issue because it is a challenging topic.
We are disappointed by some of the personal attacks that were made in this issue. We need to think about how we can be better at internal dialogue that is made public so that we can minimize misunderstandings.
One of GitLab's core values is transparency; even when it is difficult. I think this issue is a good example of something that is hard to be transparent about because the decision isn't obvious and many will have differing opinions.
We hope that people appreciate the difference between our open and transparent value and what you would see in a non-transparent company where these conversations or decisions are likely happening but are hidden from public view.