25

My company is going to hire an external developer to create some new modules and fix some bugs in our PHP software.

We have never hired an external developer by the hour before. How can we protect the source code? We are not comfortable giving out source code and were thinking that everything remained under a surveillance enabled VPN which external developer would log in to.

Has anyone solved this problem before? If so, how?

Edit: We want the developer to see/modify the code but under surveillance and on our machine remotely. Does anybody have a similar setup?

Edit 2: NDA is just a formality. IMO, even people who are in favor of NDAs know that it'll do nothing to protect their property.

Edit 3: Let me clarify that we aren't worried about the developer copying an algorithm or a solution from the code. Code is coming out of his brain, so naturally he is the creator and he can create that again. But our code is built over several years with tens of developers working on it. Let's say I hire an incompetent programmer by mistake, who steals our years of work and then sells it to the competitor. That can make us lose our cutting edge. I know this is rare, but such a threat has to be taken under consideration if you're in business. I'll make points of my comments so its easy for everyone to communicate:

  1. Why NDA sucks? Take this scenario, if anyone is capable of suggesting a solution to this scenario I will consider the NDA effective. Ok, here goes: We hire 2 external developers, one of them sells our code as it is to someone else after a year. You are no longer in touch with any of the developers, how are you supposed to find out who ripped you off? NDA does provide a purpose, but you can't rely completely on that. At least we cannot.

  2. I did not meant to offend anyone while I was posting this question, even though unintentionally I did. But again to people answering/commenting like 'I will never ever work with you' or that Men-in-black-gadget thingy: It's not about you, it's a thread about how feasible a given technical solution would be. And if anyone in this community has worked under such an environment.

  3. About 'Trust', of course we won't hire anyone we do not trust. But is that it? Can't someone be deceitful at first? We all trusted a lot of politicians to run our country, did they not fail us ever? So, I'm saying 'trust' is a complete other layer of protection like NDA, and my question was not directed to it. My question is rather directed towards technical measures we can take to avoid such a thing from happening.

DukeBrymin
  • 103
  • 1
