How can I make sure the Source Code is not leaked by our own developers?

Question

I am not a software engineer. So I am curious about how a company to make sure the source code of its product is not leaked by its own developers/employees? What method do you use to trace once it's leaked?

Answer 1

Hire people you can trust and trust the people you hire. If you act like you can't trust them, they'll stop trusting you and will stop acting for the good of your company.

There is nothing technical you can do, because if I can work on your source code, I can sneak it onto a thumb drive or email to my home account or any number of other ways to get it away.

Answer 2

I think Paul is right on with the 'If you don't trust them, don't hire them', but two other things to think about:

Is the source code really that special?
Often, it is the whole business process, brand name, combined with the code that makes a really good product. The vast majority of code that is written, would probably be easier to for other developers to rewrite then to actually read what your developers wrote.

If it really is that special
Your only really option would be to break the tasks up, and don't let see all the developers see all the code. This obviously has a very large penalty, and will probably result worse code. I think the use for this would be extremely rare, maybe high security government situations.

Answer 3

I'd say the only way to secure the source code is to not hire anyone and you're the only developer on the project.

I suppose you could try breaking down the project into modules that are individually linked together later so no one person could completely assemble your product, but I couldn't imagine the politics (or decreased morale) from such an environment...

Otherwise, you would have to talk to a lawyer about options for suing developers who turn on you, enforce a code checkin system that has accountability of who has played with what code when, and use lots of peer review to check for malware hidden in the source. And make sure all your policies (including the sue-your-pants-off clauses) are documented and known to your employees.

Of course, there's a bit of a challenge to doing this and not coming off as a jerk who deserves to have your source code stolen.

I'd say you just have to trust your employees, just as any other employer has to trust his employees aren't using the company car for drag racing and using their cubicles to run a personal Lia Sophia business on the side. Not that you're not going to get burned once in awhile, but you're going to foster a lot more resentment and churn if you treat everyone as a criminal.

There's also the possibility of a change in attitude...as the SO Podcast points out, StackOverflow is being "stolen" periodically and re-purposed but there's obviously a successful original still out there. If your code is stolen and someone else creates a thriving business just based on the source code chances are the company itself is lacking in some areas like customer experience from support, professionalism, etc. It's not right that it's stolen but having something taken is always a risk that comes as a cost of doing business sometimes. Not to mention that it is technically possible for someone to reverse engineer any product (or just steal the product and repackage it themselves, without the source code, a lot easier to do...)

Seems most people worry about that kind of piracy over someone stealing the original source and having to play with updating and altering and compiling it that way.

Answer 4

An approach taken by a previous employer was that all source files (and all internal documentation, for that matter) had to carry a confidentiality notice in them.

There was also significant resources spent on educating staff about the risks to the overall company if there were to be a leak.

It is worth making it explicit in the contract of employment too, especially if you're in a jurisdiction where the employer would seek to claim damages from anyone leaking IP.

Answer 5

Another way of handling this problem is to make the source code open source. There is nothing to steal if it is all public anyway. However, the only way that this is possible would be if the source code was not the secret sauce that brings in money. If the company makes money by selling services or hardware, giving away the software would be less of a problem. Ditto, if the software is only one small part of an extremely complex system.

Answer 6

The only way i think you could accomplish this would be to departmentalize everything. Make sure that each team builds their part to spec that way the knowledge is diffused across a variety of people and no one has the entire picture.

You would need to make the computers physically unreachable (no usb/optical writers), and not connect them to the internet.

But beyond that it's a trust thing and really people tend to remember solving problems, and how they solved them. That's what coding is. They will be able to rewrite what they did.

Answer 7

For the extremely paranoid, there's always the compartmentalized, need-to-know model that limits knowledge (and access) of the whole to a very few people. I would think it would be a very difficult and unpleasant environment to work in.

Answer 8

Totally agree with the answer above, always better to approach this with a non-technical solution.

But here's my £0.02.

Non-technical solution: Whilst this isn't great for small or simple projects. You could split the application into modules/components so your developers are more like assembly workers in a factory. No one has access to the entire project they only see the part they are working on.

Technical solution: Assuming developers are on-site. Lock down workstations using USB sentry software like Sanctuary. Do not give developers Local Admin to workstations so they can't install 3rd party software to circumvent security (ssh/http proxies etc). Employ some form of Data Loss Prevention software (all Security software firms have their own flavour CA, ClearSwift etc). Block/monitor Email to the Internet and Web access. Work is never taken home no matter what, same goes for teleworking do not allow it.

Answer 9

When you are posed with a security question such as this, always ask yourself, "What would they do in the Movies?"

There is a movie that comes to mind when I think about this problem. How to get someone to write code but ensure they cannot bring the code home with them. Indeed, after watching the movie 'Paycheck' starring Ben Affleck, I think I have the answer. In this rotten tomato, Ben plays an engineer that is locked in a room until he finishes the job. When he is done, his employer simply hands him a check. Oh, and they wipe his memory.

So - lock your developers in a room until the software is finished, then wipe their memory.

Getting his memory wiped.