Take the 2-minute tour ×

This question already has an answer here:

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.

share|improve this question


marked as duplicate by user16764, Dan Pichelman, MichaelT, gnat, Kilian Foth Oct 16 '13 at 8:55


"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 Nov 9 '11 at 10:57
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 Nov 9 '11 at 15:07
Don't hire an external developer. Then your code will be protected. –  thedaian Nov 9 '11 at 15:12
Should I mention I would never, never, never, ever work somebody with your behaviour and state of mind as an external develloper ? –  deadalnix Nov 9 '11 at 15:43
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 9 '11 at 16:07
show 18 more comments

13 Answers

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?


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.

share|improve this answer
You can also limit the code they have access to when using source control. –  ChrisF Nov 9 '11 at 10:45
@Rajat - And what will prevent him from copy/paste of files? You are being overly paranoid. –  Oded Nov 9 '11 at 14:50
@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 9 '11 at 14:54
@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 9 '11 at 15:11
@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 9 '11 at 17:44
show 20 more comments

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.

share|improve this answer
+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 9 '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 2:55
@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 5: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 –  Ptolemy Nov 10 '11 at 22:09
show 1 more comment

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.

share|improve this answer
"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 Nov 9 '11 at 15:32
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 4 at 20:00
add comment

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.

share|improve this answer
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 9 '11 at 12:51
@sleske Exactly my point though... most of the time if outsourcing and more appropriately offshoring is done right it is impractical. –  maple_shaft Nov 9 '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
add comment

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!

share|improve this answer
Though you can protect it from his brain... If if the code is bad enough, he will want to forget it ;) –  Oded Nov 9 '11 at 10:50
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 9 '11 at 16:20
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
I downvoted becase it's not an amswer to the question, even though I agree with your sentiment. ;) –  Tor Valamo Nov 10 '11 at 5:41
add comment

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.

share|improve this answer
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. –  Simon Richter Nov 10 '11 at 9:15
MS still does this. Look up "Shared Source". –  Yuhong Bao Jun 3 '13 at 6:42
add comment

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.

share|improve this answer
Best solution so far! –  CheckRaise Nov 9 '11 at 20:15
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 7:07
Loved the crazy glue bit! –  C Johnson 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 4 at 19:58
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
Internal developers are not a threat since they work on office site and code stays on LAN. –  Rajat Nov 10 '11 at 4:33
Why not hire a developer to come to your office? Why hire a remote developer? –  Kirk Broadhurst Nov 10 '11 at 4:36
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 7:07
@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
@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 2 '13 at 20:55
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment
