> As such we feel a country block is the most humane solution at this time--especially because it affects zero current employees
Edit: I've provisionally gone with "Gitlab blocks hiring SREs and Support Engineers in China and Russia". If that's wrong, or if anyone can suggest a more accurate and neutral title, we can change it again.
Maybe substitute "not" for "blocking" as well since that seems clearer.
Please note that we're still discussing this change. We work out in the open so you can see us working on it. I hope that people appreciate the difference between that and what you would see in a non-transparent company (probably nothing, they would just not open up a vacancy in the offices in that country).
Additionally would this extend to individuals who are of Chinese or Russian origin? China in particular leans on nationals who are on visas or have family still in country to conduct espionage operations.
Discriminating on origin is likely illegal.
It sounds like you just need to harden your production perimeter. Jump boxes with two-man-rule access and terminal logging. Apply the same practices to data as you do code.
> Discriminating on origin is likely illegal.
You should ask your legal folks about the national security exceptions of Title VII. It sounds like your customer requirements are pushing you in that direction anyway.
The irony...
I've danced this dance at a previous company when we had an employee working from a country of interest for an extended period of time. They were air-gapped from our systems and it worked because they submitted everything by pull requests (the original way, sending git patches by email). They didn't have access to our CRM or any customer systems because several of our contracts - not just with governments but also major multinationals - prevented employees in certain countries from having access.
Even when I traveled to the same country I used a burner laptop that was decommissioned when I returned. When we EOL'd laptops in the office they'd go in the burner pile to have one last holiday abroad before they were wiped again and sent to a local charity.
So, someone in, say, QA or documentation, looking to head into SRE or Support, would be unable to if they presently reside in China or Russia.
Meanwhile, if the government can just arrest you and say "change this repository and you go free", it's essentially free.
Security isn’t absolute, it’s layered. The harder you make it for the adversary, the more it costs the adversary (eg: potentially burning a zero day), and the more chance there is of detection.
Can Russian intelligence get into Gitlab? Probably. Are measures that make it more expensive liable to deter them? I think so.
Two points here. First of all, failing to acheive absolute security is not a justification for ignoring best practices.
Second, this isn't air gapping. It is preventing a bugged laptop from sitting in on conference calls and meetings for the next year or two until it gets aged out.
Their employment being dependent on them residing within specific locales is not the same as "prevention". It's an incentive scheme, afaik.
It could affect present employees who are in other roles, located in China or Russia, from moving to a covered role, whilst continuing to reside in China or Russia.
<BOLD>See self-reply below, not the case.</BOLD>
Though that is alluded to as a possibility, with complications.
________________________________
Update: My first read was incorrect.
That would seem to apply to current employees in Russia / China who are in roles covered by the block.
Which is kind of A Big Deal.
X: "Current team members"
A: "moving to these countries"
B: "remaining in a role that prohibits it"
X are prevented from BOTH A AND B.
(X may do neither A NOR B)
Or:
X are prevented from (A AND B).
Whether or not remaining in one of these countries and MOVING to a role that prohibits it is included in the prohibition is unclear.
Someone's future transfer may hinge on that.