Rajat
  • 323
  • 1
  • 3
  • 5
  • 35
    "not comfortable giving out source code" - especially since PHP is a scripting language (i.e. it's all source code), could you explain what the developer will be working on, exactly? I can't really envision how "here's the bugs we have, fix them without touching (or even looking at!) the source code" is supposed to work. – Piskvor left the building Nov 09 '11 at 10:57
  • I actually meant "not comfortable giving out source code on their machine". – Rajat Nov 09 '11 at 14:58
  • 27
    How does it matter, where the code is actually stored, physically? If they can *see* the code, _any way at all_, they can *copy* the code - even if they had to go all low-tech and videotape their screen as they scroll through the codebase, or even look at it, memorize a line, retype into a different machine, repeat for each line. (of course, such convoluted scenario is not really necessary if they are to have edit privileges: 1. open remote file in editor, 2. select all text, 3. paste into local file, repeat for any interesting file) – Piskvor left the building Nov 09 '11 at 15:07
  • 25
    Don't hire an external developer. Then your code will be protected. – thedaian Nov 09 '11 at 15:12
  • 3
    "Know that it'll do nothing?" An NDA will give you the right to sue him into bankruptcy if he distributes your code. It can (and HAS) happened. I don't know what universe you live in. – riwalk Nov 09 '11 at 15:13
  • 2
    In universe where we don't want to pay lawyers, and want to try to fix the problem ourself first. – Rajat Nov 09 '11 at 15:42
  • 70
    Should I mention I would never, never, never, ever work somebody with your behaviour and state of mind as an external develloper ? – deadalnix Nov 09 '11 at 15:43
  • 2
    @Rajat: Well sorry to disappoint you, but this is not the Harry Potter universe. Magic doesn't work here - and that's what you're essentially asking for. Some problems are unfixable by technological means. – Piskvor left the building Nov 09 '11 at 15:47
  • 13
    Even if you bringing the person on-site, strip and cavity searching him, and put him in a room with no internet access he can still steal your code by memorizing the important bits. – CaffGeek Nov 09 '11 at 16:07
  • 1
    Not so, @Chad. Here's [one idea](https://www.ubersoft.net/comic/hd/2010/08/unlogical-solution) :-) – Karl Bielefeldt Nov 09 '11 at 17:25
  • @KarlBielefeldt - This is suspiciously like my idea that involved a *second* remote contractor and a rubber mallet. My brain must have a security leak. – psr Nov 09 '11 at 17:43
  • Rajat, how can the company you work for be sure you haven't already taken the code? I can see past your sneakyness. – CheckRaise Nov 09 '11 at 20:16
  • 2
    Implant a chip in their brain that will explode if they read your source code, then give them SSH access. – Ben Brocka Nov 09 '11 at 22:40
  • 1
    It is not unreasonably unpractical for me to put up a webcam and records all the text on the screen and then browse through the source code while recording it on an external computer. You really should wake up and stop fooling yourself into thinking you can do anything about this issue beyond NDA's (that do hold up in court, despite what some people seem to think). – Kit Sunde Nov 10 '11 at 01:05
  • 1
    To everyone posting negative comments: Feel free to criticize but do that in a constructive way. I'm willing to take it. This will not only educate me but others too. – Rajat Nov 10 '11 at 02:39
  • 3
    "Don't hire an external developer. Then your code will be protected" and you do trust your own people? Most leaks are not by contractors but disgruntled employees... – jwenting Nov 10 '11 at 07:01
  • 6
    Developers hate code, they really do. Especially if it's written by someone else. Codebase is a pile of crap that you have to work on during the day. It's not a candy store: nobody wants to take it home and do anything with it. I can't imagine developers stealing code, they are more likely to take few ideas and rewrite the whole thing from scratch for themselves if anything. – Dyppl Nov 10 '11 at 10:15
  • 1
    "You are no more in touch with any of the guy, how are you supposed to find out who ripped you off?" After *any* employee leaves your company, kill them. Fool proof method. People either won't leave, or they won't live long enough to rip you off. Then, just don't let them have internet or leave their desks to protect your company from current employees. – thedaian Nov 10 '11 at 14:43
  • 5
    Is your code really so valuable and magical that someone will want to steal it? Surprisingly little code actually falls into that category IMO. If you have a few functions that contain company secrets, just don't give them access to those few functions. – Bryan Oakley Nov 14 '11 at 19:31
  • 5
    What you are trying to do is to have a technical solution for a social problem. It has been stated: If the hired developer wants to steal your code, he will do that no matter how hard you try technically. You can only do things to protect yourself IF that happens: Set up a contract that gives you ownership of his code, have him sign an NDA about the code you give him and if stuff happens you have legal grounds to sue him. Sorry to say, but there is no other way – klaustopher Jul 22 '12 at 13:12
  • 1
    Exactly _why_ are the sensitive bits sensitive? –  Jul 22 '12 at 13:33
  • You could always just have him killed later. That's what we did when we CGI'ed the moon landings for Nasa – Martin Beckett Jul 28 '12 at 03:04
  • I bet the next question from this person will be asking why they should **not** pay the developer after he's completed the work. – Reactgular Oct 15 '13 at 20:15

13 Answers13

69

Use source control. There is nothing a remote developer can do that will not be reversible.

Apart from that, depending on what you mean by "protect", you should have the right contract with him, including NDA.

On another note - why hire an external developer in the first place, if you are not going to trust him?

Update:

Now that you have clarified that by "protect" you mean "not allow to get the sensitive code", my points above about NDAs and trust remain unchanged.

When it comes to source control, if you have several repositories where you have different levels of code (boilerplate - not sensitive, infrastructure - not sensitive, business logic - very sensitive etc...), you can select which repository to give access to this developer. Of course, this depends on whether you can segregate like this and still have a working application (for this to work, some repositories may require having binary dependencies checked-in - these would be compile artefacts from the sensitive repositories). The feasibility of this depends on what you want the developer to work on.

Even with the scheme described above, you need to consider decompilation and reverse engineering of code (this is always possible with a determined enough attacker) so obfuscation of code/binaries may be another thing you need to consider (again, this is not perfect - with enough know how and determination, the best obfuscators can be defeated).

In essence, my point is that if you want to protect a sensitive code base, you should only give access to the sensitive portions to people you trust.

Oded
  • 53,326
  • 19
  • 166
  • 181
  • 8
    You can also limit the code they have access to when using source control. – ChrisF Nov 09 '11 at 10:45
  • 2
    @ChrisF - Depending on source control system, yes. – Oded Nov 09 '11 at 10:46
  • 2
    You can ask the external developer to work in his own branch, merging back regularly from trunk. At the end of the contract, after a review by someone from your team, you merge back his change into trunk. – Xavier T. Nov 09 '11 at 12:10
  • We already use source code control, but that's not what I'm asking here. I don't want developer to run away with the code. We're looking for some VPN setup etc. which we can have in our architecture and let our developer login to the machine using remote access, what do you think about that? – Rajat Nov 09 '11 at 14:49
  • 12
    @Rajat - And what will prevent him from copy/paste of files? You are being overly paranoid. – Oded Nov 09 '11 at 14:50
  • If we have surveillance over him, and can see every activity he's doing on our machine, it will be impossible for him to copy the source code, right? The repo server can be made accessible to that machine only, so he can't checkout from anywhere else. – Rajat Nov 09 '11 at 14:52
  • 13
    @Rajat - And who will be sitting there watching his _every_ keypress? And when he is copying a bit of code in the file, how are you going to prevent him from pasting it into his own computer? Can you explain to me why you feel the need for such over the top surveillance? Can you explain why even hire someone external if you are not going to trust him at all? – Oded Nov 09 '11 at 14:54
  • 2
    @Rajat - The correct way to ensure he "doesn't run away with the code" is to put that in his contract explicitly. – Oded Nov 09 '11 at 14:55
  • Not every keypress, but a software we use at our workstations which pull off user screenshots at random interval will solve the problem. This is not 'top surveillance', one of our competitor is doing it too. But we lack the knowledge to implement it or plan it. – Rajat Nov 09 '11 at 15:00
  • 4
    @Rajat - Again, this is silly. How will pulling random screenshots tell you anything about what the developer is doing? How will it tell you that he hasn't copied the whole repository to his computer? – Oded Nov 09 '11 at 15:07
  • 12
    @Rajat The kind of surveillance you suggest would take more man hours than actually just buckling down and doing the work yourself. You are fooling yourself. – maple_shaft Nov 09 '11 at 15:11
  • @Oded Because he would be working on our machine via remote connection. – Rajat Nov 09 '11 at 15:44
  • @maple_shaft Maybe I am, but I can't close my eyes when clearly this model is working for someone else. I think it'll be best solution than any NDA or anything. Tools to pull screenshots etc. like this already exists. – Rajat Nov 09 '11 at 15:45
  • 4
    @Rajat - Your competition may **think** this model is working for them. I assure you it doesn't. Read what Piskover posted as comments to your question. Try it yourself. – Oded Nov 09 '11 at 15:49
  • 3
    @rajat firing off screencaptures won't stop the external dev from being able to copy/paste out of the RDP session which would be the most trivial way for an unethical person to steal the code. – Dan Is Fiddling By Firelight Nov 09 '11 at 16:33
  • 2
    @Rajat: They *exist*, sure enough - which only proves that the demand for "miraculous cure-all solutions" (read: placebo) is still high in this supposedly rational age; not that they actually *do* what the maker says (i.e. protect code from being copied). – Piskvor left the building Nov 09 '11 at 16:44
  • This answers Well. Use something to protect against damage(Source Control), and then something to protect against theft(NDA). – Nicholas Nov 09 '11 at 17:44
  • 25
    @Rajat, even if he's using a remote connection, he's still ON a computer, in behind the terminal session can be a million apps running that you'll never see. And he can record the entire session without you knowing. Thus, getting an entire copy without your knowledge. There is NOTHING you can do. He could even go low-tech and just setup a camera to watch and record the screen... You're just wasting money in trying to prevent it. **If you can't trust the person DO NOT HIRE THEM**. – CaffGeek Nov 09 '11 at 17:44
  • 2
    @Rajat If the code is this valuable and you have to hire him, fly him in to your office and make him code naked. Oh, and when he's finished, be sure to flash him with one of those pens from "Men In Black". – LarsTech Nov 09 '11 at 19:58
  • @Dan Neely It'll still give him feeling of being watched and will avoid such thing IMO. – Rajat Nov 10 '11 at 02:44
  • @Chad He cannot record millions of lines with a camera. In fact, he wouldn't even need to open thousands of files in our case. – Rajat Nov 10 '11 at 02:46
  • 8
    @Rajat, then only give him access to the files he needs to see... problem solved. What the hell kind of software is this that you need this kind of security. Somehow I doubt if it's that cutting edge or proprietary, you would be outsourcing your work. – CaffGeek Nov 10 '11 at 14:35
  • Source control is irrelevant to the issue the OP raises. Of course, the issue raised by the OP is also stupid, but source control doesn't keep people from walking off with a copy of the code. – mjfgates Jul 21 '12 at 20:01
  • @mjfgates - I answered the question long before the OP edited it to explain what he meant by "protect". I disagree that source control is irrelevant - you can restrict access to repositories and only give access to code that is not as detrimental to the future of the company... – Oded Jul 21 '12 at 20:08
55

There are two ways of working with people:

  1. Control:
    • monitor all their actions
    • dictate their processes
    • restrict their freedoms
    • keep them exchangeable
    • make a clear distinction between them and you
  2. Collaboration
    • respect their freedom
    • trust them
    • build a long term relationship that both sides benefit from
    • work as a team

You go choose. But IMHO you shouldn't expect people, whom you openly treat as if they were potential criminals, to treat you fair in response. So here is a crazy idea:

  • be forthcoming and fair
  • actively engage in creating mutual trust and loyalty
  • don't be greedy and pay on time

If you make people feel, that they are in a satisfying, productive and lucrative business relationship, they will stick to you. And that is exactly the same for contractors and employees. Nothing can stop your employees from quitting and taking the source code with them, except an incentive to stay.

So make your work pleasant and worth working on, rather than wasting resources on freakish control.

back2dos
  • 29,980
  • 3
  • 73
  • 114
  • 9
    +1 because employees who physically show up to work are just as good a position to run away with your source code. This question actually seems a little crazy to me. If you don't trust a remote developer then why go down that road? – Pete Nov 09 '11 at 18:08
  • I loved your answer but I have a disagreement over the word 'freakish'. Another disagreement: Control and Collaboration goes hand-in-hand together, you can't just focus on one in business. So do we not respect our employees freedom? Of course we do. Do we not trust them? Of course we do, we trust them to solve some of the toughest problems using their code. We trust them for everything - that is why they're sitting in our office right now. Do we not build a relationship and work as a team? Of course we do. That's the entire reason why our company is making money in first place. – Rajat Nov 10 '11 at 02:55
  • 2
    @Rajat you trust that they can solve the problem, but you dont trust that they can keep the solution to themselves? – Tor Valamo Nov 10 '11 at 05:38
  • @Rajat: My point. If you work like that with your externals, they will be just as loyal. – back2dos Nov 10 '11 at 12:16
  • As the conductor / product manager on a project, control is good. What you choose to control is the key. Control the environment that you give your developers complete free range inside. Make the environment that each developer is within appropriate for that developer, and as they develop, their environment expands – Michael Shaw Nov 10 '11 at 22:09
  • @Ptolemy: I am not saying control in itself is bad. I said control as the means of a professional relationship is. One should control processes, not people, but that is something completely different. – back2dos Nov 11 '11 at 09:28
19

Simply put: You don't.

Professional developers take this kind of thing seriously. They are well aware of the importance of the code, and the consequences of stealing bits and pieces of it. If they are caught, it is a stain on their reputation as a professional, and could affect their livelihood in a meaningful manner.

Others have suggested an NDA, and while it is not a technological means of "protecting the code", it is often all that is needed. Functionally, there is no difference between internal and external programmers. You have to cede some amount of trust to all of them.

Ryan Kinal
  • 1,481
  • 10
  • 14
  • "Not technological" - quite correct; the technological solutions are all variations of DRM, and thus broken-by-design (as an attacker may be also a legitimate user). – Piskvor left the building Nov 09 '11 at 15:32
  • 1
    Two words: Edward Snowden. Even the most secretive divisions within the US Federal Government don't have a good solution to this problem. What makes you (the OP) think you can do any better? Build your solution on trust and reasonable containment, not on superficial technological restrictions! – rinogo Feb 04 '14 at 20:00
9

You should never allow outsourced or I would argue temporary contractors access to any code that is highly proprietary, extremely sensitive, or code that contains valuable algorithms or other business secrets.

Even having them sign an NDA or a Non-Compete is likely useless as they commonly do not hold up in court.

This mad orgy of offshoring all development possible is a pox on the industry and self defeating strategy. Offshoring or outsourcing makes sense with menial, tedious, or well solved and understood development problems. It was never meant to save money on the unique work and bread and butter.

When you lay your companies most proprietary and industry specific code to bare for the world to see then you are literally inviting future competitors to rise and challenge you.

With that being said, do a close evaluation of your code base and decide what code you would not like them to see and see how easy it would be to restrict their access to this through source control. If there is nothing to troublesome or worrying about your code then the application likely has very little substaintial value to steal.

Many companies like to think their codebase is special and highly proprietary when in reality it is little more than a simple CRUD app. In which case you might be more concerned with exposing all of your business requirements and possibly your data model, where the most business knowledge would be stored. This can be mitigated by focusing on giving them access to presentation code and restricting access to data access code.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • I don't really think it's practical to only give access to some parts of the source. Unless your app is very neatly divided into independent modules, this will severly hamper the efficiency of the developer. E.g. it will make it impossible to integration test changes, or to understand why a certain internal API makes sense. – sleske Nov 09 '11 at 12:51
  • 1
    @sleske Exactly my point though... most of the time if outsourcing and more appropriately offshoring is done right it **is** impractical. – maple_shaft Nov 09 '11 at 13:16
  • Outsource != Offshore. Also, what if his developers lack some important skill? Should he be just a patriot and not hire the developer he needs? – Boris Yankov Nov 15 '11 at 18:02
8

Make a contract with the external developer that he's not allowed to give out the source code to outsiders nor keep it after his hire has ended. If he violates the contract, then it's a legal case. You surely can't protect source code from the developers' eyes though!

Joonas Pulakka
  • 23,534
  • 9
  • 64
  • 93
  • 18
    Though you can protect it from his brain... If if the code is bad enough, he will _want_ to forget it ;) – Oded Nov 09 '11 at 10:50
  • 4
    These kinds of cases tend to fail in court because they are just so hard to prove. If someone steals your proprietary secrets and you have to seek legal action, **then you already failed**. – maple_shaft Nov 09 '11 at 16:20
