Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
How to manage a Closed Source High-Risk Project?

I'm working on an institution that has a really strong sense of "possession" - each line of software we write should be only ours. Ironically, I'm the only programmer (ATM), but we're planning in hiring others.

Since my bosses wouldn't count the new programmers as people they can trust, they have an issue with the copies of the source code. We use Git, so they would have a entire copy of each of the projects they work on, when they clone the repository.

We can restrict access to them to a single key with Gitolite and bind that to their PC's, but they can copy those keys to another computer and they would have the repository access in another PC. Also (and the most obvious method) they could just upload the files somewhere else, add another remote, or just copy the files to an USB drive.

Is there any (perhaps clever) way to prevent events like these?

EDIT: I would like to thank everyone for their insights in this question, since it has been not only more eye opening, but also a firm support of my arguments (since you basically think like me, and I've been trying to make them understand that) against my bosses in the near future.

I am in a difficult situation work-wise, with my coworkers and bosses (since I'm basically in the middle) being like two gangs, so all this input is greatly, greatly appreciated.

It is true that I was looking for a technical solution to a people problem - both the management and the employees are the problem, so it can't be solved that way (I was thinking about some code obfuscation, perhaps working with separate modules, etc., but that wouldn't work from my developer POV). The main problem is the culture inside and outside the company - development is not taken seriously in my country (Venezuela) so naivity and paranoia are in fact a real issue in here.

The real answer here is an NDA (something that here in Venezuela doesn't completely work), because that's the people solution, because no sane developer would work in those conditions. Things will get ugly, but I think I will be able to handle that because of your help. Thank you all a lot! <3

share|improve this question
117  
It sounds like you are asking for a technical solution to a people-problem. If we take this a step further, how would you prevent the new programmers from committing the lines of code they saw / wrote to memory and copying them down later? –  GlenH7 Oct 17 '12 at 16:32
150  
Wow... remind me to never apply for a job there. –  Walter Oct 17 '12 at 16:35
35  
If your boss don't make the difference between intellectual property and real property, then he is likely to be as competent in the business than he is technically. Is he pointy haired ? –  deadalnix Oct 17 '12 at 16:50
34  
There is an easy technical solution to this problem. Don't write any code. No code, no leaks, no problems (other than the problems that would have been solved by the code). –  emory Oct 17 '12 at 17:08
35  
I've worked for people like this. Their companies never grow past a certain point because they are unable to give up control and ultimately fail in some area. I don't think I'd consider this a long-term career although being the first programmer in a company can certainly give you some great experience (Does he mind you taking THAT with you when you leave?) –  Bill K Oct 17 '12 at 19:20
show 17 more comments

marked as duplicate by MainMa, gnat, Walter, Mark Trapp, ChrisF Oct 20 '12 at 15:29

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

14 Answers

up vote 123 down vote accepted

If you don't trust other developers, don't hire them. Working with people you don't trust is synonymous of failure.

Technically, there is nothing you can do. You can force the developers you don't trust to work in a closed room on a machine which is not connected to the internet and doesn't have USB ports and search every developer each time he leaves the room to be sure he don't have any electronic device which can hold the code, and even then, they will be technically able to get the code, for example by writing it on a piece of paper and hiding it in their clothes.

share|improve this answer
36  
-1 - Of course there's something you can do. Do you think armored car companies trust all of their employees? Do banks have to trust all their developers? They all have various security measures in place to prevent both tangible theft, and IP theft isn't that much different. How do you think defense contractors handle it? This is a misleading and provably wrong answer. –  Scott Whitlock Oct 17 '12 at 17:29
57  
@ScottWhitlock I'm sorry but how do you stop people from memorizing a block of code they're writing and then going home, rewriting it from memory and selling it? Though this is a ridiculous fear, it is 100% possible and 100% unstoppable if an employee so chooses to do it. This is precisely why MainMa is spot on that you must trust your developers. (As well as having contracts and a legal team to enforce trust violations) –  Jimmy Hoffa Oct 17 '12 at 17:47
23  
@JimmyHoffa - if you're talking about a code base of any significant size, then the amount you can memorize is insignificant compared to what's at stake. That's like saying that since people can steal my garden gnomes, what's the point of locking my car? People tend to take the easy route, and that's making a digital copy. –  Scott Whitlock Oct 17 '12 at 17:49
8  
@ScottWhitlock I'm not speaking about stealing the entire code base, there are of course plenty of security tactics available to make that difficult, I'm just saying that regardless of security measures; you need to trust your developers, because you can't completely stop them from acting against your interests. –  Jimmy Hoffa Oct 17 '12 at 17:54
24  
@ScottWhitlock, you don't need to take the entire code base, just the important proprietary bit. Any decent dev can recreate what they've done a second time if they need to. The value is in the novel approach to solve the problem. That's what developers do, sovle problems. Code is merely the recording of the solution. And the real IP, the solution, the intangible thought that solved the problem is impossible to protect. If I'm working on the next big thing at apple, they can't wipe my brain from knowing what it is...and if I know what it is, I can recreate it. –  CaffGeek Oct 17 '12 at 20:36
show 7 more comments
  1. Make them sign a non-disclosure agreement.

  2. Only hire people you trust.

  3. Compartmentalize your code base. Use of dependency injection so you can give them requirements that, when finished, resulting classes would fall right into place into the existing architecture, but they will not have acces to the "complete picture", only loose pieces. Only senior, trusted people would have clearance to the "architecture glue" that makes all work as a complete whole.

share|improve this answer
18  
I wouldn't recommend the last one, because it would prevent any dev to do smart stuff. Any competent dev would runaway from such a situation. The conclusion is not hard to deduce. –  deadalnix Oct 17 '12 at 16:48
17  
@deadalnix: #3, if done properly, makes code much easier to maintain; it forcefully avoids coupling. I'd say this approach is more common on very large projects. That being said, I don't think the OP's company is at the scale needed to justify it. –  Brian Oct 17 '12 at 17:05
14  
I have nothing against separation a project in different parts. I have something against hiding the larger picture. This is making your devs blind on purpose. Do you think ANY dev that can choose his/her work will accept to play this stupid game ? –  deadalnix Oct 17 '12 at 17:33
12  
@deadalnix given enough money yeah. I worked for a DoD contractor once. Closed environment, two separate machines (one with Internet Access for research one without for coding), and it was obvious that what we were coding wasn't the full product. Everything you could complain about a software project was there. But boy did they pay! It was soul crushing but I looked at my bank account every week and continued on. –  Mike Brown Oct 17 '12 at 18:28
6  
@stackmonster An example: the developer or an Eclipse plugin doesn't have to have access to the Eclipse code, only to the plugin interface definition. I suspect that in a company like Apple, for instance, very few developers have access to the whole code base of iOS. –  user61852 Oct 17 '12 at 20:37
show 12 more comments

I love the idea there might be a "clever" idea that "we" as developers would be baffled by. Given that every developer tool written was written by a developer and all that.

Your boss's biggest problem is naivety with a dash of paranoia. I'm being polite there. Really really polite.

If you really want a shopping list of things to keep your code proprietary, just implement the following:

  1. Disable USB and other IO on all company computers. This can be done through most enterprise anti virus or similar.

  2. All developer machines to be desktops or towers. No laptops.

  3. Do not allow any machine to connect to the internet. No web, ftp, email, IM, no internet. Cut the wires.

  4. No remote working/access (sort of covered by no internet, but some smart spark might suggest a VPN)

  5. No mobile phones or other electronic devices to be taken into the secure "development" room.

  6. Configure all printers to print a large visible watermark on every page, front and back.

  7. bag searches both in and out. Search for hand written notes, anything printed on company printers (anything, they might have hidden code in an image with steganography!). Any electrical or electronic devices. In fact, probably best to ensure bags are kept out of the secure area and developers should wear clean suits, the sort of thing you'd see in drug dens and chip fab plants.

  8. Servers should be equally isolated, back ups should be encrypted and only your boss should know the password to restore from them.

share|improve this answer
5  
And even then, good old memory works great. And without cavity searches... –  CaffGeek Oct 17 '12 at 20:44
11  
Hah, you know I started adding a 9) developers might remember something, but couldn't think of a way to fix that besides filling the developers with vodka :) –  Ian Oct 17 '12 at 20:51
23  
9. No outside phone calls allowed from landlines etc (they could tell someone the code over the phone). 10. Developers must work in windowless room then they can't shine a torch out the window and transmit the code via morse code. 11. Developers must be neuralized after completing each day of work. –  zuallauz Oct 17 '12 at 21:19
8  
why send them home? Keep them in the building, food and drink passed in through an airlock system only. –  jwenting Oct 18 '12 at 11:28
14  
14. Don't ever run software written by developers. It can contain malicious code that steals confidential data and sends outside the company –  Adam Dyga Oct 18 '12 at 14:16
show 8 more comments

If the people in question can't be trusted to keep to their employment contracts, then he needs to not hire them.

If he believes NO ONE can be trusted, then he's being overly paranoid, and he's ultimately going to damage the company if he keeps it up.

At some point you MUST trust your employees. It's not really an option to do otherwise. If you don't trust your employees at all, then they can't possibly be effective, because you're spending too much time distrusting them, and wasting a lot of their time jumping through hoops due to trust issues.

Also, when you make it clear to people that you don't trust them, they tend to get annoyed. And annoyed programmers eventually find another job where they aren't treated that way.

The right solution is a basic background check, a well-thought out employment agreement, and some trust.

share|improve this answer
9  
"If he believes NO ONE can be trusted, then he's being overly paranoid, and he's ultimately going to damage the company if he keeps it up." - VERY TRUE. –  GrandmasterB Oct 17 '12 at 21:07
add comment

I used to write code for classified computer systems. They had all sorts of ridiculous hoops to jump through to keep it secret. For example, we weren't allowed to bring music CDs into certain rooms because they could be CD-RWs in disguise.

The thing is, practicalities of the work open up security holes out of necessity. Sometimes you had to transport non-classified data/code into or out of a classified area in order to get the job done. Yes, there were rules and procedures for that, too, but they all eventually boiled down to trusting people. Instead of trusting people not to put classified data on a convenient usb thumb drive, you're just trusting the exact same people to jump through all the security hoops.

In other words, there are a lot of things you can do to protect from outsiders, but once you let them in, it's pretty much just a question of how much you want to annoy them.

share|improve this answer
3  
Some of those security hoops are for other reasons. For instand usb thumb drives often carry malicious files. So following the procedure to transfer files off a classified system, prevents the system itself from being compromised, indivual files are protected by other security rules. –  Ramhound Oct 17 '12 at 19:09
    
and to prevent files being taken out, you can customise your operating system to automatically encrypt everything it writes to any destination, and decrypt it again when reading. Anything not encrypted yields only read errors, anything encrypted is useless outside the company. Worked for one company that did that (albeit in hardware, they used superglue to glue shut any serial, parallel, etc. port on the computers). –  jwenting Oct 18 '12 at 11:32
    
"For example, we weren't allowed to bring music CDs into certain rooms because they could be CD-RWs in disguise." -- Thanks Brad! –  Gaz Davidson Oct 18 '12 at 13:37
add comment

In short, you need to have a non-disclosure agreement/contract with employees that you are hiring. In addition to this signed agreement hire developers that you can trust.

Technically speaking that code can easily get copied to device and reused somewhere else. What your boss doesn't want is - access of your competitors to this code. You may only enforce such policies through contracts of employment or partnership.

Another thing that may work is provide training on sensitivity of information, how each employee should be alerted when confidentiality of information is violated. In addition, tracking computer activities within your office network will also raise warning level.

Similar type of training is done annually for employees who deal with PHI related information .

However, getting a trusted people on board and providing training how to protect this information might be the optimal way to go.

share|improve this answer
2  
+1 for mentioning training, a crucial point that other answers seem to be overlooking! Developers are intelligent people; showing why the security procedures are necessary is a far better approach than trying to make the procedures watertight. –  Peter LeFanu Lumsdaine Oct 18 '12 at 16:20
add comment

Did you see Paycheck with Ben Affleck? I think that's the only way to guarantee your IP won't be "stolen". I can tell you that because of my memory, I could recreate almost every system I've worked on for any significant amount of time. If not a line by line recreation, I could produce the significant elements and probably improve on them in the process because of how my skills have grown over the years.

Plain and simple, there are only two things you can accomplish by "locking down" your code:

  1. You'll repulse good developers who are offended by your obvious lack of trust
  2. You'll raise a great big flag that tempts the more unscrupulous developers

If you think your software is that novel and amazing, get a patent.

share|improve this answer
3  
If you think it's hard to prevent one of your developers from copying your IP and selling it to a Chinese company, consider how hard it would be to sue that Chinese company for patent infringement. It could be that preventing your IP from being copied is actually much less expensive than the alternative. –  Scott Whitlock Oct 17 '12 at 19:27
1  
If you think your software is that novel and amazing, chances are, someone else has already written it. And while you're filing for a patent, they're making the software better. –  greyfade Oct 20 '12 at 9:10
add comment
  1. You can't prevent code from leaking. You can limit the leak to less important code.
  2. Normally there is only one part of the application that makes it unique. That would be some algorithm. You can interface this very well, and put this in a separate source control branch. You and only those people who need to work on it should have access to it. You provide only a binary (obfuscated) and the interface to the other developers.
  3. Divide your code into more modules and let people only work on a particular module. The other modules are provided in binary (obfuscated). This, however, can be stretched too far that it will be unmanageable, and can lead to duplication of code.
share|improve this answer
add comment

Be careful not to overestimate the value of your source code to those outside your company.

Sure - you paid a lot of engineers (Developers, QA, etc) lots of money to develop it, but that doesn't mean it's intrinsically valuable to a third party.

What exact attacks exist?

Source code is often leaked from (e.g.) games development or IT security companies. Of course, such leaks make them look bad, but otherwise, cause no real harm.

Ask yourself:

  • Are you so embarrassed about the quality of your source code, it would be damaging to your reputation to leak it?
  • Does the source code itself contain confidential secrets (e.g. hard-coded encryption keys, details of financial relationships with other companies)? Should it?
  • Could a competitor genuinely benefit from using your source code, despite the risk of being discovered?

As far as I know, there was a case where a member of staff at one IT security company tried to sell the source code to a competitor. The competitor immediately reported this to his employer, and he was soon dismissed. No money changed hands, but the staff member can't work easily in the IT security industry any more.

share|improve this answer
1  
+1 for reality checks. There were a number of big source code leaks in the past (e.g. Half Life 2 ), with apparently relatively little damage to the company. As a matter of fact, e.g. MVPs and governments can even officially obtain the source code for Windows. –  sleske Oct 18 '12 at 10:27
    
@sleske yes, but under very strict conditions of confidentiality. There's that trust thing again... –  jwenting Oct 18 '12 at 11:36
add comment

I know someone who worked in an environment like this one.

A few measures that were taken there:

  1. No access to the physical computer, all the computers were stored in a locked room with holes in the wall for display, keyboard and mouse.

  2. No internet access.

  3. Customized operating system that used an in-house-built file system with encryption (in case a computer were to get stolen somehow).

  4. Projects were divided in static libraries, no one had access to the whole source code (this of course does not apply for all programming languages).

  5. It was a very unpleasant workplace.

share|improve this answer
2  
And I can still think of ways to get data...I'm sure there's a recorder device I can tie into the monitors data wire. –  CaffGeek Oct 17 '12 at 20:47
3  
Or I could get a fake eye with a tiny camera and recorder in it! –  CaffGeek Oct 17 '12 at 21:03
2  
You can block cell signals from escaping the room. And you wouldn't be allowing the cells into the room...hooray for friskings! –  CaffGeek Oct 17 '12 at 21:14
8  
I know of a workplace that sounds a lot like this. They're called the NSA. In addition to doing things like this to prevent source code from being stolen by interested outsiders, they also subject their new hires to very detailed background checks to be sure they can trust them. –  Ken Bloom Oct 18 '12 at 2:54
2  
@KenBloom Hi! My name's Bradley Manning... –  itsbruce Oct 18 '12 at 9:37
show 2 more comments

You have to trust, but sometimes it's better to just monitor for infractions. For instance, if your code runs it could phone home to some IP address on the internet whenever it's run, logging the IP address, computer information, perhaps even Geo location of where it's running. Review that log to look for problems.

Of course there are ways around that, and developers could just be looking at the code, not executing it.

You could configure your firewall to do packet inspection with something like Snort that could a) block the connection immediately if it detects, e.g. your copyright notice, and b) report it to management for follow-up. In order to get around SSL and HTTPS you'd need to be running an HTTPS proxy on your firewall.

