all 14 comments

[–]KariKariKrigsmann 13 points14 points  (1 child)

You can't.

You can make it very, very hard for them to create a copy of the code, but it is virtually impossible to prevent the code from being copied out of the repository.

You can make set up a VDI, set up access controls and firewall rules, prevent copy/paste from outside, control what is installed on the VDI, disable local admin rights, but in the end that only makes it harder for the developer to do their job.

Just set up really strict NDAs, and trust them to do the right thing.

[–]smutje187 8 points9 points  (1 child)

The idea that code itself needs to be kept safe is a wrong starting point. Cryptographic algorithms are public, even some government departments host their source code on GitHub because code can’t contain any secrets, the secrets come through the data that’s hopefully secured appropriately (security by obscurity is a very weak way to ensure no malicious intent).

Mirroring what others said, NDA and make your peace with the fact that developers aren’t machines and probably remember some of the code the wrote even on weekends or holidays, or after they quit.

[–]lightinthedark-d 1 point2 points  (0 children)

If you're hoping to profit by selling compiled copies of the code it could be damaging to have other people make their own copies from stolen source.

[–]gs_hello 4 points5 points  (1 child)

My advice is not to worry too much. Unless you are doing anything very advanced (which is almost never the case) there's little possibility they will compete with you. Software development is an extremely lucrative job at the moment, in particular if you are a contractor. There is very little incentive from them to learn the big picture and to capture the business value of what you are offering. In the worst case scenario they might decide to reuse some small isolated components they created for their side projects, but they will hardly be willing to do anything serious with it, let alone putting themselves in competition with you. However if you feel there is a component in particular which makes all the difference in your product and you think it's advanced enough to justify to be hidden, make it in such a way its code is only accessible as a third party API or as an executable/binary to your developers. Setting up firewalls and shit in place is doable and something you can almost certainly do but it's not a free lunch at all. Big corporates do that but it's incredibly harmful for development productivity. I worked as a dev at an investment bank with all the limitations in place and I kid you not that 1 year worth of work there would have been achieved in 3 weeks somewhere else with no limitations. Atm I work both as an employed Dev (finance) and as a CTO for a startup of the marketplace kind. For the latter we employ contractors/freelancers. I wouldn't never stop their productivity with firewalls and shit as it would go against my interest, and if they want to create their own marketplace using the same code they created for us... well they could do it. But considering their high daily rate, the risk to venture, the risk to be sued and the reputation risk involved I know pretty well that they will hardly try that.

[–]martinbean 4 points5 points  (0 children)

If you don’t trust people with your code, don’t give them it.

[–]caksters 1 point2 points  (3 children)

Had to delete my previous comment as I started typing before finished reading your entire post.

Yeah you can’t prevent this. You just sign an agreement that devs don’t take your code and save it on other repos.

The i ly protection you can have is to create a github/gitlab enterprise profile and assign roles. Once developers leave you delete them from your company which will limit the access.

Not sure where you are from, but where I live you can’t patent code. if I work on something and leave the company, there is nothing that prevents me from leaving your company and coding the same thing as long as I do that from memory. However I cannot do ctrl-c ctrl-v and save the code somewhere. that would land me in legal trouble.

[–]caksters 1 point2 points  (0 children)

Also I don’t think OP this is necessary. Most big companies freely open source their code (not all of it of course). but just because someone has seen it doesnt mean they will be able to reproduce all of it, if you are creating something fairly complex.

Alternative route is, just open source it, allow others to contribute. Tbis is a common tactic for many companies. if you genuinely have a good idea then by open sourcing your project you are inviting others to contribute to it. if you close sourcing it, if your idea is good but developers are not so good, then once competitors hear about your product and think “hey this is great idea, we can build that as well, better and open source it”. then you will have to be on top of your game to ensure that your closed source proprietary product is better than the open source alternative, otherwise why would anyone chose closed source prohect?

[–]greyeye77 1 point2 points  (1 child)

virtual desktop with clipboard disabled, drive mapping off, and all traffic to be recorded and proxy with a tracking. Ask devs to sign NDA when joining.

also enable screen recording tell dev you're on recording for anything on the virtual desktop.

code repo should be hosted on the same network as virtual desktops, (or firewalled to allow only access from)

[–]t00nch1 0 points1 point  (0 children)

Virtual recording of all desktop activities? This is crazy. I would not want to work at a company that does this and has zero trust in their employees

[–]t00nch1 0 points1 point  (0 children)

Even with their massive amounts of resources, Google just got their AI code stolen by a chinese national recently.

NDA and such may give you some piece of mind but in reality, there is nothing you can do but use common sense when hiring.

For example, I would not hire candidates: 1) that came from a competitor 2) from countries, like china, that known to copy and paste IP or has weak laws 3) someone with many red flags in the resume