6

Probably 90% of the value in source code is the development team, support team, and user community you build around it. Unless this is some kind of super-secret game-changing start-up, the source code is essentially worthless to a third party. Even Microsoft released Windows NT code under NDAs at one point to certain people outside Microsoft. My advice is to require an NDA and be prepared to defend it with litigation in the extremely unlikely event that your IP is used somehow without your permission.

PeterAllenWebb
  • 933
  • 8
  • 12
  • 1
    Not only did they release the code under NDA, but the NT source code was leaked to various torrent sites, with no adverse effect on Windows sales at all. Windows CE always comes with full source code, even in the evaluation version that can be downloaded [for free](http://www.microsoft.com/download/en/details.aspx?id=20083). – Simon Richter Nov 10 '11 at 09:15
  • MS still does this. Look up "Shared Source". – Yuhong Bao Jun 03 '13 at 06:42
  • "Unless this is some kind of super-secret game-changing start-up..." Many people already think their startup is in this category, so adding that exclusion doesn't mean much. –  Nov 03 '14 at 05:52
6

Why not give the contractor a company laptop that can only connect to your VPN? Then put a firewall on the VPN that blocks of any email/bastebin type sites, install a keylogger on the machine, and fill the USB slots with krazy glue.

CamelBlues
  • 1,145
  • 1
  • 6
  • 14
  • 3
    Best solution so far! – CheckRaise Nov 09 '11 at 20:15
  • 1
    actually worked in a similar environment, where the same measures applied to both contractors and employees. All writes to external devices were encrypted by hardware, all reads were decrypted (so any files not written on one of the company's machines couldn't be read by those machines either, preventing malware injection). Doesn't prevent someone from writing out sections of code on paper or nowadays on a tablet or pda of course, but a policy banning those in the offices can solve that loophole. – jwenting Nov 10 '11 at 07:07
  • Loved the crazy glue bit! – C.J. Jul 22 '12 at 22:55
  • Is this answer satire? (A reasonable recommendation, sure... But come on - a good developer will likely be able to circumvent these measures. All he has to do is find one weakness in order to exploit it.) – rinogo Feb 04 '14 at 19:58
  • @rinogo I don't think it's satire. A relative came to visit me recently and he brought a company laptop where he couldn't do anything other than work and it used to connect to a VPN. Even Bluetooth was disabled. – vaibhavS Jan 05 '21 at 15:10
6

A number of points here.

Its highly unlikely that anyone except you and your company attaches any value to the source code.

If you expose you php on a public web site, unless your encoding DNA or something intrinsically complex then any competent developer could reverse engineer your algorithm in days or weeks.

Why would an external pose any more risk than an employee, the office cleaner or any other person who could access the code.

If the code is truly valuable then a standard freelance contract would give you all the legal protection you need.

James Anderson
  • 18,049
  • 1
  • 42
  • 72
5

The best way to ensure you get a poor developer is to treat him like a criminal with his every move monitored through some surveillance system. No one competent would put up with that for even a couple of seconds.

Do not hire people you can't trust for any postion.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
2

You could black-box sensitive parts of you project and separate them from the rest. Give an easy, well documented interface to interact with those modules without exposing what goes on inside. This way hired programmers can easily work on your project without even seeing what they don't need to see while still being able to use what they need to use.

Pieter B
  • 12,867
  • 1
  • 40
  • 65
1

How does your company protect the source code from you and your fellow developers? What's the stop you and your coworkers from stealing the valuable source code and selling it to the competitor?

Whatever works for you should work for the remote developer.

Kirk Broadhurst
  • 4,199
  • 18
  • 27
  • Internal developers are not a threat since they work on office site and code stays on LAN. – Rajat Nov 10 '11 at 04:33
  • 3
    Why not hire a developer to come to your office? Why hire a remote developer? – Kirk Broadhurst Nov 10 '11 at 04:36
  • 5
    and what's to prevent them from zipping up the code and putting it on a USB stick or mailing it somewhere? Putting it on an ftp dead drop site maybe? – jwenting Nov 10 '11 at 07:07
  • 1
    @Rajat, it stays on the LAN? Like it just keep circling round and round on the wires? Coding must be a real treat, having to alter packets as they pass by! – CaffGeek Nov 14 '11 at 18:36
  • 1
    @Rajat - To be frank, you're delusional if you think internal employees aren't a threat. It's IT Security 101 - your employees are *the biggest* threat, for a number of reasons (ranging from malice to just plain stupidity). SOX exists for a reason. – Shauna Jan 02 '13 at 20:55
0

Microsot did protected it's code, has anyone any idea how? well here is the thought, Microsoft paid it's employees so well that they never thought about leaving the company, the ones who left certainely tool the code with them, look at the example of Iron Python and it's development team, no one could do anything about it, it was taken to google, besides you can just get the NDA's and documents which can say that you cannot get the intellectual property, but then again

a) it's hard to proove, a developer may easily say that they had the code before they even started your company, how would you proove that wrong. I have read a lot of legal books which makes it impossible to determine that the code belonged to a certain organization.

b) There is no law in the book which prohibits writing a competitive software, if this happens it's called antitrust( there are a lot of IP lawyers who deal in antitrust cases), which means monoply in promoting open and fair competition, in england it could be reported to OFT (office of fair trading) not sure what they do in USA, from what I heard the district attorney(attorney general) or public prosecutor deals with these cases.

MoinK
  • 11
  • 1
0

If you are really that jumpy about allowing an external developer access to your source code, then just hire them to create the new modules, and fix the existing bugs yourself.

That way, the only code the outsider ever sees is the code she has written herself.

Paul Butcher
  • 2,817
  • 1
  • 18
  • 18