Perhaps you could have a system utility on every PC that checks external drives and USB flash drives for specific files or key phrases while they're plugged in. You could also disable/ban external drives (I heard the US DOD does this). You'd have to require they use your hardware, and not bring in any hardware from home.

There are probably programs available that will log everything someone does with a computer. Just schedule random audits of these logs, and make sure developers are aware of this capability.

Once you've found an infraction, hit the developer over the head with the NDA they signed.

share|improve this answer
    
Your first paragraph suggests that you are going to host the application. And how are you going to monitor the developper who is going to write that "feature"? –  Simon Oct 17 '12 at 17:24
1  
@Simon - presumably you'd get the "trusted" one to write it, or you'd have two different developers write two different features in isolation. :) Don't think the downvote is fair. I wasn't suggesting these were foolproof ideas, just ways to make the security better. –  Scott Whitlock Oct 17 '12 at 17:26
    
Security theater always seems better. –  BryanH Oct 18 '12 at 18:23
add comment

A technical solution could be to have all development sessions hosted on a server with no (or severely restricted and monitored) network access beyond that required to serve the RDP (or VNC) sessions. That way, the source is never on a developer's machine. It would also make it possible to work from home or a client site.

Ultimately, though, I think the whole situation is ripe for failure. If you make it obvious to developers that you don't trust them, and make their jobs harder, then IMHO you're creating an environment where developers will find some way to make the source public, just to "stick it to the man".

share|improve this answer
1  
The moment you let someone "work from home," you're done. Kaput in one: copy from remote; paste to local. –  BryanH Oct 18 '12 at 18:22
1  
You are already done when you let them read the code. –  BillThor Oct 18 '12 at 23:48
add comment

You are working for people who simply do not understand how software engineering works. Worse: they don't value it (only what they can get out of it). It is not going to be possible to work productively for them; ultimately, they will punish you for this. Find another job.

share|improve this answer
add comment

While I do agree that its a recipe for disaster because no programmer will stay there long enough and you will be spending more time trying to understand other people code, some things come to mind:

  • Block internet access
  • Block any third party access (USB, card readers, etc)
  • Encrypt and save elsewhere any finish line of code. Thats it, turn every code into an API so programmers could not access the functions any more.
  • That brings: Separate programmers from debuggers.

Anyway... prepare to have some high movement of people and high salaries if you want them to stay there. You are creating a very bad working environment.

Keep in mind you could basically write much code from all the free examples that out there in the Internet. Most programming is actually re-using. You are going to block and delay your workers.

share|improve this answer
16  
Saying that you don't read other answers is just a magnet for downvotes. –  vsz Oct 18 '12 at 8:03
1  
Sometimes its hard to understand this community. I really doubt all the people here read everything, I was just being honest since like most people here, I am quite busy and just wanted to add something. Yet, someone that only says "I will never apply for a job there" and bring nothing to the post, its given 128 upvotes. –  sfratini Oct 18 '12 at 20:26
    
Upvotes on comments are worth far less than upvotes on answers. –  Keith Thompson Oct 18 '12 at 22:37
    
I know. I don't care about the points. I am saying. Thats completely off topic yet people punish the one that actually gives an answer... –  sfratini Oct 19 '12 at 1:50
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.